WCAG 2.1 vs 2.2: What Changed and Why It Matters

WCAG 2.2 is not a replacement for WCAG 2.1, it’s an extension of it. It adds nine new success criteria (six at Level AA), drops one criterion that modern browsers made obsolete, and keeps everything else from 2.1 intact, so a site that already conforms to 2.1 AA has a short, specific gap to close rather than a full re-audit ahead of it.

Why WCAG has two current versions in play

The W3C published WCAG 2.2 in October 2023. But most legal and regulatory frameworks move slower than the standards bodies that define them, so a lot of active compliance obligations, including the EAA’s harmonized technical standard EN 301 549, still cite WCAG 2.1 AA in their currently published version rather than 2.2. That’s why both versions are still relevant in 2026: 2.2 is the more current and complete standard, but 2.1 is frequently the one actually named in law.

This lag is normal for how technical standards and legislation interact. A regulation typically names a specific, dated version of a standard rather than “whatever the current version is,” partly for legal certainty and partly because updating a law’s technical references takes its own administrative process. EN 301 549 is expected to eventually incorporate WCAG 2.2 in a future version (v4.1.1 is the version generally expected to make that move), but until that update is formally adopted and referenced by regulation, WCAG 2.1 AA remains the version most EU compliance work is actually measured against.

What’s new in WCAG 2.2

The new success criteria cluster around a few practical themes rather than being scattered randomly across the spec.

Focus visibility gets three related additions: 2.4.11 Focus Not Obscured (Minimum), which requires that at least part of a focused element remain visible when something like a sticky header or cookie banner would otherwise cover it, and the related 2.4.12 (enhanced version, AAA) and 2.4.13 Focus Appearance (AAA), which set minimum size and contrast requirements for focus indicators.

Authentication gets one significant addition: 3.3.8 Accessible Authentication (Minimum), which requires that login processes not rely solely on a cognitive function test (like remembering a password or solving a puzzle) without an alternative, unless that test is something like object recognition or is otherwise assisted.

Interaction and input targets get two: 2.5.7 Dragging Movements, which requires an alternative to drag-based interactions, and 2.5.8 Target Size (Minimum), which sets a 24-by-24-pixel minimum for clickable targets unless exceptions apply.

The remaining additions cover consistent help mechanisms (3.2.6 Consistent Help, requiring that a help option like a contact link or chat feature appear in the same relative place across pages where it’s offered), redundant entry (3.3.7 Redundant Entry, avoiding asking users to re-enter information they already provided earlier in the same process, such as re-typing a shipping address that was already entered on a previous step), and Page Break Navigation (2.4.13, AAA level, aimed at content with page numbers like an e-book or long document).

Two more Level AA additions round out the list: 2.4.11 has a AAA-level enhanced counterpart, and the full list at Level AA specifically comes to six new criteria most compliance programs will actually need to check: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry, and Accessible Authentication (Minimum).

What was removed

WCAG 2.2 dropped 4.1.1 Parsing, the old requirement about well-formed HTML (no duplicate IDs, properly nested tags, and so on). Modern browsers and assistive technology handle malformed HTML gracefully enough that the criterion no longer added meaningful value, so it was retired rather than carried forward.

Which new criteria matter most in practice

Not all nine additions carry equal weight for a typical business site. Focus Not Obscured (2.4.11) is probably the most broadly relevant, because sticky navigation bars, cookie consent banners, and chat widgets covering the keyboard focus indicator is an extremely common real-world problem, not an edge case. Target Size (2.5.8) matters a lot for mobile-heavy sites with small tap targets. Accessible Authentication (3.3.8) matters most for anything with a login flow, particularly if that flow uses CAPTCHAs or memory-based challenges without an alternative path.

Redundant Entry (3.3.7) tends to matter most for multi-step processes: a checkout that asks for a shipping address and then asks for the same address again on a billing step, without offering to reuse the earlier entry, is a fairly common pattern that this criterion specifically targets. Dragging Movements (2.5.7) matters disproportionately for sites with custom interactive elements like image sliders, sortable lists, or map interfaces, since drag-only interaction has historically been common in those components without much thought given to a non-drag alternative.

Do you need to redo your audit

If a site already conforms to WCAG 2.1 AA, moving to 2.2 doesn’t mean starting over. Because 2.2 is backward compatible, the practical work is checking the site against the nine new criteria specifically, not re-testing everything that was already verified under 2.1. Testing tools built around the axe-core engine, like those from Deque, have updated their rule sets to cover the 2.2 additions, which makes this a much faster check than a full audit. Vendors offering ongoing monitoring, such as AudioEye’s human-in-the-loop platform, can also flag where a previously-passing site now has gaps against the newer criteria.

A practical order of operations: run an automated scan first against a 2.2-aware rule set to catch what’s mechanically detectable, like small tap targets or missing help-link consistency, then do a focused manual pass on the criteria that need human judgment, particularly Focus Not Obscured and Accessible Authentication, since both depend on how a real user experiences the page rather than something a static scan can fully evaluate.

Common places sites fail the new criteria

A few patterns show up repeatedly when sites get checked against 2.2 for the first time. Sticky headers and floating chat widgets covering the keyboard focus ring as a user tabs through the page is probably the single most common new failure, precisely because it’s such a widespread modern design pattern. Login and signup flows that rely on a CAPTCHA with no alternative verification method fail Accessible Authentication outright. E-commerce sites with drag-based interactions, like a drag-to-reorder cart or an image carousel controlled only by dragging, fail Dragging Movements if there’s no button or tap-based alternative. And mobile navigation icons or close buttons sized well under the 24-pixel minimum are a frequent Target Size failure, especially on sites designed primarily for desktop and adapted to mobile afterward.

Which version should you target

If your applicable law or contract specifically names WCAG 2.1 AA, meeting that remains your baseline legal requirement, and you can treat 2.2 conformance as a forward-looking improvement rather than an immediate obligation. If you have flexibility, or you’re building something new, targeting 2.2 AA from the start is the more future-proof choice, since it’s a strict superset of 2.1 AA minus one obsolete criterion. Either way, our WCAG 2.1 AA checklist is a useful starting reference if you haven’t audited against the baseline yet.

For most businesses, the practical answer ends up being “both, in sequence”: treat WCAG 2.1 AA as the floor you’re legally accountable for today, and layer the WCAG 2.2 additions on top as a near-term improvement project rather than a separate initiative. Since the two standards overlap almost entirely, there’s little reason to silo them into different audits or different vendor engagements. A single testing pass that covers 2.2’s full criteria set automatically covers 2.1 AA as well, which is often the more efficient way to approach it even if your immediate legal obligation is only for the older version.

Keeping up with future WCAG versions

WCAG’s version history suggests this pattern will repeat. 2.0 was the baseline for years, 2.1 added mobile and low-vision considerations, and 2.2 added the criteria covered above; a WCAG 3.0 is in development with a substantially different structure, though it remains a working draft rather than a finished standard, and adoption into law tends to lag publication by a meaningful margin regardless of version. The practical takeaway for a business isn’t to chase every new draft, it’s to build a periodic re-check into your accessibility process (annually is reasonable for most sites) so that when a new version does become relevant, whether through updated regulation or genuine best practice, you’re not starting from scratch to find out where you stand.