WCAG 2.2 changes: what's new since WCAG 2.1, how to test each new criterion and which version laws require

The short answer

WCAG 2.2 adds nine success criteria to WCAG 2.1 and removes one, 4.1.1 Parsing. Six of the new criteria are at Levels A and AA, the levels laws and contracts ask for: focus not hidden behind sticky content, an alternative to dragging, pointer targets of at least 24 by 24 CSS pixels, help in a consistent place, no re-entering the same information, and sign-in without memory or puzzle tests. The other three are at Level AAA.

It's an extension, not a rewrite. The W3C says content that conforms to WCAG 2.2 also conforms to 2.1 and 2.0, so a site that meets 2.1 AA needs to be tested only against the six new A and AA criteria to reach 2.2 AA. Most US and EU rules still name WCAG 2.1 or 2.0, but 2.2 AA satisfies them, with one caveat on 4.1.1 covered below.

This guide was checked against the W3C's texts, US federal regulations, ETSI and government sites on 17 October 2026. Where it mentions laws, it is a planning summary, not legal advice.

WCAG 2.1 vs 2.2 at a glance

WCAG 2.2 became a W3C Recommendation on 5 October 2023, and the current edition is dated 12 December 2024. In October 2025 it was approved as ISO/IEC 40500:2025; the W3C's WCAG overview says the ISO standard is exactly the same as the October 2023 version of WCAG 2.2.

Counting the success criteria in WCAG 2.0, WCAG 2.1 and 2.2 gives this picture:

Level AA conformance means meeting every Level A and AA criterion: 50 in WCAG 2.1 and 55 in WCAG 2.2. The difference is the six new A and AA criteria minus 4.1.1, which was a Level A criterion.

The nine new success criteria

The criteria and levels below are from the W3C's What's new in WCAG 2.2; the requirement column summarizes the normative text, and the test column is the quickest check we know for each.

4.1.1 Parsing: the criterion that was removed

4.1.1 required well-formed markup: complete start and end tags, correct nesting, no duplicate attributes and unique IDs. WCAG 2.2 lists it as "obsolete and removed" because assistive technology no longer parses HTML directly. The W3C's WCAG 2 FAQ says issues that would have failed 4.1.1 will fail other criteria, such as 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.

The removal also reached the older versions. The same FAQ says WCAG 2.1 was updated on 21 September 2023 with a note, and WCAG 2.0 has an erratum, saying 4.1.1 should be considered always satisfied for any content using HTML or XML.

That's the caveat on "2.2 covers 2.1". If a contract, a buyer's checklist or a national rule still lists 4.1.1 as a requirement, report on it. Running your main templates through the W3C's validator is cheap evidence.

Which laws reference which WCAG version

Most rules name a specific WCAG version, and few name 2.2 yet:

So which version should you target?

WCAG 2.2 Level AA. It meets every rule in the table that names 2.0 or 2.1, it's what the newest European and Brazilian standards follow, and the W3C encourages the latest version. Write "WCAG 2.2 AA, plus 4.1.1 where a rule requires it" in your contracts and tenders, and you won't need to re-test when a rule catches up.

Our guide to ADA website compliance covers the US rules in detail, and our European Accessibility Act guide covers the EU's.

How to test and fix the six A and AA criteria

These are the ones that change a 2.1 AA site's result. For each: where it usually fails, how to test and the usual fix.

2.4.11 Focus Not Obscured (Minimum)

Where it fails: sticky headers and footers, cookie banners, "chat with us" buttons and non-modal pop-ups that cover the element a keyboard user has just tabbed to. The W3C lists a sticky header or footer that completely hides the focused element as a known failure (F110). Partly hidden passes at this level; that's what the AAA version tightens.

How to test: tab forward and back through each template, first with every banner and widget showing, then dismissed. Repeat at 200% browser zoom and at phone width, where sticky elements take up more of the screen.

The fix: reserve the sticky header's height with CSS scroll-padding-top (technique C43), so the browser scrolls focused elements clear of it. Make cookie banners modal, or position them so they don't cover content, and ask whether each sticky element needs to be sticky at all.

2.5.7 Dragging Movements

Where it fails: range sliders, drag-to-reorder lists, kanban boards, pannable maps and drag-and-drop upload areas.

How to test: list everything on the site that moves by dragging, then try each one with single clicks or taps only. The W3C's Understanding 2.5.7 notes that a keyboard alternative doesn't automatically meet this criterion: the alternative has to work with a single pointer, by clicking or tapping.

The fix: let a click anywhere on a slider's track set the value, add move up and move down buttons or a "move to" menu next to sortable items, add pan buttons to maps, and pair every drop zone with a "choose file" button.

2.5.8 Target Size (Minimum)

