WCAG 2.2 AA: What Actually Changed

WCAG 2.2 AA: What actually changed

The Web Content Accessibility Guidelines 2.2 became a W3C recommendation in October 2023. For organizations subject to Section 508, the European Accessibility Act, or public sector regulations in countries like the UK, it's already the required standard. The NHS, for example, now mandates WCAG 2.2 AA for all patient and staff facing services .

If you've been tracking WCAG 2.1, the transition isn't massive. Nine new success criteria were added, one was removed, and everything else stayed the same. But those nine criteria matter. They address gaps that have frustrated users with cognitive disabilities, low vision, and motor impairments for years.

This article covers what changed, what those changes mean for your sites, and how to implement them.

The big picture: What WCAG 2.2 adds

WCAG 2.2 is backward compatible. If you were compliant with WCAG 2.1 AA, you're almost there. You just need to address the new criteria .

Nine new success criteria total. Six are at A and AA levels, which means they're required for conformance at those levels. Three are AAA, which remain optional enhancements .

The new criteria target three areas:

Cognitive accessibility: Reducing memory burden, providing consistent help, preventing redundant data entry
Motor accessibility: Easier touch targets, alternatives to dragging gestures
Low vision accessibility: Better focus visibility for keyboard navigation

WCAG 2.2 also removed 4.1.1 Parsing. That criterion required valid HTML. The W3C determined it's obsolete because modern browsers handle parsing errors gracefully, and the original intent is now met through other means .

The six criteria you need for AA conformance

If you're targeting WCAG 2.2 AA, you need to meet everything from 2.1 AA plus these six new criteria :

2.4.11 Focus Not Obscured (Minimum) - Level A

What it requires: When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content .

What this means: Sticky headers, fixed footers, chat widgets, and cookie banners can't completely hide the element that currently has keyboard focus. The user must be able to see at least part of what they're focused on .

Why it matters: Imagine tabbing through a page and the focused link disappears behind a sticky header. You have no idea where you are or what you're about to activate. For keyboard users, this is disorienting and can make navigation impossible .

Common failures:

Fixed navigation covering focused links
Chat widgets overlapping form fields
Cookie consent banners hiding footer links
Sticky CTAs covering interactive elements

How to fix it:

css

/* Ensure sticky headers don't cover focused content */ html { scroll-padding-top: 80px; /* Height of your sticky header */ } /* Ensure focused elements scroll into view */ :focus { scroll-margin-top: 100px; /* Creates space above focused elements */ }

The key is to manage scroll position so focused elements appear below any sticky content .

2.4.12 Focus Not Obscured (Enhanced) - Level AA

What it requires: When a component receives keyboard focus, no part of the component is hidden by author-created content .

What this means: This is the stricter version of 2.4.11. The minimum version allows partial obscuring. The enhanced version requires the entire focused element to be visible .

Why it matters: For users with low vision or cognitive disabilities, even partial obscuring can make it hard to understand what's happening. If a button's label is hidden, they might not know what it does .

How to fix it: Same techniques as 2.4.11, but more thorough. You need to audit every sticky element and ensure focused components are completely visible .

2.5.7 Dragging Movements - Level AA

What it requires: All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential .

What this means: If you have drag-and-drop interfaces, sliders, or any functionality that requires clicking, holding, and moving, you need an alternative that works with a single click or tap .

Why it matters: Some people cannot perform dragging movements precisely. Others use specialized input devices like head pointers or eye-gaze systems that make dragging cumbersome or impossible . As the W3C's understanding document explains, dragging requires four discrete actions: press and hold, move to end point, release. Not all users can do that .

Common failures:

Sortable lists requiring drag-and-drop
Image cropping interfaces
Sliders without keyboard or button alternatives
File upload drop zones without click alternatives
Kanban boards with drag-only card movement

How to fix it:

html

<ul role="list" aria-label="Sortable items"> <li> <span>Item 1</span> <button aria-label="Move Item 1 up">↑</button> <button aria-label="Move Item 1 down">↓</button> </li> </ul>  <div role="group" aria-label="Price range"> <button aria-label="Decrease minimum price">−</button> <input type="range" aria-label="Minimum price"> <button aria-label="Increase minimum price">+</button> </div>

The alternative must work with a single pointer action, not just keyboard shortcuts .

2.5.8 Target Size (Minimum) - Level AA

What it requires: The size of the target for pointer inputs is at least 24 by 24 CSS pixels, with specific exceptions .

What this means: Buttons, links, and interactive controls need a minimum touch and click area. If a target is smaller than 24x24, it can still pass if there's enough spacing around it .

Why it matters: Small targets are difficult for users with hand tremors, limited dexterity, or anyone using a touchscreen on a moving bus. WCAG 2.1 had a 44x44 requirement at Level AAA, but that was too strict for most organizations. This brings a smaller, still useful requirement to Level AA .

The exceptions :

