Accessibility scan tools work by running automated checks against specific Web Content Accessibility Guidelines (WCAG) success criteria. Each check corresponds to one or more WCAG requirements, and the tool reports whether the page passes or does not pass that particular criterion. This mapping between tool checks and WCAG requirements determines what a scan can and cannot evaluate.
| Key Point | What It Means |
|---|---|
| Mapping method | Each automated check is coded to evaluate a specific WCAG success criterion by inspecting HTML, CSS, or ARIA attributes |
| Coverage | Scans only flag approximately 25% of WCAG issues; the remaining 75% requires human evaluation |
| Strongest areas | Criteria with clear programmatic rules, such as missing form labels or absent alternative text attributes |
| Weakest areas | Criteria requiring judgment, such as whether alternative text is meaningful or whether content is logically ordered |
What Scan Tools Actually Inspect
A scan loads a web page and inspects the rendered HTML, CSS, and ARIA attributes. Each check the tool runs corresponds to a coded rule. That rule is tied to a specific WCAG success criterion at a defined conformance level (A, AA, or AAA).
For example, a tool might check whether every img element has an alt attribute. That check maps to WCAG success criterion 1.1.1 (Non-text Content). If the attribute is missing, the tool flags it.
The tool does not evaluate whether the text inside the attribute accurately describes the image. That distinction is the boundary between what code can verify and what a person must assess.
Which WCAG Criteria Scans Cover Well
Scans perform best where the WCAG requirement has a binary, code-level answer. A form input either has a programmatic label or it does not. A page either has a language attribute on the html element or it does not.
Criteria related to the presence or absence of specific elements, duplicate attributes, or structural markup tend to produce reliable automated results. These are the criteria where the gap between “attribute exists” and “requirement met” is smallest.
Where the Mapping Breaks Down
Many WCAG success criteria depend on context, meaning, or user experience. A scan can confirm that a heading element exists, but it cannot determine whether the heading text accurately reflects the section content. It can detect that a link has visible text, but not whether that text communicates the link’s purpose.
This is why scans flag approximately 25% of accessibility issues. The remaining 75% involves criteria where a code-level check is either impossible or insufficient. Evaluating those criteria requires a human auditor conducting screen reader testing, keyboard testing, and visual inspection.
How Conformance Levels Affect Coverage
WCAG organizes success criteria into three conformance levels: A, AA, and AAA. Most organizations target WCAG 2.1 AA or WCAG 2.2 AA conformance.
Scan coverage is not evenly distributed across levels. Some Level A criteria lend themselves well to automated checks because they involve fundamental markup requirements. At the AA level, criteria increasingly involve interaction patterns and content relationships that code inspection alone cannot verify.
Reading Scan Results Against the WCAG Map
When a scan returns results, each flagged item typically references the WCAG criterion it maps to. A result labeled “1.3.1” points to the Info and Relationships criterion. A result labeled “4.1.2” points to Name, Role, Value.
These references are useful for prioritization and for understanding which conformance requirements a page is or is not meeting. They do not indicate that the criterion has been fully evaluated. A pass on an automated check means the code-level portion of that criterion was not flagged, not that the criterion is fully satisfied.
Scan results are a starting point. A complete evaluation of WCAG conformance pairs those automated results with an audit that covers the criteria scans cannot reach.