What's new in WCAG 2.2? The 9 new criteria in plain English

Someone using a keyboard tabs through your checkout. Focus lands on the “Pay now” button, but a sticky cookie banner sits on top of it, so they can't see where they are. Under WCAG 2.1 that page could still pass. Under WCAG 2.2 it fails.

That's the kind of gap the 2.2 update closes. Below, each new success criterion gets the same treatment: what it says, who it helps, a quick test and the usual fix. For the four principles and the levels on one page, see our WCAG 2.2 reference.

What is WCAG 2.2?

WCAG 2.2 is the current version of the Web Content Accessibility Guidelines, the W3C standard that most accessibility laws and contracts point to. It became a W3C Recommendation on 5 October 2023 (opens in a new tab), was updated on 12 December 2024 (opens in a new tab), and was approved as ISO/IEC 40500:2025 (opens in a new tab) in October 2025.

WCAG is made of testable statements called success criteria, each with a level: A (the minimum), AA (what laws usually ask for) or AAA (the strictest). “We need WCAG 2.2 AA” means every A and AA criterion in version 2.2. The specification says 2.2 “builds on and is backwards compatible with WCAG 2.1”, so it adds to 2.1 rather than replacing it.

What changed from WCAG 2.1 to 2.2?

WCAG 2.2 adds nine success criteria and removes one. Six of the new ones are Level A or AA, so they count towards the usual AA target: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 and 3.3.8. The other three are AAA. The removed criterion is 4.1.1 Parsing, which W3C now describes as obsolete.

4.1.1 Parsing checked for markup errors such as duplicate IDs. The WCAG 2 FAQ (opens in a new tab) explains that those problems now fall under other criteria, such as 4.1.2 Name, Role, Value. One catch: if a contract still requires WCAG 2.0 or 2.1, you “may need to continue to test and report 4.1.1”.

Focus Not Obscured and Focus Appearance: can keyboard users see where they are?

These criteria keep the element with keyboard focus visible. At Level AA (2.4.11), a focused link or button must not be entirely hidden by content you added, such as a sticky header, cookie banner or chat bubble. At AAA, nothing may cover any part of it (2.4.12), and the focus outline must be large and clearly contrasting (2.4.13).

• Who it helps: sighted people who use a keyboard instead of a mouse, often because of a motor disability. If they can't see focus, they're guessing.
• Quick test: load a long page with the cookie banner, sticky header and chat widget all showing, then press Tab repeatedly. If focus disappears completely behind something, that's a 2.4.11 failure.
• Common fix: add CSS scroll padding equal to the height of your sticky header or footer, so the browser scrolls focused items clear of it. W3C lists this as a sufficient technique (opens in a new tab). A banner can also pass if it's modal and must be dismissed first.

Focus Appearance (2.4.13) asks for an indicator at least as large as a 2 CSS pixel thick outline around the component, with a contrast change of at least 3:1 between focused and unfocused states. It's AAA, but a solid 2-pixel outline in a strong colour usually gets you there. Our guide to colour contrast explains how to measure 3:1.

Dragging Movements and Target Size: can people use your site without precise pointing?

These two Level AA criteria help people who find fine pointer control hard. 2.5.7 says anything you can do by dragging must also work with single clicks or taps. 2.5.8 says targets must be at least 24 by 24 CSS pixels, or spaced so that a 24-pixel circle centred on each one doesn't touch another target.

2.5.7 Dragging Movements

Think of a price-range slider in a shop's filters or a wishlist you reorder by dragging. For someone with a tremor, or someone using a head pointer, press-hold-move-release can be very hard.

Quick test: finish each dragging task with clicks or taps only. Common fix: let people click anywhere on a slider track, add “min” and “max” boxes next to it, or add “Move up” and “Move down” buttons to sortable lists. Keyboard support alone isn't enough: W3C's Understanding document (opens in a new tab) says keyboard equivalence “does not automatically meet this success criterion”.

2.5.8 Target Size (Minimum)

The usual failures are small “×” buttons on pop-ups, tightly packed page numbers, star ratings and rows of social icons. Tapping the wrong one is irritating for anyone and a real barrier for people with limited dexterity.

• Exceptions: links inside a sentence, targets with an equivalent control elsewhere on the page that meets the size, controls sized by the browser that you haven't restyled, and cases where a particular size is essential or legally required.
• Quick test: on a phone, try every small icon and button; to measure one, inspect it in your browser's developer tools.
• Common fix: add padding. The clickable area grows even if the icon looks the same. And treat 24 pixels as a floor: the older AAA criterion 2.5.5 asks for 44 by 44.

Consistent Help and Redundant Entry: are you making people hunt or repeat themselves?

