WCAG 2.2 vs 2.1: What Changed and What Your Site Needs to Fix

WCAG 2.2 became a W3C Recommendation in October 2023. If your organization targets WCAG 2.1 AA compliance — the standard referenced in most ADA legal filings and government contracts — you now have nine new success criteria to evaluate. Some are quick wins. Others require significant design changes.

Here's what actually changed, what you can probably ignore, and what's most likely to cause compliance gaps on a typical web app.

What was removed

WCAG 2.2 removed one criterion from 2.1: 4.1.1 Parsing, which required valid HTML. The W3C determined that modern browsers handle malformed HTML gracefully enough that this criterion no longer provides meaningful accessibility protection. If your automated tools still flag 4.1.1, you can safely de-prioritize those results.

The nine new success criteria

2.4.11 — Focus Appearance (Minimum) [AA]

When a UI component has keyboard focus, the focus indicator must have a minimum area of 2 CSS pixels around the unfocused component, with a contrast ratio of at least 3:1 against adjacent colors.

What this means in practice: The default browser focus ring satisfies this on most browsers. Where sites fail is when CSS removes the outline (outline: none) without replacing it with an equivalent indicator. Check every interactive element.

2.4.12 — Focus Appearance (Enhanced) [AAA]

AAA-level enhancement: focus indicator must enclose the component, have at least a 2px offset, and meet a 4.5:1 contrast ratio. Most sites target AA, so this is optional — but it's worth knowing what AAA looks like for future-proofing.

2.4.13 — Focus Appearance [AAA, supercedes 2.4.11 at AA]

In the final WCAG 2.2 spec, 2.4.11 was merged into a consolidated criterion. The practical requirement at AA level: focus indicators need sufficient size and contrast. axe-core and most automated tools now check this.

2.5.7 — Dragging Movements [AA]

Any functionality that uses dragging must have an alternative that doesn't require dragging — using only a single pointer (click or tap). This affects drag-and-drop interfaces, sliders, map panning, and sortable lists.

Common fix: Add up/down arrow buttons alongside drag handles for sortable lists. For sliders, ensure keyboard input (arrow keys) works. Most modal drag implementations don't have a pointer-only alternative.

2.5.8 — Target Size (Minimum) [AA]

Interactive targets must be at least 24×24 CSS pixels. An exception applies when there's sufficient spacing (at least 24px) between smaller targets. This is the minimum; WCAG 2.1's advisory recommendation was 44×44px.

What fails this: Checkbox-only click targets (not the label), inline links in dense text, close buttons in dialogs, and social share icons often fall below 24px.

3.2.6 — Consistent Help [A]

If a help mechanism exists on multiple pages (live chat, contact form, FAQ link, phone number), it must appear in the same relative location across those pages. This is an A-level criterion, meaning it's required at the baseline compliance level.

Most common failure: Help links that appear in the footer on most pages but move to the header on checkout or login pages.

3.3.7 — Redundant Entry [A]

Information already entered by the user in a multi-step process must either be auto-populated or available for the user to select — they shouldn't have to re-enter it. This matters for checkout flows, registration wizards, and multi-step forms.

3.3.8 — Accessible Authentication (Minimum) [AA]

Authentication processes cannot require a cognitive function test (memorizing characters, solving puzzles) unless an alternative method is available, the test is to identify objects, or a mechanism is provided to assist. This effectively requires that CAPTCHA-protected logins have an alternative.

The real-world implication: Image-based CAPTCHAs that require transcription fail this unless there's an audio alternative or a "send me an email link" option. Google reCAPTCHA v3 (invisible, behavior-based) passes. hCaptcha's image challenges require the audio alternative.

3.3.9 — Accessible Authentication (Enhanced) [AAA]

AAA level: no cognitive function tests at all in authentication. Password managers and passkeys are the path to compliance here.

What automated tools can catch

axe-core (which powers Kuality's accessibility scanner and WAVE) automatically detects:

• Focus indicator absence (2.4.11)
• Target size failures below 24px (2.5.8)
• Some CAPTCHA patterns (3.3.8)

These require manual review:

• Dragging alternatives (2.5.7) — requires user flow testing
• Consistent help location (3.2.6) — requires cross-page comparison
• Redundant entry (3.3.7) — requires multi-step flow testing

Roughly 30% of WCAG 2.2 criteria can be caught automatically. The rest require manual testing with a keyboard and screen reader.

Where to start

Run an automated scan first to catch the quick wins — focus indicators and target sizes are mechanical checks that automated tools handle reliably. Then prioritize manual review of your most-used user flows for dragging interactions and multi-step forms.

If you're starting from WCAG 2.1 AA compliance, the highest-risk new requirements are 2.5.8 (target size) and 3.3.8 (authentication) — both are AA-level and the most likely to appear in ADA demand letters targeting WCAG 2.2 conformance.

Kuality runs a full axe-core WCAG 2.2 AA audit on your live site. Scan for free at kuality.io/accessibility-testing.