Automated accessibility testing has become a standard part of modern website development. Tools such as WAVE, Axe, and Lighthouse can scan a page in seconds and identify problems that once required someone to inspect the code manually. For development and quality assurance teams, that capability is incredibly valuable.
It can also create a false sense of completion.
A page can pass an automated accessibility test and still be difficult for someone to navigate with a keyboard, confusing when read through a screen reader, unclear when forms return errors, or frustrating when an interactive component changes unexpectedly.
The World Wide Web Consortium (W3C) is clear about this distinction. Accessibility evaluation tools can help identify barriers, but no tool on its own can determine whether a website meets accessibility standards. Knowledgeable human evaluation remains necessary.
For teams building websites, that changes how automated accessibility testing should be understood. A scan is an important layer of quality assurance. It is only one layer.
What Automated Testing Does Well
Automated testing works particularly well when an accessibility requirement can be translated into a repeatable technical rule.
A scanner can identify an image without an alternative text attribute. It can detect certain color contrast failures, missing form labels, an undeclared page language, duplicate IDs, and many incorrect uses of ARIA. It can analyze large numbers of pages quickly and flag recurring issues that might otherwise be repeated throughout a website.
That makes automation extremely useful during implementation.
If a component has an accessibility problem and that component appears on 100 pages, discovering the problem before launch is considerably more efficient than correcting every instance afterward. Automated checks can also be incorporated earlier into development workflows so that accessibility issues surface as components and templates are being built.
The value of these tools should not be underestimated. The limitation is that accessibility includes many questions that software cannot answer confidently.
What We Learned When People Actually Used the Experience
Some of the clearest lessons we have learned about accessibility have come from moving beyond evaluation and watching people with impaired vision actually use the experiences we build.
As part of expanding our accessibility testing process at ArtVersion, we worked with blind and low-vision participants who rely on assistive technologies in their everyday lives. The testing was task-based rather than simply asking someone to review individual pages. Participants navigated content, located information, moved through menus and interacted with the experience using their own combinations of devices, browsers and screen readers.
A technical review can tell us whether a heading is coded correctly, whether a control has an accessible name or whether a particular WCAG criterion appears to be satisfied. A person trying to complete a task can tell us something different: where they hesitate, where context disappears, which labels make sense, how long it takes to reach something important and whether an interaction behaves the way they expect it to.
We also saw how differently the same website can be experienced depending on the technology being used. Testing included VoiceOver on an iPhone as well as JAWS and NVDA on Windows across different browsers. Something that works smoothly in one environment can feel different in another, and an issue that seems relatively minor when looking at the interface visually can become much more significant when information is encountered sequentially through a screen reader.
Perhaps the most useful lesson was that accessibility problems are not always failures that neatly appear in a report. Sometimes the interface technically works, but completing a task requires too much effort. Sometimes the information is available, but the path to understanding it is unnecessarily complicated. Those observations are difficult for an automated scanner to make because they depend on context, behavior and the experience of the person using the site.
That experience has reinforced how we think about automated accessibility testing. It is an important part of the process and one we use extensively, but its results need to be understood alongside manual evaluation and real interaction.
The 30–40% Number Needs Some Context
One figure frequently repeated in accessibility conversations is that automated testing catches roughly 30 to 40 percent of accessibility problems.
There is some basis for that general idea, although the percentage depends on what is being measured.
WebAIM has stated that automated tools can detect only about 25 to 35 percent of possible accessibility conformance failures. It also cautions that the absence of automatically detectable errors does not mean a website is accessible or compliant.
Deque reached a different number when it examined real accessibility audits. Its analysis covered more than 13,000 pages or page states and nearly 300,000 accessibility issues. Axe-core automation identified 57.38 percent of the total issues recorded in that dataset.
Those figures measure different things.
One looks at how many types of conformance failures can be determined automatically. The other looks at the volume of actual issues found across audited pages. A machine-detectable problem can occur repeatedly across a site, which means automation may discover a substantial share of the total errors while still being unable to evaluate many accessibility requirements.
For a development team, the precise percentage is less important than the larger point: automated testing can identify a significant amount of accessibility debt, while important parts of the experience still require human judgment.
An Alt Attribute Does Not Tell You Whether the Alt Text Is Useful
Alternative text is a simple example of where that distinction appears.
An automated tool can usually determine whether an image includes an alt attribute. It has a much harder time determining whether the words inside that attribute communicate what someone actually needs to know.
An image might technically contain alternative text such as “image,” “graphic,” or an automatically generated filename. The scanner sees that the attribute exists. A person using a screen reader receives almost no meaningful information.
Context makes the evaluation more complicated.
A photograph used decoratively may require no description at all. That same photograph used to communicate something important within a case study could require meaningful alternative text. A chart may need a description of the information it communicates rather than a description of how it looks.
The code alone cannot always explain the purpose of the content.
The Same Problem Appears Throughout an Interface
Buttons, links, headings, navigation, and forms create similar situations.
A button can have an accessible name and still leave its purpose unclear. A heading hierarchy can technically exist while doing a poor job of communicating how the information on the page is organized. A form field can contain a valid programmatic label while its instructions remain confusing. An error message may be correctly connected to an input and still fail to explain how someone should resolve the problem.
These situations require someone to interpret the experience.
The question becomes less about whether an element exists in the markup and more about whether the information surrounding it makes sense when visual assumptions are removed.
This is one of the reasons manual review becomes so important. Accessibility depends on relationships between content, design, code, interaction, and context. Each individual element can look correct in isolation while the experience created by those elements remains difficult to use.
Keyboard Testing Reveals What a Scan Cannot
One of the simplest manual accessibility tests is also one of the most revealing: put the mouse aside and navigate the website with a keyboard.
- Can you reach every interactive element?
- Can you tell which element currently has focus?
- Does the focus move through the page in a logical order?
- Can menus be opened and closed?
- Can form controls be operated?
- Can someone enter and exit a modal without becoming trapped?
- When the modal closes, does focus return somewhere sensible?
Automated testing can identify some keyboard-related problems, but the quality of the interaction often becomes apparent only by moving through it.
A keyboard-accessible interface can technically function and still require an unreasonable amount of effort. A user might need to tab through dozens of navigation links before reaching the primary content. Focus may jump somewhere unexpected after an interaction. A visually prominent element may appear early on the page while arriving much later in the keyboard sequence.
Those are experiential issues, and they matter.
Dynamic Interfaces Make Human Review Even More Important
Web interfaces have become considerably more dynamic. Accordions, tabs, sliders, filters, autocomplete fields, menus, modal windows, dashboards, search experiences, and asynchronously updated content can all change what appears on a page without loading a new one.
Accessibility in these environments depends heavily on behavior.
When new content appears, does a screen reader user know something changed? When a filter is applied, is the result communicated? When a menu opens, is its expanded state exposed correctly? When an error appears after a form submission, can someone find it and understand what happened?
A scanner can inspect the underlying structure and identify many technical problems. Evaluating the sequence of events often requires someone to interact with the component.
W3C’s current WCAG Evaluation Methodology acknowledges this limitation directly. Its guidance notes that most accessibility checks are not fully automatable, while evaluation tools remain valuable for supporting a broader human evaluation process.
Screen Readers Add Another Perspective
Screen reader testing can reveal issues that are difficult to recognize visually because it exposes the interface through the information provided by the underlying code.
A visually obvious page might sound very different when experienced as a sequence of headings, links, buttons, form controls, landmarks, labels, and announcements.
That difference matters because visual design communicates relationships in ways that may never reach assistive technology. Position, proximity, color, scale, icons, and animation can all provide context to a sighted user. When those visual cues disappear, the semantic structure of the page has to carry much more of the experience.
Testing with a screen reader can expose vague link labels, repetitive navigation, confusing heading structures, missing context, poorly announced state changes, and interactive elements whose purpose is obvious visually but unclear when heard.
It also provides developers with something an automated report cannot: an understanding of what the interface actually sounds like.
Accessibility Should Be Tested Throughout Implementation
Accessibility becomes much harder when it is treated as an audit that happens after everything else has been completed.
By that point, problematic patterns may already exist across dozens of components and hundreds of pages. A navigation issue can be embedded throughout the site. An inaccessible form pattern may have been reused repeatedly. Decisions made months earlier can become expensive to reconsider because they are now connected to design, development, content, and functionality.
Testing during implementation creates a different workflow.
Automated scans can identify repeatable technical issues as components are built. Keyboard testing can validate interaction behavior. Manual review can evaluate content structure and context. Assistive technology testing can reveal how those decisions translate beyond the visual interface.
Accessibility then becomes part of the same quality process used to evaluate responsiveness, functionality, browser compatibility, performance, and design fidelity.
That is a much healthier place for it to live.
A Better Accessibility Testing Process Is Layered
There is no single test that tells a team everything it needs to know about accessibility.
Automation provides scale and consistency. Manual review provides judgment. Keyboard testing exposes interaction behavior. Assistive technology testing reveals how the interface is communicated through different modes of use. Involving people with disabilities can provide another level of insight into the real experience, something W3C also recommends as part of accessibility evaluation.
These approaches complement one another.
For a typical website implementation, the process might begin with automated testing at the component and template level. Manual testing can then evaluate keyboard navigation, focus management, zoom and reflow, content structure, forms, error handling, and interactive states. Screen reader testing can be used across representative journeys and important functionality.
The exact approach will vary with the complexity of the website, but the principle remains consistent: accessibility needs more than one method of evaluation.
Passing the Test Is Where the Review Begins
There is something reassuring about seeing an accessibility tool return zero errors. It gives the development team an objective result and confirms that many detectable issues have been addressed.
That result still needs context.
A scanner does not experience uncertainty when a button label is vague. It does not struggle through an unexpected focus order. It does not wonder whether an error message explains what went wrong. It does not have to understand the information in an image or determine whether navigating an interface requires unnecessary effort.
People do.
The best use of automated accessibility testing is to let software handle the problems software can reliably identify, then continue evaluating the experience through human interaction and judgment.
Passing an automated accessibility test is an accomplishment worth reaching and it’s a good starting point for the teams. It just should not be where accessibility testing ends.