Inline: Links within sentences or blocks of text (they reflow, so authors can't control positioning)
Spacing: If a target is smaller than 24x24 but has at least 24 CSS pixels of space between it and adjacent targets, it passes
Essential: When a particular presentation is essential to the information being conveyed (like map pins showing exact locations)
Legal: When legally required to replicate a paper form with specific sizing

How to fix it:

css

/* Ensure minimum target size */ button, a:not(.inline-link), [role="button"] { min-width: 24px; min-height: 24px; } /* Icon buttons need explicit sizing */ .icon-button { width: 44px; /* Even better for touch */ height: 44px; display: inline-flex; align-items: center; justify-content: center; } /* Spacing alternative */ .compact-nav a { padding: 12px; /* Creates 24px+ effective target area */ }

The requirement is independent of page zoom. When users zoom in, CSS pixels stay the same size, so you can't claim it's fine at higher zoom levels .

3.2.6 Consistent Help - Level A

What it requires: If a web page contains help mechanisms (contact details, chat, self-help options) and those mechanisms are repeated on multiple pages, they occur in the same relative order .

What this means: Your help options should be in the same place on every page. If you have a contact link in the footer, it should be in the same position relative to other footer content across the site .

Why it matters: Users with cognitive disabilities rely on consistent patterns. Moving help mechanisms between pages creates confusion and increases cognitive load. When someone needs help, they need to find it immediately, not hunt for it .

How to fix it:

Place help links in consistent header or footer locations
Use consistent labeling ("Help," "Contact Us," "Support")
Maintain the same order when multiple help options exist

3.3.7 Redundant Entry - Level A

What it requires: Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated or available for the user to select .

What this means: Don't make users enter the same information twice. If you need shipping and billing addresses, provide a checkbox to copy them. If you ask for an email on page one and again on page three, pre-fill it .

Why it matters: Re-entering information is frustrating for everyone. For users with memory difficulties, motor disabilities, or those using assistive technologies, it can be a significant barrier .

The exceptions :

Re-entering is essential (like confirming a new password)
The information is required for security
Previously entered information is no longer valid

How to fix it:

html

<input type="checkbox" id="same-address"> <label for="same-address">Billing address same as shipping</label>  <input type="email" value="{{ previouslyEnteredEmail }}" aria-describedby="email-note"> <span id="email-note">Pre-filled from previous step</span>  <input type="text" name="shipping-street" autocomplete="shipping street-address">

3.3.8 Accessible Authentication (Minimum) - Level AA

What it requires: A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one alternative method that does not rely on cognitive function, or a mechanism to assist the user .

What this means: You can't force users to solve puzzles, transcribe text, or remember complex passwords without providing alternatives that don't rely on memory or cognitive ability .

Why it matters: Traditional authentication creates barriers for users with cognitive disabilities, memory impairments, and learning disabilities. CAPTCHAs, in particular, can be impossible for some users .

Compliant alternatives :

Password manager support (proper autocomplete attributes)
Email or SMS authentication codes with copy-paste enabled
Biometric authentication
Physical security keys
OAuth or third-party authentication

What doesn't work: Object recognition tests (select all images with traffic lights) are still cognitive tests. They're allowed under the minimum AA criteria, but they're not ideal .

How to fix it:

html

<input type="email" autocomplete="username email" aria-label="Email address"> <input type="password" autocomplete="current-password" aria-label="Password">  <input type="text" inputmode="numeric" autocomplete="one-time-code" aria-label="6-digit verification code">  <div role="group" aria-label="Verification"> <p>Please complete one verification method:</p> <button>Audio CAPTCHA</button> <button>Email verification code</button> </div>

The three AAA criteria

WCAG 2.2 also added three Level AAA criteria. Most organizations won't need these for compliance, but they're worth understanding:

2.4.13 Focus Appearance - Level AAA

Requires focus indicators to have a specific size (at least as large as a 2px thick perimeter of the element) and contrast (at least 3:1 between focused and unfocused states) . The UK government's design system pattern of a yellow background with black underline fails this, because it doesn't extend to a 2px perimeter and the contrast on white backgrounds is below 3:1 .

3.3.9 Accessible Authentication (Enhanced) - Level AAA

Requires no cognitive function test for any step of authentication. Even object recognition and personal content recognition aren't allowed .

What was removed: 4.1.1 Parsing

WCAG 2.2 removes Success Criterion 4.1.1 Parsing, which required HTML to be well-formed with complete start and end tags, proper nesting, and no duplicate attributes .

The W3C determined this criterion is obsolete because:

Modern browsers handle parsing errors gracefully
Assistive technologies work with browser DOMs, not raw HTML
Validation errors rarely cause accessibility failures
Automated tools flagged many parsing errors that caused no actual barriers

This doesn't mean you should write invalid HTML. Valid HTML remains a best practice. But it's no longer a WCAG requirement.

Implementation priorities

If you're moving from WCAG 2.1 AA to 2.2 AA, address these criteria in order :

Focus Not Obscured - Quick wins adjusting scroll padding and margins
Target Size - Audit button and link sizes, fix the small ones
Redundant Entry - Review multi-step forms for repeated fields
Dragging Movements - Add alternatives to drag-and-drop interfaces
Accessible Authentication - Review login flows and add support for password managers
Consistent Help - Check help placement across pages

The NHS service manual provides a good summary: "Your service must meet WCAG 2.2. The Government Digital Service, Department of Health and Social Care and NHS England are now monitoring accessibility to WCAG 2.2" .

That's the reality. These aren't theoretical future requirements. They're being enforced now.

WCAG 2.2 AA: What Actually Changed