WCAG 2.2: What's New and What Your Development Team Needs to Know

The short answer: WCAG 2.2, which became the W3C recommended standard in October 2023, adds nine new success criteria and removes one. The most impactful changes for development teams are the strengthened focus indicator requirements, minimum target size rules, and new accessible authentication criteria. Organisations subject to the UK Public Sector Bodies Accessibility Regulations or the European Accessibility Act (EAA) must comply.

Approximately 1 in 5 people in the UK live with a disability—that's 14 million people whose ability to use your product depends on how seriously your team takes accessibility. Beyond the legal obligations, accessible products consistently show improved usability for all users: the Web Accessibility Initiative reports that accessible design improvements benefit users without disabilities too.

What Changed from WCAG 2.1

WCAG 2.2 added nine new success criteria and removed one (4.1.1 Parsing, retired as redundant with modern browser behaviour).

Focus Indicators (2.4.11 and 2.4.12)

Two new criteria strengthen requirements around keyboard focus visibility. 2.4.11 (AA) requires that focus indicators meet minimum size and contrast requirements—the default browser outline is no longer sufficient for compliance. 2.4.12 (AAA) adds even stricter requirements for focus indicator area.

This is one of the most impactful changes for development teams. Many design systems suppress the default focus outline for aesthetic reasons, replacing it with custom indicators that may not meet the new requirements.

Dragging Movements (2.5.7, AA)

All functionality that relies on dragging must also be operable with a single pointer (click/tap). This affects carousels, sliders, drag-and-drop interfaces, and map interactions.

Target Size (2.5.8, AA)

Interactive targets must be at least 24×24 CSS pixels, or have sufficient spacing around them. The AAA criterion (2.5.5) requires 44×44px. This matters for dense interfaces with small action buttons.

Consistent Help (3.2.6, A)

If a help mechanism (chat widget, phone number, FAQ link) appears across multiple pages, it must appear in a consistent location.

Redundant Entry (3.3.7, A)

Information already entered by the user in the same session should not need to be re-entered unless there is a specific reason. This applies to multi-step forms, checkouts, and applications that collect user data across screens.

Accessible Authentication (3.3.8 and 3.3.9)

Cognitive function tests—including CAPTCHAs—cannot be the only method of authentication unless an alternative is provided. This has direct implications for login flows relying on traditional image-based CAPTCHAs.

Practical Compliance Approach

Rather than attempting full compliance in a single sprint, we recommend a phased approach:

1. Audit against 2.2 to establish your current baseline and gap list
2. Prioritise Level A failures as these are the most severe and legally material
3. Address focus indicator issues early—they affect every interactive element and often require design system changes
4. Review form flows for Redundant Entry and Accessible Authentication compliance
5. Test with real assistive technology users—automated tools catch approximately 30–40% of WCAG failures; manual testing with JAWS, NVDA, and VoiceOver is essential for the rest

Key Takeaways

• WCAG 2.2 AA is the legal baseline for UK public sector and EAA-regulated organisations
• Focus indicator changes affect virtually every interactive element on your site
• CAPTCHAs as the sole authentication method no longer meets Level AA compliance
• Automated tools catch only 30–40% of issues—manual testing is required for full coverage