WCAG 2.2 vs 2.1: What Changed and What to Re-Test

If your site was built or audited against WCAG 2.1 and someone now asks for WCAG 2.2, the good news is that the gap is small and well defined. WCAG 2.2 keeps every WCAG 2.1 success criterion except one, adds nine new ones, and changes nothing about color contrast. This guide covers only the difference: what was added, what was removed, which of it applies at Level AA, and what a team that already meets 2.1 has to re-test.

Every level and quotation below comes from the WCAG 2.2 Recommendation (current edition dated 12 December 2024) and its Comparison with WCAG 2.1 section. If you want the full list of Level A and AA criteria instead, use our WCAG 2.2 checklist.

The short answer

The W3C published WCAG 2.2 as a Recommendation on 5 October 2023, according to its own What's new in WCAG 2.2 page. The Recommendation describes the relationship in one sentence: "WCAG 2.2 builds on and is backwards compatible with WCAG 2.1, meaning web pages that conform to WCAG 2.2 are at least as accessible as pages that conform to WCAG 2.1."

In practice that means three things:

• Nine criteria were added. Six of them are Level A or AA, so they count for an AA target. Three are AAA.
• One criterion was removed: 4.1.1 Parsing.
• Everything else is the same. The W3C says the 2.0 and 2.1 success criteria "are essentially the same in 2.2, with one exception", and that exception is Parsing.

So a site that meets WCAG 2.1 AA is not starting over. It needs to pass six additional checks.

Did color contrast change in WCAG 2.2?

No. This is the question people search for most often, so here is the plain answer. The two contrast criteria at Level AA are the same in both versions:

• 1.4.3 Contrast (Minimum), AA: text needs a contrast ratio of at least 4.5:1, or 3:1 for large text.
• 1.4.11 Non-text Contrast, AA: the visual parts needed to identify controls and their states, and the parts of graphics needed to understand them, need at least 3:1 against adjacent colors.

Both were already in WCAG 2.1 (1.4.11 was added in 2.1) and neither changed in 2.2. If your text and controls passed contrast under 2.1, they pass under 2.2. You can confirm a page with our color contrast checker, and our guide to contrast requirements explains the ratios in detail.

The new criterion that touches contrast is 2.4.13 Focus Appearance, and it is Level AAA. It asks that a visible focus indicator be at least as large as a 2 CSS pixel thick perimeter of the component and have a contrast ratio of at least 3:1 between the focused and unfocused states. Because it is AAA, it is not part of an AA target. It is still a good design rule for focus outlines, and it is the reason many teams now use a solid 2 pixel outline.

The nine new criteria and their levels

For an AA target, the six that matter are 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 and 3.3.8. For a deeper explanation of each one with examples, see our breakdown of the nine WCAG 2.2 criteria.

What was removed: 4.1.1 Parsing

WCAG 2.1 had 4.1.1 Parsing at Level A. It asked for complete start and end tags, correct nesting, no duplicate attributes and unique IDs. WCAG 2.2 marks it "Obsolete and removed", with this note: "Assistive technology no longer has any need to directly parse HTML. Consequently, these problems either no longer exist or are addressed by other criteria."

The W3C also edited WCAG 2.1 itself. The current WCAG 2.1 Recommendation (dated 6 May 2025) adds a note that 4.1.1 "should be considered as always satisfied for any content using HTML or XML". So even under 2.1, an HTML validator error is no longer a Parsing failure.

That does not make markup errors harmless. A duplicate id can still break a real relationship, and then the failure belongs to another criterion, usually 1.3.1 Info and Relationships or 4.1.2 Name, Role, Value:

<!-- Broken: two inputs share id="email", so the second label points at the wrong field -->
<label for="email">Billing email</label>
<input id="email" type="email" autocomplete="email">
<label for="email">Shipping email</label>
<input id="email" type="email">

<!-- Fixed: unique ids, so each label names its own field -->
<label for="billing-email">Billing email</label>
<input id="billing-email" type="email" autocomplete="email">
<label for="shipping-email">Shipping email</label>
<input id="shipping-email" type="email">

One more detail from the Recommendation: authors who are required by policy to conform to WCAG 2.0 or 2.1 "may need to continue to test and report 4.1.1". If a contract or procurement form lists 4.1.1, answer it, and explain the W3C note.

