WCAG 2.2 vs WCAG 2.1: what's new?
If your accessibility statement, VPAT, or internal audit still cites WCAG 2.1, it's worth knowing exactly what changed when WCAG 2.2 became current — new success criteria were added, and one older criterion was formally removed. Below is the plain-English rundown, drawn directly from the current 55-criterion Level A/AA checklist.
Auditing against the current standard for the first time? See the free VPAT template for how a WCAG-based conformance report is structured once your audit is done.
The headline number: 55 criteria, not 56
WCAG 2.2 is commonly described as "87 success criteria total" and "32 at Level A." That figure counts 4.1.1 Parsing, which WCAG 2.2 formally removed — but which some older summaries still list as a legacy entry. Excluding 4.1.1, WCAG 2.2 has 86 active success criteria: 31 at Level A and 24 at Level AA — 55 rows in a Level A/AA self-audit checklist, not 56. If you see other references quoting "56," they're likely still counting the removed 4.1.1.
What was removed: 4.1.1 Parsing
WCAG 2.0 and 2.1 included 4.1.1 Parsing (Level A) — a requirement that HTML be well-formed (no duplicate IDs, properly nested/closed tags) so assistive technology could reliably parse it. WCAG 2.2 formally removed this criterion. The rationale: 4.1.1 was written for an era when assistive technology parsed raw HTML directly. Modern browsers and assistive technology instead rely on the browser's own DOM/accessibility-tree APIs, which already handle malformed markup consistently — making a separate parsing-validity check redundant. Basic HTML validity is still good practice, but it's no longer a distinct testable success criterion under 2.2.
Practically: if your existing WCAG 2.1 audit has a 4.1.1 row, you can drop it when you move to 2.2 — it doesn't carry over as "Not Applicable" or need retesting, it's simply gone from the current standard.
What was added: six new criteria at Level A/AA
WCAG 2.2 added new success criteria addressing gaps identified since 2.1 — particularly around focus visibility, dragging interactions, target sizing, and authentication that doesn't rely on memory or puzzle-solving. The ones that apply at the commercially-required Level A and AA (the levels this kit's checklist covers) are:
| Criterion | Level | What it checks |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Focused elements aren't entirely hidden behind sticky headers, cookie banners, or other overlays. |
| 2.5.7 Dragging Movements | AA | Any drag-and-drop interaction has a single-pointer, non-dragging alternative (e.g. tap to select, tap to place). |
| 2.5.8 Target Size (Minimum) | AA | Interactive targets are at least 24×24 CSS pixels, or have sufficient spacing, unless inline in text or otherwise exempt. |
| 3.2.6 Consistent Help | A | If help mechanisms (contact info, chat, FAQ link) appear on multiple pages, they appear in the same relative order/location. |
| 3.3.7 Redundant Entry | A | Information the user already provided earlier in the same process isn't re-requested, unless necessary. |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login doesn't require a cognitive function test (solving a puzzle, memorizing/transcribing) unless an alternative is offered. |
A few patterns worth noticing: three of the six (2.4.11, 2.5.7, 2.5.8) target interaction design — focus management, drag alternatives, and touch-target sizing — areas that got more scrutiny as mobile and touch interfaces matured past what WCAG 2.1 anticipated. 3.3.8 specifically addresses login flows that rely on memory or puzzle-solving (a barrier for users with cognitive disabilities), reflecting growing attention to authentication accessibility.
Why this matters for an existing conformance claim
If your accessibility statement or VPAT still says "WCAG 2.1 Level AA," it's not wrong — but it's citing a superseded version of the standard. Section 508's 2018 refresh names WCAG 2.0 AA specifically, and ADA settlement practice most commonly references WCAG 2.0 or 2.1 AA — so a 2.1 claim isn't a compliance failure. It is, however, a signal to sophisticated reviewers (enterprise procurement, legal teams) that your last audit predates the current standard. Re-auditing against the six new 2.2 criteria and dropping 4.1.1 is a relatively contained update compared to a full re-audit from scratch, since the other 49 criteria carry over unchanged.
Audit against the current standard, not the last one
The AccessibleDocs Core Kit's WCAG 2.2 self-audit checklist is built against the current 55-criterion Level A/AA standard described above — so you're not retrofitting a 2.1 audit or guessing which rows to add.
Audit once, against the standard that's actually current
Core Kit ($99) includes the WCAG 2.2 self-audit checklist, an accessibility statement template, a remediation plan template, and an internal accessibility policy.
Get Core — $99 Compare Core vs ProFAQ
Do I need to redo my entire audit for WCAG 2.2?
No — 49 of the 55 Level A/AA criteria are unchanged from 2.1. You need to test the six new criteria (focus obscuring, dragging, target size, consistent help, redundant entry, accessible authentication) and can drop 4.1.1 Parsing, which was removed.
Is WCAG 2.1 still acceptable for compliance purposes?
In many contexts yes — both Section 508's 2018 refresh and common ADA settlement practice reference WCAG 2.0 or 2.1 AA. WCAG 2.2 AA is a superset that meets or exceeds those references, which is why it's the recommended current target rather than a strict requirement.
Is this legal advice?
No. This page and the linked templates are professional documentation resources, not legal advice, and using them does not create an attorney-client relationship. Have qualified counsel review your conformance claims before publishing or submitting them to a buyer.