WCAG 2.2 vs 2.1: What Changed and What It Means for Your Website (2026)
WCAG 2.2 became the official W3C standard on October 5, 2023. It adds 9 new success criteria, removes 1, and is backwards compatible with WCAG 2.1. Here is exactly what changed — and what you need to do about it.
If you built your website to WCAG 2.1 Level AA, you are already most of the way to WCAG 2.2 compliance. The two versions share the same foundation — WCAG 2.2 does not replace 2.1 so much as extend it. Every success criterion from WCAG 2.1 carries forward into 2.2 with one exception: 4.1.1 Parsing, which was removed because modern browsers now handle the issues it was designed to catch.
The new criteria in WCAG 2.2 focus on three underserved groups: users who navigate by keyboard, users with motor impairments on mobile devices, and users with cognitive disabilities. If your site relies on drag-and-drop interactions, has a sticky header that covers content, or uses a CAPTCHA on your login page, WCAG 2.2 directly addresses those gaps.
This guide covers every change — what each new criterion requires, why it exists, and how to fix it. We also address the legal question: does WCAG 2.2 change what you need to comply with under the ADA?
What Is WCAG 2.2?
WCAG (Web Content Accessibility Guidelines) is the international standard for web accessibility, developed by the W3C (World Wide Web Consortium). The guidelines are organized into four principles — Perceivable, Operable, Understandable, and Robust (POUR) — and each principle contains testable success criteria at three levels:
- Level AMinimum — basic accessibility requirements. Failing these makes content inaccessible to some users.
- Level AARecommended standard. Referenced by the ADA, AODA, EU EAA, and most legal frameworks worldwide.
- Level AAAEnhanced — the highest level, not required for general compliance.
WCAG 2.2 was published on October 5, 2023 as a W3C Recommendation — the highest level of W3C endorsement. It is the current version of WCAG. The previous version, WCAG 2.1, was published in June 2018.
WCAG 2.1 vs WCAG 2.2: At a Glance
| Feature | WCAG 2.1 | WCAG 2.2 |
|---|---|---|
| Published | June 2018 | October 5, 2023 |
| Total success criteria | 78 | 86 (9 added, 1 removed) |
| Level A criteria | 30 | 32 (+2) |
| Level AA criteria | 20 | 24 (+4) |
| Level AAA criteria | 28 | 28 (+3, overlapping with AA proposals) |
| Removed criteria | None | 4.1.1 Parsing |
| Primary focus areas | Mobile, low vision | Cognitive, motor, keyboard usability |
| Backwards compatible? | Yes (with 2.0) | Yes (with 2.1, except 4.1.1) |
What Was Removed: 4.1.1 Parsing
4.1.1 Parsing required that HTML be free of certain markup errors — duplicate IDs, improperly nested elements, and unclosed tags. It was removed from WCAG 2.2 because modern browsers and assistive technologies now handle these errors gracefully, making the criterion largely obsolete.
This does not mean you can write invalid HTML. Clean, well-structured markup still benefits screen readers and automated tools. What it means is that failing a markup validator no longer constitutes a WCAG failure on its own. If you are currently auditing against WCAG 2.1, you can stop flagging 4.1.1 Parsing as an issue when upgrading to 2.2.
New Level AA Criteria (Required for Compliance)
These four new Level AA criteria are the most important changes in WCAG 2.2. Level AA is the standard required by the ADA, AODA, EU EAA, and most other accessibility regulations. If you are aiming for legal compliance, these criteria need to be on your fix list. For step-by-step guidance on addressing violations, see our complete guide to fixing WCAG violations.
2.4.11 — Focus Not Obscured (Minimum)
What it requires
When a keyboard-focusable component receives focus, it must not be entirely hidden by author-created content — such as a sticky header, cookie banner, or chat widget.
Why it matters
Keyboard-only users navigate by moving focus between elements. If the focused element is completely hidden behind another layer, users cannot see where they are on the page.
How to fix it
Test every sticky or fixed-position element on your page. Tab through the page and verify no focused element is fully obscured. Adjust z-index values or add scroll padding to compensate for sticky headers.
2.5.7 — Dragging Movements
What it requires
Any functionality that requires dragging (sliders, drag-and-drop file uploads, sortable lists) must also be achievable with a single pointer action — like a click or tap — without dragging.
Why it matters
Users with motor impairments, tremors, or limited dexterity cannot reliably perform precise dragging movements. Requiring drag-only interactions excludes these users entirely.
How to fix it
Add button-based alternatives for drag interactions. A sortable list should have "Move up / Move down" buttons. A range slider should also accept direct numeric input.
2.5.8 — Target Size (Minimum)
What it requires
Interactive targets (buttons, links, form controls) must be at least 24×24 CSS pixels in size, or have sufficient spacing so a 24px circle centred on the target does not intersect another target.
Why it matters
Small touch targets are difficult to activate accurately for users with motor impairments, older users, or anyone on a mobile device. This is one of the most common causes of mobile usability failure.
How to fix it
Audit your buttons and links for size. In CSS, set minimum dimensions: min-width: 24px; min-height: 24px. For text links inline in a paragraph, spacing-based exceptions may apply.
3.3.8 — Accessible Authentication (Minimum)
What it requires
Authentication steps (login, account creation, two-factor) must not require users to solve a cognitive function test — such as remembering a password, solving a puzzle, or transcribing characters — unless an alternative is provided.
Why it matters
CAPTCHAs and memory-based authentication create significant barriers for users with cognitive disabilities, dyslexia, or memory impairments. They also frustrate all users unnecessarily.
How to fix it
Support password managers (do not block autocomplete on password fields), offer copy-paste in OTP fields, and provide audio alternatives or simpler methods alongside image-based CAPTCHAs.
New Level A Criteria (Also Required)
Level A is the baseline — failing these criteria means some users cannot access your content at all. WCAG 2.2 adds two new Level A requirements.
3.2.6 — Consistent Help
Level AWhat it requires
If your website provides a help mechanism — contact form, live chat, phone number, FAQ link — it must appear in the same location relative to page content across all pages where it is present.
How to fix it
Place your help link or chat widget in the same header, footer, or sidebar position consistently. If it appears on some pages but not others, that is acceptable — what is not acceptable is placing it in a different position on different pages.
3.3.7 — Redundant Entry
Level AWhat it requires
Information a user has already entered in a multi-step process must be either auto-populated in subsequent steps or made available for the user to select — they should not have to type the same data twice.
How to fix it
In checkout flows, pre-fill the billing address with the shipping address (with an option to change). In multi-step forms, carry forward previously entered name, email, or contact data.
New Level AAA Criteria (Not Required for AA Compliance)
These three criteria are not required to meet WCAG 2.2 AA. They represent enhanced goals for teams that want to go further.
| Criterion | What it requires |
|---|---|
| 2.4.12 Focus Not Obscured (Enhanced) | No part of the focused element is hidden — stricter than 2.4.11 which only requires it is not entirely hidden. |
| 2.4.13 Focus Appearance | Focus indicators must meet minimum size (at least 2 CSS pixel perimeter) and contrast (3:1 against adjacent colours) requirements. |
| 3.3.9 Accessible Authentication (Enhanced) | No cognitive function tests at any step of authentication — no exceptions, no alternatives required. |
Does WCAG 2.2 Change Your Legal Obligations?
For most businesses, not yet — but the direction is clear.
The DOJ's ADA Title II Final Rule, which sets a compliance deadline for government entities in April 2026, specifically references WCAG 2.1 Level AA — not 2.2. So if you are a government entity, WCAG 2.1 AA is currently the required standard. Federal agencies are also governed by Section 508, which incorporated WCAG 2.0 AA in its 2018 refresh and similarly points to WCAG 2.1 as best practice.
For private businesses subject to ADA Title III, there is no federal rule specifying a WCAG version. Courts have consistently used WCAG 2.1 AA as the benchmark when evaluating website accessibility claims.
The practical case for WCAG 2.2
Since WCAG 2.2 is backwards compatible with 2.1, targeting 2.2 AA means you automatically satisfy 2.1 AA (the current legal standard). There is no compliance cost to going further. As regulations are updated — which historically follows the W3C standard — you will already be ahead.
WCAGsafe's scanner tests against WCAG 2.1 AA criteria. The four new Level AA criteria in WCAG 2.2 require additional manual testing alongside automated scanning — particularly focus obscured checks and drag interaction alternatives.
WCAG 2.2 Upgrade Checklist
If you are already compliant with WCAG 2.1 AA, use this checklist to identify what still needs attention. For a full accessibility review, see our ADA compliance checklist for small businesses.
Tab through every page — no focused element is entirely hidden by sticky headers, banners, or overlays
Every drag interaction (sliders, sortable lists, file uploads) has a single-click/tap alternative
All interactive targets are at least 24×24 CSS pixels or have adequate spacing
Login and authentication flows do not require solving puzzles or transcribing characters — autocomplete and password managers are supported
Help mechanisms (chat, phone, support link) appear in the same position on every page they appear
Multi-step forms do not ask users to re-enter information already provided in the same session
(Removed) You can stop testing for 4.1.1 Parsing if auditing against WCAG 2.2
Check your site against WCAG 2.1 AA now
WCAGsafe scans your pages with axe-core and returns a full violation list with plain-English explanations and fix instructions — free, no account required.
Run a free scanFrequently Asked Questions
Is WCAG 2.2 required for ADA compliance?
The DOJ Title II rule (effective April 2026 for large government entities) specifically references WCAG 2.1 Level AA, not 2.2. However, since WCAG 2.2 is backwards compatible with 2.1, meeting WCAG 2.2 AA means you also satisfy WCAG 2.1 AA. Private businesses under ADA Title III are not bound by a specific WCAG version in federal regulation, but courts consistently use WCAG 2.1 AA as the benchmark.
Does WCAG 2.2 replace WCAG 2.1?
WCAG 2.2 supersedes WCAG 2.1 as the current W3C Recommendation. It is backwards compatible — all WCAG 2.1 Level A and AA success criteria carry over into 2.2, with one exception: 4.1.1 Parsing was removed. If you currently meet WCAG 2.1 AA, you only need to address the 6 new A and AA criteria to be fully current.
What is the minimum target size under WCAG 2.2?
Under 2.5.8 (Target Size Minimum, Level AA), interactive elements must be at least 24×24 CSS pixels, or have sufficient spacing so a 24px circle centred on the target does not intersect another target. The enhanced Level AAA criterion requires 44×44 CSS pixels.
When was WCAG 2.2 published?
WCAG 2.2 became a W3C Recommendation on October 5, 2023. WCAG 2.1 was published in June 2018 and WCAG 2.0 in December 2008.
Related Guides
How to Fix WCAG Violations: Complete Guide for Non-Developers
Read ADA ComplianceADA Website Compliance Checklist for Small Businesses in 2026
Read ADA ComplianceADA Title II Deadline Is April 24, 2026 — Is Your Website Ready?
Read ADA ComplianceAccessibility Overlays — Why They Don't Work (and What Actually Does)
Read