Automated accessibility scans can evaluate a subset of Web Content Accessibility Guidelines (WCAG) success criteria, primarily those with outcomes that are binary and detectable through code analysis. This covers roughly 25% of all WCAG criteria scans evaluate at a reliable level. The remaining 75% require human judgment to assess.
| Key Point | What It Means |
|---|---|
| Coverage | Scans flag approximately 25% of WCAG issues with reliable accuracy |
| Detection method | Scans evaluate HTML, CSS, and ARIA attributes against defined rules |
| Strongest areas | Criteria with programmatically verifiable pass/fail conditions |
| Weakest areas | Criteria requiring context, intent, or user experience judgment |
What Makes a WCAG Criterion Scannable?
A scan works by loading a page and evaluating its code. It reads HTML elements, CSS properties, and ARIA attributes, then compares what it identifies against a set of programmed rules. If a criterion has a clear, code-level pass or fail condition, a scan can evaluate it.
For example, a scan can check whether an image has an alt attribute present. It can confirm whether a form input has a programmatically associated label. It can verify whether a page includes a language declaration in the HTML tag.
These are binary checks. The element either exists in the code or it does not.
Criteria That Scans Evaluate Well
Scans are most effective with WCAG criteria tied to specific HTML structures. Under the Perceivable principle, scans can flag images missing alt attributes (1.1.1 Non-text Content, partially), missing form labels (1.3.1 Info and Relationships, partially), and pages lacking a language attribute (3.1.1 Language of Page).
Under the Operable principle, scans can identify pages missing title elements (2.4.2 Page Titled) and links with duplicate or empty text (2.4.4 Link Purpose in Context, partially). Under Understandable, scans detect absent labels and missing error identification markup.
Across the Robust principle, scans are effective at flagging duplicate IDs, invalid ARIA roles, and parsing issues (4.1.1 Parsing, 4.1.2 Name, Role, Value, partially).
Where Scans Fall Short
Many WCAG criteria require an evaluator to assess meaning, not code. A scan can confirm an alt attribute exists, but it cannot determine whether the alt text accurately describes the image. A scan can detect a label on a form field but cannot assess whether the label makes sense to a person filling out the form.
Criteria related to keyboard operability, reading order, focus management, timing, motion, and cognitive load are beyond what code analysis can determine. These require someone to interact with the page using assistive technologies and observe the results firsthand.
WCAG 2.1 AA and 2.2 AA each include criteria addressing reflow, text spacing, and pointer interactions that depend on visual and functional evaluation, not code inspection alone.
Partial Detection Is Common
Several criteria fall into a middle category where scans can identify a potential issue but cannot confirm whether it is actually a problem. A scan might flag a table without header cells, but whether that table is a data table or a layout table requires context a scan does not have.
Scan results often include items marked as needing manual review. The scan identifies a pattern in the code that could indicate an issue, but a human evaluator must verify it.
How Scans Fit into a Full WCAG Conformance Strategy
Scans are a starting point, not an endpoint. They efficiently surface the 25% of issues that are code-detectable, giving teams a baseline to work from. The remaining evaluation requires a manual audit conducted by an accessibility professional using screen readers, keyboard interaction, and visual inspection.
Organizations pursuing WCAG 2.1 AA or 2.2 AA conformance use scans as one component within a broader evaluation process. Scans provide speed and repeatability. Audits provide the depth and contextual judgment that conformance requires.