Skip to content
wcagc
←Back to blog
WCAGWCAG 2.2standards

WCAG 2.1 vs 2.2: what actually changed

WCAG 2.1 vs 2.2 added nine success criteria and dropped 4.1.1 Parsing. What each new rule requires, and which version your law expects.

P

Pavel Charkasau

WCAG 2.2 became a W3C Recommendation on 5 October 2023, and it is the current version of the guidelines (W3C). Set against WCAG 2.1, the change is small and additive. Version 2.2 adds nine new success criteria and removes one, 4.1.1 Parsing, which is now marked obsolete (W3C, What's New in WCAG 2.2). Everything else from 2.0 and 2.1 carries over word for word, so 2.2 is a superset of 2.1: a site that meets 2.2 already meets 2.1. Six of the nine new criteria sit at Level A or AA, the levels laws and contracts actually ask for. The other three are AAA.

The wrinkle is that most accessibility law still names an older version. The EU's EN 301 549 and the US DOJ's ADA Title II rule both reference WCAG 2.1 AA today, not 2.2. So "which version do I need" and "which version should I build to" can have different answers. This guide lists every new criterion, explains the one that left, and says which version your obligation most likely names.

What is the difference between WCAG 2.1 and 2.2?

WCAG 2.2 keeps all 50 success criteria from 2.1, adds nine, and retires one. The net count of testable criteria goes from 78 in 2.1 to 86 in 2.2. Nothing that passed under 2.1 fails under 2.2 on the strength of a wording change, because the older criteria were left untouched (W3C).

The nine additions target gaps that 2.1 left open, mostly around keyboard focus, touch targets, dragging, and login. Version 2.1 itself, back in 2018, was aimed at mobile, low vision, and cognitive accessibility. Version 2.2 continues in that direction rather than changing course. If you already track your conformance against 2.1, moving to 2.2 is a matter of checking nine more boxes, not re-auditing the whole standard.

Which success criteria are new in WCAG 2.2?

Here are the nine, with their level and the plain requirement behind each (W3C, What's New in WCAG 2.2):

CriterionLevelWhat it requires
2.4.11 Focus Not Obscured (Minimum)AAWhen a component gets keyboard focus, it is not entirely hidden behind sticky headers, cookie bars, or other author content.
2.4.12 Focus Not Obscured (Enhanced)AAAThe focused component is not hidden at all, even partially.
2.4.13 Focus AppearanceAAAThe focus indicator meets a minimum size and a 3:1 contrast between focused and unfocused states.
2.5.7 Dragging MovementsAAAnything you do by dragging can also be done with a single tap or click, unless dragging is essential.
2.5.8 Target Size (Minimum)AAPointer targets are at least 24 by 24 CSS pixels, or have enough spacing around them.
3.2.6 Consistent HelpAHelp options (contact link, chat, phone) appear in the same relative place across pages.
3.3.7 Redundant EntryAInformation you already entered in a process is auto-filled or selectable, not asked for twice.
3.3.8 Accessible Authentication (Minimum)AALogin does not force a cognitive test like solving a puzzle or retyping characters, unless there is an alternative.
3.3.9 Accessible Authentication (Enhanced)AAAStricter version: no object or image recognition test either, unless an alternative exists.

Six of these are A or AA. If your target is WCAG 2.2 AA, the ones you have to meet are 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7, and 3.3.8. The three AAA criteria are the ones few organisations commit to across a whole site, and 2.2 does not change that norm.

Why was 4.1.1 Parsing removed?

Success criterion 4.1.1 Parsing is obsolete and removed from WCAG 2.2 (W3C, What's New in WCAG 2.2). It originally asked that markup have complete start and end tags and no duplicate attributes, back when assistive technology parsed HTML directly and choked on broken markup. Browsers and assistive tech no longer work that way. They read the accessibility tree the browser builds, so a stray unclosed tag that the browser recovers from cleanly no longer breaks a screen reader the way it might have in 2008.

The W3C went a step further and told teams still on 2.0 or 2.1 that 4.1.1 should now be treated as always satisfied for content using HTML or XML. In practice that means you can stop chasing 4.1.1 failures on a modern site. One caveat: if a contract or procurement checklist explicitly requires WCAG 2.0 or 2.1 conformance, an auditor may still list 4.1.1 on the form, in which case you mark it satisfied and move on.

Do you have to use WCAG 2.2 or 2.1?

It depends entirely on which law, contract, or policy references the guidelines. WCAG on its own carries no legal force. It is a technical document that other instruments point to, and they each pin a version:

  • EU (EAA and public sector). The harmonised standard EN 301 549, in its current version v3.2.1, adopts WCAG 2.1 Level AA for web content (ETSI EN 301 549 v3.2.1). The European Accessibility Act relies on that standard for its presumption of conformity, so the working target across the EU today is 2.1 AA.
  • US federal government. Section 508 incorporates WCAG 2.0 Level AA through its 2017 Revised Standards. See Section 508.
  • US state and local government. The DOJ's 2024 ADA Title II rule sets WCAG 2.1 Level AA as the technical standard, and the 2026 date extension did not change that target (ADA.gov).

So for most obligations right now, 2.1 AA is the letter of the requirement. Here is the founder opinion, stated plainly: build to 2.2 AA anyway. Because 2.2 is backward compatible, meeting it satisfies every rule that names 2.0 or 2.1, and it saves you a second pass when the standards catch up, which they will. The nine extra criteria are also just good practice. Nobody regrets making their tap targets bigger or letting people paste a password.

Which new criteria will change your site the most?

In my experience reviewing real sites, four of the nine do most of the work.

2.5.8 Target Size (Minimum). The 24 by 24 CSS pixel floor catches cramped icon buttons, close-X controls, and tightly stacked links. This is the single most common new failure I see, because dense toolbars and mobile footers were rarely built with a 24px minimum in mind.

3.3.8 Accessible Authentication. If your login or checkout uses a puzzle CAPTCHA with no alternative, or blocks pasting into the password field, that now fails at AA. Allowing a password manager to fill and paste is usually the whole fix.

2.4.11 Focus Not Obscured. Sticky headers and cookie banners are the usual culprits. Tab through a long form and watch whether the focused field slides under a fixed header. If it disappears completely, that is a fail.

2.5.7 Dragging Movements. Sliders, drag-to-reorder lists, and map controls need a non-drag path, such as buttons or a text input. Essential drawing tools are exempt, but most drag interactions on a marketing or commerce site are not essential.

A scanner can flag some of these automatically, target size and focus contrast among them. It cannot judge whether a dragging alternative actually works or whether a login puzzle has a real bypass. Automated tools catch roughly 30 to 57% of issues; the rest needs a person testing with a keyboard and a screen reader (Deque, 2021). Treat a clean scan as the start of the review, not the end of it.

How do you test a site against WCAG 2.2?

Run an automated scan first to clear the mechanical failures, then check the criteria a machine cannot judge by hand. Our WCAG checklist lists the criteria by level so you can see exactly which of the nine new ones apply to your target. For the automated pass, run a scan against the pages that matter, including the ones behind a login where target size and authentication issues tend to hide.

Frequently asked questions

Is WCAG 2.2 backward compatible with WCAG 2.1?

Yes. WCAG 2.2 keeps every 2.1 success criterion unchanged and only adds new ones, apart from retiring 4.1.1 Parsing. A site that conforms to 2.2 conforms to 2.1 by definition (W3C).

How many new success criteria are in WCAG 2.2?

Nine new criteria, and one removed. Six of the nine are at Level A or AA; three are AAA. The removed one is 4.1.1 Parsing (W3C, What's New in WCAG 2.2).

When did WCAG 2.2 become official?

WCAG 2.2 was published as a W3C Recommendation on 5 October 2023, which makes it the current version of the guidelines (W3C).

Does the EAA require WCAG 2.2?

Not yet. The EAA works through EN 301 549, and the current v3.2.1 of that standard references WCAG 2.1 Level AA, not 2.2 (ETSI EN 301 549 v3.2.1).

Is 4.1.1 Parsing still something I need to test?

No. It is obsolete in 2.2, and the W3C now treats it as always satisfied for HTML and XML content even under 2.0 and 2.1. You only report it if a specific contract still asks for a 2.0 or 2.1 line-by-line result.

Check where your site stands

WCAG 2.2 adds nine concrete things to verify, and six of them apply at AA. The fastest way to see which ones your pages already pass is to scan them and read the findings against the checklist. Run a free scan to get the violation list with the exact selector for each issue, then bring in a manual review for the criteria a scanner cannot judge.

Written by Pavel Charkasau, founder of wcagc.com. Last updated 16 July 2026.

Sources