WCAG 2.2: What's New and How to Test for It

WCAG 2.2 became an official W3C Recommendation in October 2023, bringing nine new success criteria that address gaps in mobile accessibility and support for cognitive disabilities. If you're still testing against WCAG 2.1, it's time to understand what changed and why it matters for real users.

What Changed in WCAG 2.2

The update adds nine new success criteria: six at Level A covering the most basic requirements, two at Level AA representing the standard compliance target most organizations aim for, and one at Level AAA for enhanced accessibility. The W3C also removed 4.1.1 Parsing, which became obsolete as modern browsers now handle HTML parsing issues automatically. These changes emerged from years of feedback showing that WCAG 2.1 missed critical barriers, particularly for mobile users and people with cognitive disabilities.

Understanding Focus Visibility: Three New Criteria

WCAG 2.2 introduces three related criteria about focus indicators, escalating from minimum requirements to enhanced standards.

Focus Not Obscured (Minimum) arrives as a Level AA requirement addressing a frustration that keyboard users face daily. When you tab through a page, focused elements must remain at least partially visible rather than being completely hidden by sticky headers, cookie consent banners, or chat widgets. Test by tabbing through every interactive element while sticky elements are present; if focused items disappear completely behind fixed headers or overlays, you're failing. Fixes involve adding scroll margin to account for sticky headers, ensuring modals manage focus properly, and using CSS properties like `scroll-padding-top` to create buffer space.

Focus Not Obscured (Enhanced) takes the same concept to Level AAA by requiring focused components to be fully visible, not just partially. The testing approach mirrors the minimum version, but your threshold becomes stricter: any obstruction at all constitutes a failure.

Focus Appearance rounds out the trio as another Level AAA criterion with specific technical requirements. Focus indicators must have an area at least as large as a 2-pixel perimeter around the focused element, and the contrast ratio between focused and unfocused states must reach at least 3:1. Testing this requires actually measuring indicator thickness and checking contrast ratios with color tools. Many default browser focus styles fail this criterion, which explains why custom focus indicators often work better for users.

Mobile Interaction: Dragging and Touch Targets

Two Level AA criteria in WCAG 2.2 directly address mobile accessibility challenges that barely existed when earlier WCAG versions were written.

Dragging Movements requires that any functionality using drag operations must also work with single pointer actions that don't involve dragging. This matters because users with motor impairments, tremors, or those using alternative input devices often cannot execute drag gestures reliably. A drag-to-reorder list needs up and down buttons, a drag-to-resize interface needs input fields where users can type dimensions, and a drag-to-draw tool needs a click-to-place-points alternative. Test by identifying every drag operation, then verifying that each has an alternative method that works with keyboard and single clicks.

Target Size (Minimum) establishes that interactive targets must measure at least 24x24 CSS pixels, with exceptions for adequately spaced targets, equivalent larger alternatives, inline text targets, user agent-determined sizes, or legally required specific sizes. When testing, measure actual clickable areas including padding, check spacing between adjacent interactive elements, and verify mobile touch targets meet the threshold. Common fixes include increasing padding on small buttons, adding spacing between crowded elements, and aiming for 44x44 pixels on primary touch targets.

Cognitive Support: Help, Entry, and Authentication

Three criteria address cognitive disabilities and memory challenges, making interfaces work better for users who struggle with information retention and complex interactions.

Consistent Help is a Level A requirement stating that help mechanisms (contact information, help chat widgets, FAQ links, support phone numbers) must appear in the same relative location across pages. Test by identifying what help you provide and visiting multiple pages to confirm consistent placement. This consistency helps users with cognitive disabilities who struggle to find help if its location changes unpredictably.

Redundant Entry tackles a frustration that affects everyone but particularly burdens users with cognitive and memory disabilities. Information a user has already entered should be auto-populated or selectable rather than requiring manual re-entry, with exceptions for essential re-entry like password confirmation, security requirements, or invalid previous information. Test by completing multi-step forms to verify data persistence and appropriate auto-fill of address and contact information.

Accessible Authentication (Minimum) represents a Level AA requirement that authentication methods shouldn't demand cognitive function tests (remembering passwords without paste, solving puzzles, transcribing distorted characters) unless alternatives exist. Compliant approaches include allowing password paste for password managers, providing email or SMS authentication codes, supporting biometric authentication, and offering OAuth or SSO options. Test by attempting to authenticate without memorizing anything and verifying that password paste and alternative methods work.

Implementation Strategy for AA Compliance

Most organizations target Level AA compliance. Prioritize strategically by starting with target sizes across all interactive elements, then identifying dragging operations and providing alternatives. Next, check how sticky elements and overlays affect focus visibility, review multi-step forms for redundant entry issues, and enable password paste with authentication alternatives. This order reflects both frequency and user impact: target size and focus obscured problems appear on nearly every interface and affect all keyboard users, while dragging alternatives and authentication issues appear less frequently but completely block users when missing.

The Testing Reality

Most WCAG 2.2 criteria require manual testing. Automated tools can help measure target sizes, calculate focus indicator contrast, and check basic structural patterns, but they cannot verify that dragging alternatives function correctly, evaluate authentication options, or confirm help location consistency. These judgments require human testers who understand the user experience and can assess whether alternatives truly meet user needs.

Timeline and Legal Context

WCAG 2.2's status as a W3C Recommendation since October 2023 doesn't mean immediate legal requirements. US Section 508 still references WCAG 2.0 with updates pending. The EU Web Accessibility Directive may adopt 2.2 in future updates. However, private litigation increasingly references WCAG 2.2 as the current standard of care.

We recommend testing against 2.2 now even if your legal requirement is technically still 2.1. The new criteria address real user barriers that affect your actual users today, not theoretical compliance points. When we run WCAG 2.2 scans through Auditi, we consistently find issues that 2.1 testing would miss but that significantly impact how people interact with interfaces. Testing to the current standard isn't just about legal protection; it's about building products that work for everyone.