Automated accessibility scans detect approximately 25% of accessibility issues on a web page. The remaining 75% requires human evaluation to identify. Understanding where the gap falls helps organizations plan for both.
| Key Point | What It Means |
|---|---|
| Scan Coverage | Scans flag about 25% of WCAG conformance issues by evaluating HTML, CSS, and ARIA attributes |
| Human Coverage | Human evaluation identifies the other 75%, including context, usability, and interaction patterns |
| Why Both Matter | Scans provide a fast baseline; human evaluation provides depth and accuracy |
What Automated Scans Can Detect
Scans work by loading a web page and running automated checks against WCAG success criteria. They evaluate the code structure, looking at HTML elements, CSS properties, and ARIA attributes.
This makes scans effective at flagging issues that are binary and code-visible. A missing alt attribute on an image is either present or absent. A form field either has a programmatic label or it does not.
A heading hierarchy either follows a logical order in the markup or it skips a level. These types of issues have clear right-or-wrong answers that a scan can verify without interpretation.
Where Scans Stop
Scans cannot interpret meaning. An image may have an alt attribute, but a scan cannot determine whether the alt text accurately describes the image content. A button may have an accessible name, but a scan cannot tell if that name makes sense to someone who cannot see the surrounding visual context.
Scans also cannot operate the page the way a real person would. They read static code. They do not move through a page with a keyboard, listen through a screen reader, or try to complete a multi-step process like filling out a form or making a purchase.
What Human Evaluation Identifies
Human evaluators interact with the page using assistive technologies like NVDA, JAWS, and VoiceOver. They conduct keyboard testing, screen reader testing, and visual presentation checks at different zoom levels (200% and 400%).
This evaluation identifies issues that require judgment. A reading order that looks correct in the code may be confusing when heard through a screen reader. A custom dropdown may appear functional with a mouse but trap keyboard focus. An error message may exist in the DOM but never get announced to assistive technology users.
These are the types of issues that make up the 75% scans cannot reach.
Common Categories Scans Miss
Keyboard operability is a frequent gap. Scans can check whether focusable elements exist, but they cannot verify that a user can move through every interactive component in a logical sequence without getting stuck.
Screen reader coherence is another. The experience of hearing a page read aloud involves sequence, context, and labeling accuracy. A scan sees code, while a human evaluator hears the page and knows whether it makes sense.
Dynamic content creates additional blind spots. Pages that change based on user actions, such as modals, accordions, or single-page application routes, often require interaction to reveal their accessibility issues. Scans evaluate what loads initially, not what appears after a click or a state change.
How Both Fit Together
Scans serve as an efficient first pass. They catch the 25% quickly, which frees human evaluators to focus on the deeper, context-dependent issues that make up the rest. Running scans before a manual audit means the evaluator spends less time on code-level issues and more time on usability and interaction patterns.
Neither approach replaces the other. An accessibility program that relies on scans alone misses three-quarters of the picture. An audit conducted without a prior scan may spend time identifying issues that could have been flagged automatically.
The 25% and the 75% are complementary, and accounting for both is what separates a partial review from a complete evaluation.