WCAG 2.2: the nine new success criteria and what they change on real websites

Where WCAG 2.2 fits

The Web Content Accessibility Guidelines are the reference standard for web accessibility. Version 2.0 was published in 2008 and version 2.1 in 2018. WCAG 2.2 was published as a W3C Recommendation on 5 October 2023 and builds directly on 2.1: content that conforms to WCAG 2.2 also conforms to the earlier versions, apart from the one criterion that was removed.

Legal requirements often point to a particular version, either directly or through a technical standard. In Europe, the harmonised standard EN 301 549 has referenced WCAG 2.1 at level AA, and a revision aligned with WCAG 2.2 has been in preparation. Organisations planning new websites or redesigns now generally aim for WCAG 2.2 AA, because it includes everything in 2.1 and addresses problems users face today.

Accessibility obligations have also widened. The European Accessibility Act brought many consumer-facing digital services, including e-commerce and banking services, under accessibility requirements from June 2025. Designing to the current version avoids fixing the same components twice.

The criterion that was removed

Success criterion 4.1.1 Parsing was removed. It required markup to be well formed, which mattered when assistive technologies parsed HTML directly. Modern browsers and assistive technologies handle markup errors in consistent ways, so the criterion no longer protected users in practice. W3C also published a note that 4.1.1 should be treated as always satisfied for WCAG 2.0 and 2.1.

Removing it does not make invalid HTML a good idea. Broken markup can still cause accessibility failures, but those failures are now captured by other criteria, such as those on names, roles and values.

New criteria at level A and AA

Six of the nine new criteria are at levels A or AA, which are the levels most policies and laws require. Each one maps to recognisable problems on everyday websites.

2.4.11 Focus Not Obscured (Minimum), AA

When a component receives keyboard focus, it must not be entirely hidden by content the site itself added, such as sticky headers, chat widgets or cookie banners.

2.5.7 Dragging Movements, AA

Any function that uses dragging, such as sliders, sortable lists or map panning, must also work with a single pointer without dragging, unless dragging is essential.

2.5.8 Target Size (Minimum), AA

Pointer targets must be at least 24 by 24 CSS pixels, with exceptions for adequate spacing, inline links in text, equivalent controls elsewhere, browser-controlled elements and essential presentations.

3.2.6 Consistent Help, A

Where help mechanisms such as contact details, a contact form or a chat appear on multiple pages, they must be in the same relative order on each page.

3.3.7 Redundant Entry, A

Information a user already entered in the same process must be filled in automatically or available to select, instead of being typed again, with exceptions for security and essential re-entry.

3.3.8 Accessible Authentication (Minimum), AA

Logging in must not depend on a cognitive function test, such as remembering a password or solving a puzzle, unless an alternative or assistance is available, for example allowing password managers and paste.

New criteria at level AAA

Three criteria were added at level AAA. Few organisations commit to full AAA conformance, but these criteria are useful design targets.

2.4.12 Focus Not Obscured (Enhanced) requires that no part of a focused component is hidden by author-created content. 2.4.13 Focus Appearance sets a measurable standard for the visible focus indicator, including a minimum area and a contrast of at least 3:1 between focused and unfocused states. 3.3.9 Accessible Authentication (Enhanced) removes the exceptions for object recognition and personal content that the minimum version allows.

Where real websites usually fail

Sticky headers and cookie banners are the most frequent cause of focus problems. A keyboard user tabs down a page and the focused link disappears behind a fixed header or a consent banner at the bottom of the screen. Scroll padding in CSS, banners that do not cover content, and testing with the keyboard alone solve most of these cases.

Target size problems appear in icon-only buttons, social links, carousel dots, close buttons on modals and tightly packed navigation on mobile. Increasing the clickable area or the spacing between targets usually fixes the issue without changing the visual design much.

Login and checkout forms often break the authentication and redundant entry criteria. Blocking paste into password fields, requiring users to retype an email address, or asking for a delivery address again as a billing address without an option to reuse it all create barriers. Supporting password managers, passkeys, magic links and address reuse helps everyone, not only users with disabilities.

Help mechanisms move around more than teams realise. A phone number in the header on one template and in the footer on another, or a chat button that appears only on some pages, can fail consistent help. Defining help placement in the design system prevents it.

A practical way to adopt WCAG 2.2

Start with components rather than pages. Most accessibility issues live in shared elements: headers, navigation, buttons, form fields, modals, banners, carousels and login flows. Fix them in the design system and component library, and every page using them improves.

Combine automated and manual testing. Automated tools catch missing labels, contrast failures and some target size issues, but focus visibility, dragging alternatives, consistent help and authentication flows need manual checks with a keyboard, a screen reader and a touch device.

Finally, write the requirements into briefs and acceptance criteria for new work. Agencies, developers and content editors should know that a new slider must work without dragging and that a new sticky element must not cover focused content. It is far cheaper to build it correctly than to audit and repair it later.

Where this sits in what we do

This article covers one decision inside a wider engagement. The solution page sets out how that engagement runs, what it includes and what it costs to find out.

• Digital Growth — The ongoing programme — strategy, content, paid, organic and reporting — run as one thing that answers to pipeline rather than to channel dashboards.
• Quote to cash without re-keying: where the handoffs break
• Product data is the e-commerce growth lever nobody budgets for
• Webhooks or polling: designing integrations between business systems that do not lose data
• Moving a website, email or domain without downtime: the DNS steps that usually go wrong
• All insight articles