What a team that meets 2.1 has to re-test

Here is the upgrade work for a site that already meets WCAG 2.1 AA, ordered by where failures usually turn up.

Sticky headers, footers and banners (2.4.11)

Tab through every template with the cookie banner open and closed. If a focused link scrolls under a fixed header and disappears completely, it fails. The usual fix is one line of CSS:

/* Broken: focused items scroll underneath a 72px fixed header */
.site-header { position: fixed; top: 0; height: 72px; }

/* Fixed: the browser keeps focused and scrolled-to items clear of the header */
html { scroll-padding-top: 80px; }

Our keyboard and focus checker covers tab order and focus on a page, and how to test keyboard accessibility by hand walks through the manual pass.

Small targets (2.5.8)

Icon buttons, pagination links, close buttons and social icons are the usual suspects. A target under 24 by 24 CSS pixels can still pass if the spacing exception applies, and links inside a sentence are exempt. Run the target size checker on your busiest templates, and read our guide to the 24 pixel rule for the exceptions.

Drag interactions (2.5.7)

List every slider, sortable list, map, kanban board and file drop zone. Each needs a way to do the same thing with clicks or taps alone, such as up and down buttons on a sortable list or a "choose file" button next to the drop zone.

Login, sign-up and password reset (3.3.8)

Check that password fields allow paste and password managers (no autocomplete="off" on them), that one-time codes can be pasted, and that any CAPTCHA has an alternative that does not rely on a puzzle. Our guide to accessible forms covers the field markup.

Multi-step forms (3.3.7)

Walk through checkout, booking and application flows. If step three asks for an address the user typed in step one, offer a "same as billing" checkbox or fill it in.

Help links (3.2.6)

If the header or footer has a contact link, phone number or chat button on several pages, make sure it sits in the same order relative to the rest of the page on each one. Templates usually get this right; one-off landing pages are where it slips.

Which version should you target?

Some rules still name WCAG 2.1. In the United States, the Department of Justice rule for state and local governments under ADA Title II adopted WCAG 2.1 Level AA (Federal Register, 89 FR 31320); our post on the Title II deadline extension has the dates. In Europe, the new EN 301 549 V4.1.1 points its web requirements at WCAG 2.2, as we explain in what changed in EN 301 549 V4.1.1.

Because 2.2 is backwards compatible, you do not have to choose. The W3C says "sites which conform to WCAG 2.2 also conform to WCAG 2.1", and its Working Group "recommends that sites adopt WCAG 2.2 as their new conformance target, even if formal obligations mention previous versions". Building to 2.2 AA covers a 2.1 AA requirement too.

What to tell a manager or a client

Something like this works: "WCAG 2.2 is the current version. It keeps everything from 2.1, drops one outdated rule, and adds six requirements at our level, mostly about focus, tap targets, dragging and logins. Contrast rules did not change. We will test those six on our main templates and fix what fails." That is accurate, short and does not overpromise.

A note on tools: automated checks, ours included, can flag many of these problems, but they cannot confirm that a site conforms to any version of WCAG. Several of the new criteria, such as Consistent Help and Redundant Entry, depend on how pages and processes behave, so a person still has to look.

Upgrade checklist: WCAG 2.1 AA to 2.2 AA

1. Keep your 2.1 results. Contrast, alt text, headings, labels and the rest carry over unchanged.
2. Drop 4.1.1 Parsing from your 2.2 report, but keep fixing duplicate ids that break labels or ARIA references.
3. Tab through each template with sticky elements visible (2.4.11).
4. Measure small icons and links against 24 by 24 CSS pixels (2.5.8).
5. Give every drag action a click or tap alternative (2.5.7).
6. Allow paste and password managers on login and reset forms (3.3.8).
7. Remove repeated questions in multi-step forms (3.3.7).
8. Keep help links in the same order across pages (3.2.6).
9. Update your accessibility statement and reports to say WCAG 2.2 AA.

Want a starting point? Run a free accessibility scan on your home page and one key template. AccessGuard runs automated WCAG 2.2 AA checks in a real browser, including target size and focus checks, and shows which failures need a person to confirm.