WCAG 2.2: What the New Accessibility Version Brings

WCAG 2.2 was published as a W3C recommendation on October 5, 2023, adding 9 new criteria to WCAG 2.1. Changes are modest in number but significant in intention: they improve accessibility on mobile and for users with cognitive limitations. For companies working towards EAA 2025 compliance, WCAG 2.1 AA remains the legal minimum; WCAG 2.2 AA is where the bar is heading.

This article covers the 9 new criteria, how they affect existing products, and context vs WCAG 3 (which will take years).

The 9 New Criteria

Level A (minimum)

2.4.11 Focus Not Obscured (Minimum) (AA in 2.2): when an element receives keyboard focus, at least part of it must be visible. Violates: a modal or cookie banner covering the focused element.

2.5.7 Dragging Movements (AA): any drag-requiring functionality must have alternative (click, tap). Violates: drag-only reordering without “up/down” buttons.

2.5.8 Target Size (Minimum) (AA): clickable targets must be at least 24×24 CSS pixels (with exceptions). Many icon buttons and inline links violate.

3.2.6 Consistent Help (A): if your site offers “contact”, “help”, “chat”, they must be in the same consistent location across pages.

3.3.7 Redundant Entry (A): don’t ask users for info already entered in the same session. Login → checkout shouldn’t re-ask address.

3.3.8 Accessible Authentication (Minimum) (AA): login process mustn’t require cognitive skills without alternative (remembering complex passwords, identifying images). Password managers must work.

Level AA

2.4.12 Focus Not Obscured (Enhanced) (AAA): focused element mustn’t be at all obscured. Stricter than 2.4.11.

2.4.13 Focus Appearance (AAA): focus indicator must have minimum 3:1 contrast and sufficient area.

3.3.9 Accessible Authentication (Enhanced) (AAA): even stricter than 3.3.8.

Impact on Existing Products

AA criteria are most compliance-relevant. Most impactful:

Target Size (2.5.8)

Most likely to break your current UI:

Small inline links within text.
16×16 or 20×20 icon buttons.
Small switches/toggles.
Dense pagination links.

Solution: increase to minimum 24×24, or add padding making the clickable area 24×24 (even if visible is smaller).

Dragging Movements (2.5.7)

Any drag-and-drop interface:

Kanban boards (Trello-style).
Reorder lists.
Image croppers.
Custom range sliders.

Solution: add alternative controls (buttons, numeric inputs). Keep drag as preferred but not unique.

Accessible Authentication (3.3.8)

Breaking patterns:

reCAPTCHA v2 with image identification (cognitive).
Password fields blocking paste (password manager).
Custom CAPTCHA with puzzles.

Solution: accessible CAPTCHA (reCAPTCHA v3 silent, Turnstile), allow paste, alternative auth methods (passkey, social).

Focus Not Obscured (2.4.11)

Sticky headers covering focused element on scroll.
Fixed cookie banners at bottom.
Chat widgets covering buttons.

Solution: scroll-margin-top in CSS, z-index management, viewport unit awareness.

Practical Migration from 2.1

If you already meet WCAG 2.1 AA, upgrading to 2.2 AA is manageable:

Audit with 2.2-aware tools: axe-core, Pa11y, WAVE all support 2.2.
Prioritise the 4 new AA criteria:
- 2.4.11 Focus Not Obscured (Minimum)
- 2.5.7 Dragging Movements
- 2.5.8 Target Size (Minimum)
- 3.3.8 Accessible Authentication
Review drag interactions, icon buttons, CAPTCHAs.
Update internal design-system policies.

Typically 1-2 sprints for a mid-size product already accessible to 2.1.

Target Size: Detailed Calculation

Criterion 2.5.8 has nuances:

24×24 CSS pixels is minimum.
Exception: if enough separation (>24px between targets), smaller size is OK.
Exception: target within text block (inline links), though large is recommended.
Exception: if user-agent controlled (browser default).

Quick testing: in DevTools, verify getBoundingClientRect() of clickable elements.

EAA Context

For companies preparing European Accessibility Act 2025:

Legal minimum: EN 301 549 references WCAG 2.1 AA.
Next EN 301 549 revision will incorporate WCAG 2.2 — eventually.
Prudent: target 2.2 AA now to avoid re-auditing when reference changes.

In UK, GDS Service Manual already cites WCAG 2.2 in acceptance criteria.

Updated Tools

WCAG 2.2 support in popular tools:

axe-core 4.8+: 2.2 rules included.
Pa11y: via custom actions.
Lighthouse: partial 2.2 rules from Chrome 120+.
WAVE: updated with 2.2 indicators.
IBM Equal Access Accessibility Checker: complete support.

Cases Where 2.2 Stands Out

Interface types where new criteria most matter:

Mobile web apps: target size and dragging movements.
E-commerce: checkout flows with redundant entry.
B2B SaaS: consistent help and authentication.
Complex dashboards: focus not obscured in sticky navigation.
Form-heavy apps: redundant entry, accessible auth.

WCAG 3: The Horizon

While 2.2 increments, WCAG 3 (codename “Silver”) is a major rewrite:

Scoring model: instead of pass/fail, gradual levels.
More holistic testing: complete user journeys, not isolated criteria.
Broader disability coverage: more cognitive, motor, situational.
Timeline: 2025+ for stable draft; formal adoption years later.

Don’t wait for WCAG 3. Work to 2.2 now.

Cognitive Accessibility: The New Focus

A thread through WCAG 2.2 is cognitive accessibility:

Redundant Entry reduces memory load.
Accessible Authentication eliminates cognitive tests.
Consistent Help reduces cognitive search.

This benefits all users, not just those with cognitive disabilities. But it’s where WCAG historically focused less.

Conclusion

WCAG 2.2 is an incremental but focused update. For teams already meeting 2.1 AA, the jump is manageable and worthwhile — benefits are real, especially on mobile and for users with cognitive load. For companies still working to EAA, targeting 2.2 AA directly is more future-compatible. The standard’s direction is clear: increasing focus on cognitive, mobile, and situational accessibility. Sticking with only visible technical criteria (contrast, ARIA) no longer suffices to be considered an accessible product.