Where it fails: social media icons, close (X) buttons, pagination numbers, carousel dots, date-picker days and icon buttons packed together in toolbars.

How to test: in the browser's developer tools, measure the clickable area, not the drawn icon. A target passes at 24 by 24 CSS pixels or larger. A smaller one passes if a 24-pixel circle centred on it doesn't touch another target or another small target's circle: in the W3C's Understanding 2.5.8 examples, 20 by 20 pixel icon buttons with a 4-pixel gap pass, and the same buttons with no gap fail. Links inside a sentence are exempt, as are controls the browser draws and you haven't styled.

The fix: enlarge the hit area with padding without changing the icon, space small targets apart, and fix the size in the design system's button and icon components so every page inherits it. 24 pixels is the floor; the AAA criterion 2.5.5 asks for 44 by 44, which is a better target for primary actions on mobile.

3.2.6 Consistent Help

Where it fails: a phone number in the header on some pages and in the footer on others, a chat widget that appears only on certain templates in a different position, or a help link that moves around the menu.

How to test: open five pages built on different templates at the same width and zoom, and note the order of help mechanisms (contact details, contact form or chat, self-help pages such as an FAQ, and chatbots) relative to the rest of the content. The order, not the pixel position, is what's compared. The criterion doesn't require you to offer help at all; it applies when you do.

The fix: put help in a shared header or footer component, not in blocks that editors place by hand on each page.

3.3.7 Redundant Entry

Where it fails: checkouts that ask for the shipping address again as the billing address, multi-step applications that ask for the email twice, and forms that clear every field after a validation error, forcing users to retype.

How to test: walk every multi-step process end to end, including going back a step, and list each piece of information requested more than once. Re-entry is allowed when it's essential, needed for security (such as confirming a new password) or when the earlier entry is no longer valid.

The fix: carry data between steps, prefill what you already know, add "same as shipping address" options, and show a summary with edit links at the end.

3.3.8 Accessible Authentication (Minimum)

Where it fails: login forms that block paste or password-manager autofill, one-time codes split into six boxes that only accept one pasted digit, and text or arithmetic CAPTCHAs with no alternative.

How to test: sign in using a password manager, then paste the one-time code. Check every step, including two-factor authentication and password reset. According to the W3C's Understanding 3.3.8, a password passes if a password manager can fill it or the user can paste it; requiring the user to transcribe a code by hand fails; and at Level AA, a CAPTCHA that asks you to recognize objects, such as picking the photos with cars, is allowed, while distorted-text and maths CAPTCHAs are not.

The fix: mark fields with the right autocomplete values (username, current-password, one-time-code), allow paste everywhere, and offer a method that needs no memory test, such as passkeys, a sign-in link by email or signing in with another provider. Replace puzzle CAPTCHAs with checks that ask nothing of the user, such as rate limiting.

The three AAA criteria

Few rules require Level AAA, but two of these are cheap wins once the AA work is done:

• 2.4.12 Focus Not Obscured (Enhanced): no part of the focused element is hidden. If you fixed 2.4.11 with scroll padding, you're most of the way there.
• 2.4.13 Focus Appearance: a focus indicator at least as large as a 2 CSS pixel perimeter of the component, with 3:1 contrast against its unfocused state. A solid outline at least 2 pixels thick, set once as a design token, usually covers the area test; check the 3:1 contrast against the unfocused state.
• 3.3.9 Accessible Authentication (Enhanced): as 3.3.8, but object-recognition and personal-content tests no longer count as exceptions. Passkeys and sign-in links by email avoid cognitive tests altogether.

Moving a WCAG 2.1 AA site to 2.2 AA

1. Test only what changed. Run the six new A and AA criteria above across your templates and complete processes: sign-up, sign-in, checkout or booking, contact.
2. Fix at the component level. Focus styles, target sizes, sticky elements and form fields live in a handful of shared components; fixing them once fixes every page.
3. Retest sign-in with every method you offer, including single sign-on, two-factor authentication and password reset.
4. Update your documentation. Change the standard named in your accessibility statement, and reissue any Accessibility Conformance Report: the current VPAT's WCAG edition already reports against 2.2, as our VPAT and ACR guide explains.
5. Keep 4.1.1 evidence if a contract or rule you work under still names WCAG 2.0 or 2.1 with 4.1.1 in scope.
6. Write 2.2 AA into new contracts and briefs, so the next redesign starts at the current standard.

What to do next

Our free WCAG 2.2 checklist has a "New in 2.2" filter that shows exactly these criteria, each as a plain question with how to test and fix it, and builds a prioritized plan from your answers. To budget outside help, see what a website accessibility audit costs. If you'd rather Dardo test and fix it, our web accessibility audit covers WCAG 2.2 AA by hand and starts at USD 690, as listed on our pricing page.