WCAG 2.1 vs WCAG 2.2: What Changed and Why It Matters

Quick summary: what changed in WCAG 2.2

WCAG 2.2, published as a W3C Recommendation in October 2023, added 9 new success criteria and removed 1 existing criterion (4.1.1 Parsing). All existing WCAG 2.1 criteria remain in force. WCAG 2.2 is backwards compatible.

The removed criterion: 4.1.1 Parsing

WCAG 4.1.1 required that HTML be well-formed and parseable. It was removed because modern browsers handle malformed HTML gracefully and robustly, meaning the criterion no longer meaningfully improves accessibility. If you were testing for 4.1.1, you can stop — it's no longer part of the standard.

The 9 new success criteria: full detail

2.4.11 Focus Not Obscured (Minimum) — Level AA

Requirement: When a user interface component receives keyboard focus, it must not be entirely hidden by other content.
Most common failure: Sticky navigation bars or cookie banners that sit on top of focused elements.

2.4.12 Focus Not Obscured (Enhanced) — Level AAA

Requirement: The focused component must be fully visible — no part obscured.
Going further than 2.4.11: 2.4.11 requires it's not entirely hidden; 2.4.12 requires it's entirely visible.

2.4.13 Focus Appearance — Level AA

Requirement: Focus indicators must meet minimum size (area ≥ the perimeter of the component × 2px) and contrast (3:1 against adjacent colours) requirements.
Most common failure: Focus outlines with insufficient contrast (e.g. grey on white) or focus styles that are too thin to see.

2.5.7 Dragging Movements — Level AA

Requirement: Any functionality using a dragging motion must also be achievable by a single pointer action.
Most common failure: Sortable lists, sliders, or map controls that require drag and have no keyboard or single-click alternative.

2.5.8 Target Size (Minimum) — Level AA

Requirement: Interactive targets must be at least 24×24 CSS pixels, or have sufficient spacing from adjacent targets that the effective target area meets the requirement.
Most common failure: Icon-only buttons, small checkboxes, and inline text links that are too small to tap reliably.

3.2.6 Consistent Help — Level A

Requirement: If a help mechanism (phone number, email link, live chat, FAQ link) appears on multiple pages, it must appear in the same relative location on each page.
Most common failure: Help links in the header on some pages but the footer on others.

3.3.7 Redundant Entry — Level A

Requirement: In multi-step processes, information previously entered by the user must not be required again unless re-entry is essential or a security requirement.
Most common failure: Multi-page checkout forms that ask for the same billing information the user entered on a previous step.

3.3.8 Accessible Authentication (Minimum) — Level AA

Requirement: Authentication must not rely on cognitive function tests (puzzles, CAPTCHAs transcribing distorted text, memory tasks) unless an alternative is available.
Most common failure: Image-based CAPTCHAs with no audio alternative or no option to request human review.

3.3.9 Accessible Authentication (Enhanced) — Level AAA

Requirement: No cognitive function tests in authentication, period — even with alternatives.
Going further: At AAA, there's no acceptable fallback for cognitively inaccessible authentication.

What do you need to update?

If your site currently meets WCAG 2.1 AA, review these specific items for WCAG 2.2 AA compliance:

1. Check all sticky/fixed UI elements against Focus Not Obscured (2.4.11)
2. Audit focus indicator size and contrast against 2.4.13
3. Review interactive controls for minimum target size (2.5.8)
4. Check for any dragging functionality without a single-pointer alternative (2.5.7)
5. Verify help mechanisms appear consistently across pages (3.2.6)
6. Audit multi-step forms for redundant entry requirements (3.3.7)
7. Review your authentication flow for cognitive test dependency (3.3.8)

Use the RedQA Accessibility Scanner for automated detection, or contact us for a full WCAG 2.2 compliance audit.