Both are Level A. 3.2.6 Consistent Help says that if help such as contact details, a chat or an FAQ link appears on several pages, it must sit in the same order relative to the rest of the page each time. 3.3.7 Redundant Entry says people shouldn't have to re-type information they've already given in the same process.

Consistent Help doesn't oblige you to offer help at all. It only says that if the phone number sits in the header on product pages, it shouldn't move to the footer at checkout, where people most need it. People with memory or attention difficulties benefit most. The fix is usually a shared template rather than placing help page by page.

Redundant Entry targets multi-step forms. A booking form that asks for your email on step 1 and again on step 3 fails, and so does a checkout that makes you retype an identical billing address. Fill the field automatically or let people select it, for example with a “Billing address is the same as delivery” checkbox. The exceptions: re-entry is essential, needed for security, or the earlier information is no longer valid.

Accessible Authentication: can people log in without a memory test?

Success criterion 3.3.8 (Level AA) says no step of logging in may rely on a cognitive function test, such as remembering a password, typing distorted characters or solving a puzzle, unless you offer an alternative or something that helps. In practice: let password managers fill the fields, allow pasting, and offer a method that doesn't depend on memory.

WCAG defines a cognitive function test as “a task that requires the user to remember, manipulate, or transcribe information”. Entering your name, email address or phone number doesn't count, because those are personal to you and the same everywhere. A login step passes at AA if it offers at least one of these:

• An alternative method without a cognitive test, such as a passkey or an email link.
• A mechanism that helps, such as support for password managers, or copy and paste so a one-time code doesn't have to be retyped.
• Object recognition, for example “select the pictures with a bicycle”.
• Personal content, such as identifying a picture you uploaded yourself.

The AAA version, 3.3.9, drops the last two options, so an image CAPTCHA can pass at AA but not at AAA. Typical failures: password fields that block pasting or password managers, one-time code boxes that break when you paste, and a text CAPTCHA with no alternative. People with dyslexia or memory impairments gain the most, but anyone locked out after a long day will recognise the problem.

Is WCAG 2.2 legally required?

It depends on where you are and who you are. Laws rarely name a WCAG version directly, and several still point to WCAG 2.1 AA. Because WCAG 2.2 is backwards compatible, meeting 2.2 AA also meets 2.1 AA, apart from the removed 4.1.1. Aiming for 2.2 covers both. If a contract names a version, follow the contract.

• European Union: under the European Accessibility Act, conformity is presumed when you meet the harmonised standard EN 301 549. According to AccessibleEU (opens in a new tab), version 4.1.1, published in September 2026, adopts WCAG 2.2 but isn't yet the legal reference; until it's cited in the Official Journal, v3.2.1 (based on WCAG 2.1 AA) applies. Our European Accessibility Act explainer covers who the act applies to.
• United Kingdom: government guidance (opens in a new tab) says public sector websites and apps must meet WCAG 2.2 AA. That guidance covers public bodies, not private businesses.
• United States: the Department of Justice rule for state and local governments uses WCAG 2.1 AA, with compliance dates moved in April 2026 (opens in a new tab) to 26 April 2027 and 26 April 2028. For private businesses, the Department's 2022 guidance (opens in a new tab) says the ADA applies to their websites but sets no specific technical standard.

What about WCAG 3?

WCAG 3 is a draft, so nobody can conform to it yet. W3C published updated drafts in September 2026 and says WCAG 3 isn't expected to be a completed standard “for a few more years”. WCAG 2 won't be deprecated for several years after that, so 2.2 is the version to work to now.

How can you check the new criteria in 15 minutes?

You can spot most failures of the six A and AA criteria in about 15 minutes with a keyboard, a phone and your own login page. It won't replace a full audit or testing with disabled people, but it tells you where to start and gives a developer a concrete list to work from.

1. Tab through your home page, a product page and your checkout with every banner showing. Can you always see focus? (2.4.11)
2. Finish every slider or drag-and-drop task with clicks or taps only. (2.5.7)
3. On a phone, try every close button, page number and small icon. (2.5.8)
4. Compare where help and contact details appear on three page types. (3.2.6)
5. Go through a purchase or booking and note any question you answer twice. (3.3.7)
6. Log in with a password manager, then paste a password and a one-time code. Does any CAPTCHA have an alternative? (3.3.8)

For the rest of WCAG, our guide on how to test your website's accessibility covers free tools and manual checks, and our website accessibility checklist turns common failures into a to-do list. Anything you can't fix yet belongs in your accessibility statement.

A note on widgets, including ours: none of these criteria can be met from a visitor-side panel. A large cursor makes small targets easier to aim at, but it doesn't make them 24 pixels wide, and highlighting focus doesn't move a sticky banner out of the way. Every new criterion is about how your pages are built, so the fix lives in your templates and code.