Automated scans only flag approximately 25% of WCAG issues. The remaining 75% require human evaluation because they involve meaning, context, and usability judgment that software cannot replicate. Understanding which issues fall into that gap is the first step toward accurate WCAG conformance.
Scans are pattern-matching tools. They read code and check whether certain attributes exist. They cannot interpret whether those attributes are correct, meaningful, or useful to someone with a disability. That distinction separates detectable code errors from the vast category of issues that require a person to evaluate.
| Factor | Detail |
|---|---|
| Detection rate | Scans flag approximately 25% of WCAG issues |
| Root cause of the gap | Most WCAG criteria require human judgment about meaning and context |
| Conformance determination | A (manual) accessibility audit is the only way to determine WCAG conformance |
| Common missed categories | Alt text quality, keyboard functionality, focus order, reading order, form labels, video captions |
What Can a Scan Actually Detect?
Scans check for the presence or absence of code-level attributes. A scan can confirm that an image has an alt attribute. It can flag a form input that lacks a label element. It can detect insufficient color contrast between two hex values.
These are binary, code-readable checks. The attribute either exists or it does not. The contrast ratio either passes or it does not.
The problem is that most WCAG criteria do not operate on a binary, code-readable basis. They require interpretation.
Alt Text That Exists but Fails
A scan sees alt="image" on an <img> element and moves on. It has no way to evaluate whether that alt text accurately describes the image or conveys equivalent information. An image of a quarterly revenue chart labeled alt="chart" passes every automated check while providing no usable information to a screen reader user.
WCAG 1.1.1 (Non-text Content) requires that non-text content have a text alternative that serves an equivalent purpose. Evaluating equivalence requires understanding the image and the surrounding content. That is a judgment only a person can make.
Decorative images present a related issue. A scan cannot determine whether an image is decorative or informational. If a decorative image carries an alt description, it adds noise for screen reader users. If an informational image is marked decorative with an empty alt attribute, critical content is lost. Both situations conform on a code level while failing in practice.
Keyboard Accessibility and Focus Management
WCAG 2.1.1 (Keyboard) requires that all functionality be operable through a keyboard interface. A scan cannot tab through a page, interact with custom components, or determine whether a dropdown menu, modal dialog, or date picker works without a mouse.
Custom JavaScript components are where keyboard issues concentrate. A scan reads the static HTML. It does not execute the component, press Tab to move through it, press Enter to activate it, or press Escape to close it. Only a person using a keyboard can evaluate whether these interactions work.
Focus management is a closely related gap. When a modal opens, focus should move into it. When it closes, focus should return to the trigger. When new content loads dynamically, focus should land in a logical position. Scans have no mechanism to evaluate any of this because it requires real-time interaction with the rendered page.
Does a Scan Evaluate Reading Order and Content Structure?
Screen readers follow the DOM order of a page, not the visual layout. CSS can position elements visually in a sequence that differs entirely from the underlying code order. A scan reads the code but cannot determine whether the resulting reading order makes logical sense to someone who cannot see the layout.
Heading hierarchy is partially detectable. A scan can flag a skipped heading level, such as jumping from H2 to H4. But it cannot evaluate whether the headings accurately describe the content beneath them or whether the hierarchy reflects the actual structure of the page. A page with perfect heading levels and meaningless heading text passes every scan.
WCAG 1.3.2 (Meaningful Sequence) requires that content presented in a meaningful sequence can be programmatically determined. Evaluating this requires understanding what the meaningful sequence actually is, which is a content judgment.
Form Labels and Error Identification
A scan can verify that a form input has an associated <label> element. It cannot verify that the label text is clear, accurate, or sufficiently descriptive. A text input labeled “Field 1” passes the automated check. A person evaluating the form would immediately identify it as unusable.
Error identification under WCAG 3.3.1 is another area scans cannot reach. When a user submits a form with errors, the page must identify the error and describe it in text. Scans cannot submit forms, trigger validation, or evaluate whether error messages are present and descriptive. The entire error-handling workflow is invisible to automated tools.
WCAG 3.3.3 (Error Suggestion) goes further, requiring that when an error is detected and suggestions for correction are known, those suggestions be provided. Evaluating this requires triggering the error, reading the suggestion, and judging its usefulness.
Video and Multimedia Content
Scans cannot evaluate captions. They may detect the presence of a caption track file, but they cannot compare the captions against the actual spoken audio to confirm accuracy, synchronization, or completeness. A video with auto-generated captions full of errors passes the same automated check as one with professionally written captions.
Audio descriptions for pre-recorded video (WCAG 1.2.5) are another gap. A scan has no way to determine whether meaningful visual information is conveyed only through the video with no audio equivalent. Only a person watching the video can make that determination.
Context-Dependent Link Text
WCAG 2.4.4 (Link Purpose in Context) requires that the purpose of each link can be determined from the link text or from the link together with its programmatically determined context. A scan can flag a link with text “click here,” but most context-dependent link issues are subtler.
A page with three links all labeled “Learn more” passes many automated checks. A person evaluating the page recognizes that a screen reader user tabbing through links would hear “Learn more, Learn more, Learn more” with no way to distinguish among them. That is a conformance issue no scan will identify.
Dynamic Content and State Changes
Modern web pages update content without full page reloads. Notifications appear. Sections expand. Content loads as the user scrolls. WCAG 4.1.2 (Name, Role, Value) requires that the name, role, and state of user interface components be programmatically determinable.
A scan takes a snapshot of the page at one moment. It does not interact with accordion panels, toggle switches, tab interfaces, or any component whose state changes through user action. Whether an ARIA attribute updates correctly when a component is activated is something only a person can evaluate by using the component.
Why This Matters for Conformance
WCAG conformance means meeting every applicable success criterion at the target level for every page in scope. Because scans can only evaluate approximately 25% of issues, a clean scan result says very little about actual conformance. An organization relying on scans alone has no basis for a conformance claim.
A (manual) accessibility audit conducted by a qualified evaluator is the only way to determine WCAG conformance. The evaluator interacts with every component, evaluates content in context, and uses assistive technology like screen readers to assess the real user experience. That is what closes the 75% gap that scans leave open.
Accessible.org audits address the full scope of WCAG criteria through human evaluation. The Accessibility Tracker Platform then maps every identified issue to a structured workflow so teams can remediate efficiently and track progress over time.
Frequently Asked Questions
Should I stop using automated scans entirely?
No. Scans are useful for catching code-level issues quickly, especially during development. They serve a different purpose than an audit. Use them as a first pass to catch detectable issues, and use a (manual) audit to evaluate everything scans cannot reach.
Can AI-powered scans catch context-dependent issues?
Current AI-powered scanning tools have improved at detecting certain patterns, but they still cannot replicate the judgment required for alt text accuracy, keyboard operability, focus management, or meaningful reading order. The 25% detection rate applies broadly across scan tools, including those with AI features.
Which WCAG level has the most issues scans miss?
The gap exists across all levels. Level A includes keyboard accessibility, alt text quality, and form error identification. Level AA includes captions, focus visibility in context, and reflow. The proportion of human-judgment criteria is consistent across both levels.
Scans and audits are separate activities that serve different purposes. Knowing where the line falls between them is what separates organizations that track a conformance number from those that actually achieve it.
Contact Accessible.org for a comprehensive accessibility audit that evaluates the issues no scan can reach.
