Would you publish without spellchecking?
I have been promoting use of automated accessibility tools for years. There has been a lot of controversy around them because publishers want them to be more than they are. There is never going to be an automated tool that will be able to tell an author with any certainty that there are no barriers for users accessing the content.
Many in the web accessibility industry are beginning to re-position the discussion as more akin to spellcheckers. Spellcheckers compare patterns of characters with a dictionary to highlight words that are unknown. Often there is industry jargon, names or acronyms that are legitimate, but that the author should just review to make sure. Everyone involved in creating digital content needs to think about automated accessibility tools in the same light.
The UK government describes automated accessibility tools in an article in their series on Accessibility in Government, What we found when we tested tools on the world’s least-accessible webpage:
“A good analogy is to think of a testing tool as like using a spellchecker. It can certainly help you pick up issues, but it should never be used in isolation. To be most useful, automated tools should be combined with manual inspection and user research.”
Just like a spell checker, it often takes a manual inspection to make sure that the author has used “their” vs “there” correctly. Grammar checkers are getting much better at this, but even still they are simply looking at libraries of patterns that have been collected and comparing those with what has been written. Grammarly and the HemingwayApp are among many that are just applying rules to help guide the author to produce better work. They will never replace a human editor’s ability to evaluate if it actually makes sense.
The majority of accessibility errors will probably only be identified through manual intervention. This doesn’t mean that organizations shouldn’t use automated tools, just that people shouldn’t rely on them. Organizations should also be:
- building sites to better support authors in creating accessible content (ATAG 2.0 AA);
- doing user testing with a range of users with different disabilities;
- hiring 3rd party professionals to review the site, particularly when designs change;
- leveraging patterns that have already been tested for accessibility;
- doing the hard work of simplifying the interaction for everyone;
- providing a clear Accessibility Statement that engages users who face barriers to report them.
I am confident that anyone involved in creating content for the web needs to have easy access to tools that allows them to easily assess basic accessibility problems.
Firefox & Chrome both have some built in accessibility tools now. There are also several browser extensions for Firefox (WAVE and axe) and Chrome (WAVE, axe and Accessibility Insights) that make doing quick accessibility reviews easy. Microsoft’s Edge Insider (Accessibility Insights) can also leverage more developer tools than were available for IE, since it is based on the Chromium open source project which is the basis of Chrome.
For secure environments it is worth noting that the WAVE extension boldly claims that:
“Because the extension runs entirely within your web browser, no information is sent to the WAVE server. This ensures 100% private and secure accessibility reporting.”
If that isn’t sufficient assurance, then Microsoft’s Accessibility Insights leverages Deque’s axe core and both are open source. I encourage security teams to evaluate these tools and find ways to improve them.
In the USA the 18F’s Accessibility Handbook recommends a range of tools. Recently the Canadian Digital Services produced a smaller handbook with their practice of using automated tools.
One of the misconceptions I’ve heard is that someone needs to be a publisher to make use of these tools. I am happy to report that anyone involved in creating digital content can learn how to make use of these tools to identify accessibility problems. They may not be able to fix them, but most make it easy to report them. With the WAVE Toolbar anyone can take a screenshot of the error message, or if it is a public page a user can simply send a URL to the developers to highlight the problem. Accessibility Insights has a nice function to export the accessibility problems it finds that they can be forwarded along to a developer who should be able to fix them.
Governments need to give everyone involved in creating digital content access to the main browsers that their users actually use.
Any organization that cares about accessibility should ensure that the tools that allow authors to quickly check for easy mistakes are enabled by default. Far too many simple accessibility barriers are regularly missed because developers, designers and authors are not given the right tools to do the job. Web accessibility in many organizations is left to the experts to debate rather than something for which everyone should know the basics.
If an editor had to spend all of their time chasing down spelling mistakes, they wouldn’t be able to take the time to support the author in seeing that it is well written. Accessibility is a team sport, and everyone has a role. Lack of proper tools and training means that often the low-hanging-fruit gets missed which can easily damage your credibility on accessibility.
The easiest way to catch spelling errors is while engaged in writing. It would be much harder to spellcheck a book if the author had to wait right before it were published and fix all the issues at once. Same goes for accessibility: make it easy to just incorporate the basics into the daily routines of creating digital content.
I don’t ever expect to win a spelling bee. I will rely on automated tools to help me write better. This should be a fairly straight forward process, as we know that these tools are already used inside of government. These tools just need to be installed by default. Let’s make sure we stop accessibility “typos” from being published to the websites we work on.
