Most accessibility scan tools on the market reference Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as their evaluation baseline, but none of them cover it fully. Scans detect approximately 25% of WCAG issues by evaluating HTML, CSS, and ARIA attributes against success criteria that can be checked programmatically. The remaining 75% requires human evaluation.
| Key Point | What It Means |
|---|---|
| Coverage Level | Scan tools check approximately 25% of WCAG 2.1 AA criteria automatically |
| Evaluation Method | Tools load pages and inspect code structure, labeling, and attribute values |
| Common Baseline | Most tools reference WCAG 2.1 AA as the default standard |
| What Scans Miss | Logical reading order, meaningful content sequence, and context-dependent criteria require human review |
What Types of Scan Tools Reference WCAG 2.1 AA?
Browser-based scanners, API-based scanners, command-line scanners, and open source scanners all typically reference WCAG 2.1 AA. The version and level they target is usually configurable, but 2.1 AA is the most common default because it aligns with current regulatory expectations, including ADA Title II requirements and European Accessibility Act (EAA) references.
Some tools allow users to select WCAG 2.0 AA or WCAG 2.2 AA instead. The difference between versions affects which success criteria the scan checks against, though the overall detection rate remains around 25% regardless of which version is selected.
Which WCAG 2.1 AA Criteria Can Scans Evaluate?
Scans are effective at identifying issues tied to code-level attributes. Missing form labels, absent alt text on images, duplicate ID values, incorrect heading hierarchy, and missing language declarations are examples of what automated checks can flag reliably.
These criteria share a common trait: the correct or incorrect implementation is detectable in the source code without requiring subjective judgment. A label either exists or it does not. A heading level either follows the correct sequence or it skips a level.
Where Do Scan Tools Fall Short on WCAG 2.1 AA?
Criteria that depend on context, meaning, or user experience sit outside what any scan tool can assess. Whether alt text is accurate and descriptive, whether content remains usable at 200% and 400% browser zoom, whether keyboard focus order is logical, and whether error messages are helpful all require a human evaluator.
This is why scan tools serve as one component within a broader evaluation strategy rather than a standalone method. A scan identifies the 25% of issues it can detect. An audit conducted by an accessibility professional identifies the rest.
Does the Scanner Category Affect WCAG Coverage?
No. Browser-based, API-based, and command-line scanners all operate on the same principle: loading page content and running automated checks against defined rules. The category affects how the scan is deployed and integrated into a workflow, not what percentage of WCAG criteria it can evaluate.
An API-based scanner integrated into a CI/CD pipeline checks the same types of issues as a browser-based scanner running on demand. The delivery mechanism differs, but the 25% detection ceiling applies equally across categories.
Selecting a scan tool based on WCAG 2.1 AA coverage alone provides an incomplete picture, since every category of scanner operates within that same detection boundary.