Standards
WCAG 2.1 vs WCAG 2.2: What Changed for Audit Readiness
A practical guide for audit buyers comparing WCAG 2.1 and WCAG 2.2, including new success criteria, scope updates, evidence expectations, and remediation planning.
Quick answer: what changed from WCAG 2.1 to WCAG 2.2?
WCAG 2.2 is an update to Web Content Accessibility Guidelines that builds on WCAG 2.1. W3C explains that WCAG 2.2 adds 9 success criteria since WCAG 2.1, while the existing 2.0 and 2.1 success criteria are essentially the same in 2.2, with one major exception: 4.1.1 Parsing is obsolete and removed from WCAG 2.2.
For audit buyers, the practical question is not only what changed in the standard. The question is what needs to change in audit scope, testing evidence, remediation planning, design-system review, and retest criteria.
WCAG 2.2 does not replace audit discipline
Moving from WCAG 2.1 to WCAG 2.2 does not mean teams can ignore existing accessibility fundamentals. Keyboard access, labels, contrast, headings, forms, error handling, ARIA use, and assistive technology behavior still matter.
The update adds more explicit coverage for issues that often affect people with low vision, cognitive disabilities, motor disabilities, touch input needs, and authentication barriers.
The new WCAG 2.2 criteria audit buyers should understand
A WCAG 2.2 audit should account for the new success criteria introduced after WCAG 2.1. Some criteria are Level A or AA and therefore matter directly for most AA audit scopes. Others are Level AAA and may be used selectively or as advisory enhancements.
- 2.4.11 Focus Not Obscured (Minimum) at Level AA.
- 2.4.12 Focus Not Obscured (Enhanced) at Level AAA.
- 2.4.13 Focus Appearance at Level AAA.
- 2.5.7 Dragging Movements at Level AA.
- 2.5.8 Target Size (Minimum) at Level AA.
- 3.2.6 Consistent Help at Level A.
- 3.3.7 Redundant Entry at Level A.
- 3.3.8 Accessible Authentication (Minimum) at Level AA.
- 3.3.9 Accessible Authentication (Enhanced) at Level AAA.
What changes for WCAG 2.2 AA audit scope
If the target is WCAG 2.2 AA, the practical additions include Level A and AA criteria from WCAG 2.2. Buyers should expect review coverage around focus not being hidden, alternatives to dragging, minimum target size, consistent help, avoiding unnecessary repeated entry, and accessible authentication.
These checks often touch real product workflows, not just static pages. Login, account setup, forms, help flows, carousels, maps, sliders, drag-and-drop interfaces, and mobile-friendly controls may need closer review.
- Review focus visibility when sticky headers, modals, cookie banners, chat widgets, or overlays are present.
- Check whether dragging actions have non-dragging alternatives.
- Review small buttons, icons, controls, and touch targets against minimum target-size expectations.
- Check whether help mechanisms appear consistently when repeated across pages.
- Review forms for repeated-entry issues that create unnecessary burden.
- Test authentication flows for cognitive and assistive technology barriers.
What happened to 4.1.1 Parsing?
W3C notes that 4.1.1 Parsing is obsolete and removed from WCAG 2.2. This does not mean code quality, semantic structure, or assistive technology compatibility no longer matter. It means audit reports should avoid treating 4.1.1 as an active WCAG 2.2 success criterion.
Issues that previously appeared under parsing may still be relevant when they cause real accessibility failures, but they should be mapped to the appropriate active criterion and user impact.
How audit evidence should change
A WCAG 2.2 audit report should make the version and target level explicit. If the report is for WCAG 2.2 AA, findings should map to WCAG 2.2 criteria and should distinguish whether a finding relates to existing WCAG 2.1 coverage or a new WCAG 2.2 requirement.
Evidence should be practical enough for remediation teams to reproduce the issue and verify closure later.
- Name the WCAG version and conformance target in the report.
- Identify whether the finding relates to a new WCAG 2.2 criterion.
- Capture screenshots, steps, component states, URLs, device context, or assistive technology notes where useful.
- Document expected accessible behavior, not only the failure label.
- Use the same WCAG version and scope during retesting.
What teams should prepare before moving to WCAG 2.2
Teams preparing for WCAG 2.2 should review high-impact journeys before the audit starts. The most useful preparation is not a broad statement that the site is ready, but a clear inventory of components, forms, authentication flows, help patterns, and interaction models that may trigger the new checks.
Design systems also need attention because target size, focus visibility, help patterns, and drag alternatives often live in reusable components.
- List login, registration, account recovery, and multi-factor authentication journeys.
- Identify drag-and-drop, slider, map, upload, reorder, or gesture-heavy interactions.
- Review small icon buttons and touch controls in design-system components.
- Check sticky headers, overlays, modals, banners, and widgets that may obscure focus.
- Inventory repeated forms where users may be asked to re-enter the same information.
- Clarify whether AAA checks are advisory or in formal scope.
Common mistakes during WCAG 2.2 transition
The transition from WCAG 2.1 to WCAG 2.2 is often mishandled when teams treat it as a simple label update. A report should not say WCAG 2.2 AA unless the testing scope, evidence model, and criteria mapping actually reflect WCAG 2.2.
Another common mistake is relying only on automated scans. Several WCAG 2.2 checks require manual review of behavior, context, and user journey impact.
- Changing the report title from 2.1 to 2.2 without updating test coverage.
- Ignoring authentication, forms, focus behavior, and touch controls.
- Treating AAA criteria as required without confirming scope.
- Continuing to map WCAG 2.2 findings to obsolete 4.1.1 Parsing.
- Expecting automated tools to fully prove WCAG 2.2 AA readiness.