The WCAG 2.1 vs 2.2 scans difference comes down to the rule set the scanner checks against. A 2.1 scan evaluates pages against the success criteria in WCAG 2.1, while a 2.2 scan adds the criteria introduced in WCAG 2.2. The mechanics of scanning do not change. What changes is the checklist the scanner uses, and a small portion of the new 2.2 criteria can be partially evaluated through code inspection. Scans still detect roughly 25% of accessibility issues regardless of which version is selected.
| Key Point | What It Means |
|---|---|
| Rule Set | 2.2 scans check against a superset that includes 2.1 criteria plus newer additions. |
| Backwards Compatible | WCAG 2.2 includes all 2.1 criteria, so a 2.2 scan covers everything a 2.1 scan covers. |
| Coverage Rate | Both versions are limited to about 25% automated detection of accessibility issues. |
| New 2.2 Criteria | Most new criteria require human evaluation; only a few have any code-level signals scanners can flag. |
How Scan Versions Work
An accessibility scan loads a page and evaluates HTML, CSS, and ARIA against a defined set of success criteria. The version selected, 2.1 AA or 2.2 AA, determines which criteria the scanner attempts to check.
WCAG 2.2 is backwards compatible with 2.1. Any page that conforms to 2.2 also conforms to 2.1. Scanners reflect this by treating 2.2 as a superset, adding checks for the new criteria on top of the existing 2.1 rule base.
What Changes With a 2.2 Scan
The newer criteria in WCAG 2.2 focus heavily on user interaction patterns, target sizing, focus appearance, and authentication. Most of these require observation of how a real user moves through the page, which scanners cannot replicate.
A few of the new criteria do produce signals scanners can partially flag. Target size has measurable dimensions in code. Focus visibility has CSS properties that can be inspected. These are partial signals, not conformance verdicts. A scanner can report that a button measures below a certain pixel threshold, but it cannot confirm whether the criterion is met in context.
What Stays the Same
The 25% coverage limit applies to both versions. A 2.2 scan does not detect more issues as a percentage; it checks against a larger rule set, but the share of criteria that can be evaluated through code alone remains roughly the same.
The categories of issues scanners detect well are unchanged: missing alternative text, form labels tied to inputs, document language declarations, ARIA role validity, heading structure, and similar code-level patterns. These checks behave identically whether the scan is set to 2.1 or 2.2.
Choosing a Version for Scanning
Organizations selecting a scan version usually align with the conformance target referenced in their accessibility statement, contract, or applicable rule. Title II of the ADA references WCAG 2.1 AA. Many procurement requests now reference 2.2 AA. The version chosen for scanning should match the version the organization is conforming to.
Running a 2.2 scan on a site targeting 2.1 conformance produces extra flags that may not be relevant. Running a 2.1 scan on a site targeting 2.2 misses the newer checks entirely. The selection is a configuration decision, not a quality decision.
Why Version Selection Is Not the Limiting Factor
The version setting on a scanner is a smaller variable than the inherent limit of automated evaluation. A 2.2 scan with zero flagged issues does not indicate conformance with WCAG 2.2. It indicates that the scanner found nothing within the 25% of criteria it can evaluate.
A complete picture of conformance, at either version, requires a manual audit that includes screen reader testing, keyboard testing, visual inspection, and code review. The scan version determines the rule set; the evaluation method determines whether issues are actually identified.
Selecting 2.1 or 2.2 for a scan is a matter of matching the scanner’s rule set to the conformance target. The coverage ceiling and the need for human evaluation hold steady across both versions.