No. Unfortunately, we cannot automate accessibility. And that is not likely to change in the future.
Tools already exist that automatically analyse the accessibility of a website. For example, WAVE is a suite of tools that helps us identify failures in compliance with accessibility guidelines. If we use one of its extensions for different browsers, we get a list of potential non-compliances while browsing the page, pointing out the specific point of failure with information on how to fix it.
Another example is Axe-core. This is an open-source tool that can be used to automatically analyse an entire website. We also get a list of non-compliances with precise information on how to locate them. These are just two examples of free tools, but many other paid tools and services exist.
So, why can we not automate accessibility on a website?
Firstly, because tools generally report a non-compliance, but are not necessarily capable of fixing it. The simplest example is with images. A tool tells us that an image has no alternative text, but it cannot assess whether that image is purely decorative or not, nor what alternative text would be appropriate.
And you might be thinking: Can an AI not see what is in the image? And the answer is yes, more or less. Because the alternative text of an image depends on an intentional human decision to use that image, one must know that intention to provide good alternative text.
An example: a member of a company’s team receives an award, and we publish a photo on the company blog. In that photo, we see “two people, one of them holding an award”. Would that be a good alternative text? Because if we publish it to announce that someone has won that award, we would need to include their name, mention that they are part of the company team, and, if the award is related to a company project, probably mention that as well. It all depends on the intention behind publishing that photo.
Another reason why automatic tools are sometimes insufficient is that there are errors (even those that are errors in the code) which are impossible to detect.
Another example: if we have tabbed navigation in one part of the website, the implementation requires relating each tab to its corresponding content, marking which one is active or visible at that moment, making it keyboard-navigable, and so on. You can see full examples of a tab pattern implementation in the Accessible Rich Internet Applications (ARIA) Authoring Practices Guide. If we have done the entire implementation correctly and have only forgotten to mark which tab is active, an automatic tool might recognise the implementation pattern and indicate the missing part.
But if we have only implemented it visually without adding any of the necessary parts in the code, how can the automatic tool know that we are implementing tabbed navigation?
These limitations mean that automating the detection of accessibility issues is very useful, but insufficient. It can help us detect oversights and improve the development and implementation of new content, but it cannot detect everything or offer solutions. And we might fall into the error of thinking that if an automatic tool does not detect any faults, it is because there are none, which is not necessarily the case. Tools help us, but they do not replace knowledge or human factors such as intention.
Fran Rosa, Senior Developer & Advocate specialising in people-first development