WCAG 2.2 became a W3C Recommendation on October 5, 2023, adding 9 new success criteria and removing the old 4.1.1 Parsing requirement, which is now obsolete (W3C, 2023). If you already build to WCAG 2.1 Level AA, you are most of the way there, because 2.2 is backward compatible: content that meets 2.2 also meets 2.1, except that 4.1.1 no longer applies.
The gap between the standard and live sites is still wide. In 2026, 95.9% of the top one million home pages had detectable WCAG 2 failures (WebAIM Million, 2026), so most teams have not even cleared the older criteria, let alone the new ones. This post is the usable checklist, not the high-level overview. For the wider map of accessibility law and standards, start with our web accessibility compliance guide. Here we go criterion by criterion, with code-level pass and fail tests for the new 2.2 additions.
TL;DR: WCAG 2.2 carries forward the WCAG 2.1 criteria, minus 4.1.1 Parsing, and adds 9 new ones. Six of the new criteria sit at Level A or AA and are required for AA conformance: 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size (24 by 24 CSS pixels), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, and 3.3.8 Accessible Authentication. The other three are AAA and optional. Before you reach those, fix the criteria that fail most sites first: low-contrast text fails 83.9% of home pages and missing alt text fails 53.1% (WebAIM Million, 2026). Automated tools catch roughly 57% of issues by volume (Deque, 2021), so several new criteria need manual testing.
What Changed in WCAG 2.2?
WCAG 2.2 added 9 new success criteria and removed 4.1.1 Parsing when it became a W3C Recommendation on October 5, 2023 (W3C, 2023). It is backward compatible: anything that meets 2.2 also meets 2.1, with the single exception that 4.1.1 no longer applies. The four principles are unchanged: Perceivable, Operable, Understandable, Robust.
For a developer, only six of the nine new criteria actually matter for conformance, because Level AA is the legal floor that regimes like the EAA reference. The three AAA criteria are optional and are never required to claim AA. The table below splits the nine by level so you know which to schedule.
SC | Name | Level | Required for AA? |
|---|---|---|---|
2.4.11 | Focus Not Obscured (Minimum) | AA | Required |
2.4.12 | Focus Not Obscured (Enhanced) | AAA | Optional |
2.4.13 | Focus Appearance | AAA | Optional |
2.5.7 | Dragging Movements | AA | Required |
2.5.8 | Target Size (Minimum) | AA | Required |
3.2.6 | Consistent Help | A | Required |
3.3.7 | Redundant Entry | A | Required |
3.3.8 | Accessible Authentication (Minimum) | AA | Required |
3.3.9 | Accessible Authentication (Enhanced) | AAA | Optional |
So the working checklist is six criteria, not nine. Before we walk those, a caution: the new 2.2 criteria are not where most sites lose AA. The older criteria are. We will fix those first, then turn to the 2.2 additions.
Citation capsule: WCAG 2.2 became a W3C Recommendation on October 5, 2023. It adds 9 new success criteria and removes 4.1.1 Parsing, and it is backward compatible: content meeting 2.2 also meets 2.1, except that 4.1.1 no longer applies (W3C, 2023). Six of the nine new criteria sit at Level A or AA; the other three are AAA and are not required for AA conformance.
Which Criteria Should You Fix First?
Fix the existing criteria that fail most sites before the new 2.2 ones, because they are what cost you AA today. WebAIM found that 95.9% of the top one million home pages had detectable WCAG 2 failures in 2026, and just six categories account for roughly 96% of all detected errors (WebAIM Million, 2026). These are old criteria, not 2.2 additions, and they are mostly automatable.
The table below lists those six, ranked by how often they appear. If a scanner flags any of these, you fail AA before the new criteria even come into play. Each one maps to a long-standing Level A or AA success criterion.
Failure | % of home pages | Success criterion |
|---|---|---|
Low-contrast text | 83.9% | 1.4.3 Contrast (Minimum), AA |
Missing alt text | 53.1% | 1.1.1 Non-text Content, A |
Missing form labels | 51% | 3.3.2 Labels or Instructions / 4.1.2 Name, Role, Value, A |
Empty links | 46.3% | 2.4.4 Link Purpose (In Context), A |
Empty buttons | 30.6% | 4.1.2 Name, Role, Value, A |
Missing document language | 13.5% | 3.1.1 Language of Page, A |
All six figures come from the 2026 WebAIM Million (WebAIM Million, 2026). The quick checks: every image needs meaningful alt (or alt="" if decorative), every input needs an associated <label>, every link and button needs a discernible text name, the page needs a valid lang attribute on <html>, and text needs a 4.5:1 contrast ratio against its background. Our developer's guide to web accessibility testing walks the full audit workflow for these.
Citation capsule: In 2026, 95.9% of the top one million home pages had detectable WCAG 2 failures, and six categories cause roughly 96% of all errors: low-contrast text (83.9%), missing alt text (53.1%), missing form labels (51%), empty links (46.3%), empty buttons (30.6%), and missing document language (13.5%) (WebAIM Million, 2026). Fix these existing failures before the new 2.2 criteria.
The New WCAG 2.2 Criteria: A Developer Checklist
Six of the nine new WCAG 2.2 criteria are required for Level AA, and most are not detectable by an automated scanner (Deque, 2021). This section gives the pass and fail test for each, grouped by principle, with code hints where they help. The three AAA criteria (2.4.12, 2.4.13, 3.3.9) are optional and are not covered as required items here.
Operable: 2.4.11, 2.5.7, 2.5.8
2.4.11 Focus Not Obscured (Minimum), AA. When an element receives keyboard focus, at least part of it must stay visible. It must not be fully hidden behind a sticky header, sticky footer, cookie banner, or chat widget. Fail: tabbing to a field scrolls it under a fixed top bar so the focused control is completely covered. Fix: reserve space with CSS scroll padding so the browser stops short of the sticky element.
/* Keep focused targets clear of a sticky header/footer */
html {
scroll-padding-top: 5rem; /* height of the sticky header */
scroll-padding-bottom: 4rem; /* height of a sticky footer/cookie bar */
}2.5.7 Dragging Movements, AA. Any action that uses dragging needs a single-pointer alternative that does not require a drag. Sliders, drag-to-reorder lists, kanban boards, and map panning all qualify. Fail: a price slider can only be set by dragging the handle. Fix: add buttons or +/- controls, or let users click a track position. The exception is dragging that is genuinely essential or handled by the user agent.
2.5.8 Target Size (Minimum), AA. Pointer targets must be at least 24 by 24 CSS pixels, or undersized targets must have enough spacing that a 24px circle centered on each does not overlap a neighbor (W3C Understanding 2.5.8, 2023). Fail: a 16px icon button sitting flush against another. Fix: set a minimum size, or grow the hit area with padding while keeping the icon small.
/* Meet the 24px minimum without resizing the visible icon */
.icon-button {
min-width: 24px;
min-height: 24px;
/* Or enlarge the hit area while the glyph stays small: */
padding: 8px;
}This is the one new criterion a scanner can partly verify, because geometry is measurable. The exceptions still need human judgment: spacing, an equivalent control elsewhere on the page, inline targets within a sentence, user-agent-controlled elements, and cases where the size is essential (W3C Understanding 2.5.8, 2023).
Understandable: 3.2.6, 3.3.7, 3.3.8
3.2.6 Consistent Help, A. If a help mechanism (a contact link, chat launcher, FAQ link, or phone number) appears on multiple pages, it must appear in the same relative order and location on each. Fail: the support link sits in the header on one page and buried in the footer on the next. Fix: render it from one shared layout component so position is consistent everywhere.
3.3.7 Redundant Entry, A. Within a single process, such as a multi-step form or checkout, do not force users to re-enter information they already gave you. Fail: a checkout asks for the shipping address, then asks again for billing with no shortcut. Fix: auto-populate the repeated fields, or offer a "same as above" checkbox. The exception is re-entry that is essential, like reconfirming a new password.
3.3.8 Accessible Authentication (Minimum), AA. Login must not require a cognitive function test, such as remembering or transcribing a password or solving a puzzle, unless an alternative or assistance is available (W3C Understanding 3.3.8, 2023). Fail: a login form that blocks paste, breaking password managers, or a text-transcription CAPTCHA with no other route. You satisfy it with any one of these: support password managers and autofill (do not break autocomplete), allow copy and paste into auth fields, offer passwordless options like WebAuthn, OAuth, or email links, or use object-recognition rather than text-transcription CAPTCHAs.
<!-- Authentication-friendly markup: autocomplete works, paste is not blocked -->
<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="username" />
<label for="password">Password</label>
<input id="password" name="password" type="password" autocomplete="current-password" />
<!-- Do NOT add onpaste="return false" or similar; blocking paste fails 3.3.8 -->A note for EU teams: the European Accessibility Act currently references WCAG 2.1 AA through EN 301 549, with 2.2 AA expected to follow as the standard updates, so building these six now is the safer bet. See our EAA developer compliance guide for the timeline.
Citation capsule: WCAG 2.2 Target Size (Minimum), SC 2.5.8 AA, requires pointer targets of at least 24 by 24 CSS pixels, or sufficient spacing so a 24px circle on each does not overlap, with five exceptions: spacing, equivalent control, inline, user-agent, and essential (W3C Understanding 2.5.8, 2023). Accessible Authentication (Minimum), SC 3.3.8 AA, prohibits cognitive-function-test logins unless an alternative such as password-manager support or copy-paste exists (W3C Understanding 3.3.8, 2023).
What Can a Scanner Check, and What Needs a Human?
Automated tools catch roughly 57% of accessibility issues by volume, which leaves a large share that only manual testing finds (Deque, 2021). For the new 2.2 criteria, that split is sharp: most of them are largely manual. Only Target Size is partly automatable, because its geometry is measurable while its exceptions still need a person to judge.
The table below shows where each new A/AA criterion lands. Use it to plan coverage: run the automatable parts in CI, and route the rest to a manual pass with a keyboard and a screen reader.
Criterion | Scanner catches it? | Note |
|---|---|---|
2.4.11 Focus Not Obscured | Largely manual | Needs a real focus walk to see what a sticky element hides |
2.5.7 Dragging Movements | Largely manual | A tool cannot tell if a non-drag alternative exists |
2.5.8 Target Size (Minimum) | Partly automatable | Geometry is measurable; the five exceptions need judgment |
3.2.6 Consistent Help | Largely manual | Requires comparing help placement across pages |
3.3.7 Redundant Entry | Largely manual | Requires walking a multi-step process |
3.3.8 Accessible Authentication | Largely manual | Tools can flag blocked paste; the full check is manual |
The practical setup is two layers. Gate the detectable majority in your pipeline so a contrast failure or a missing label breaks the build before it merges; our GitHub Actions guide shows how to wire that with axe and Playwright, and our tool comparison helps you pick an engine. Then run a human pass for focus, dragging alternatives, help consistency, and login. For scanning many pages programmatically, an accessibility scanning API feeds checks into any pipeline.
Citation capsule: Automated tools catch roughly 57% of accessibility issues by volume (Deque, 2021). Among the new WCAG 2.2 A/AA criteria, only Target Size (2.5.8) is partly automatable; Focus Not Obscured, Dragging Movements, Consistent Help, Redundant Entry, and Accessible Authentication are largely manual and require keyboard and screen-reader testing.
Frequently Asked Questions
Is WCAG 2.2 backward compatible with 2.1?
Yes. WCAG 2.2 is backward compatible: content that meets 2.2 also meets 2.1, with one exception (W3C, 2023). The 4.1.1 Parsing criterion was removed in 2.2 because it is now obsolete, so it no longer applies. Everything else carries forward, and 2.2 simply adds 9 new criteria on top.
Do I have to meet the AAA criteria (2.4.12, 2.4.13, 3.3.9)?
No. Level AAA criteria are never required for AA conformance (W3C, 2023). Of the 9 new criteria, three are AAA: 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, and 3.3.9 Accessible Authentication (Enhanced). They are optional enhancements. For AA, you only need the six new criteria at Level A or AA.
What is the minimum target size in WCAG 2.2?
24 by 24 CSS pixels. SC 2.5.8 Target Size (Minimum), Level AA, requires pointer targets of at least 24 by 24 CSS pixels, or undersized targets with enough spacing that a 24px circle on each does not overlap (W3C Understanding 2.5.8, 2023). Five exceptions apply: spacing, equivalent control, inline, user-agent, and essential.
Does WCAG 2.2 ban CAPTCHAs?
No. SC 3.3.8 Accessible Authentication (Minimum), AA, does not ban CAPTCHAs outright. It prohibits ones that require a cognitive function test, like transcribing distorted text, unless an alternative or assistance exists (W3C Understanding 3.3.8, 2023). Object-recognition CAPTCHAs, where you identify pictures, are allowed because they do not test memory or transcription.
Can a scanner check all of WCAG 2.2?
No. Automated tools catch roughly 57% of accessibility issues by volume (Deque, 2021). Among the new 2.2 criteria, only Target Size is partly automatable. Dragging Movements, Consistent Help, Redundant Entry, Focus Not Obscured, and Accessible Authentication need manual testing with a keyboard and screen reader.
The Bottom Line
WCAG 2.2 is a small, manageable step if you already build to 2.1 Level AA. It carries the 2.1 criteria forward, drops 4.1.1 Parsing, and adds 9 new ones, of which only six sit at Level A or AA and are required for conformance (W3C, 2023). Your working checklist is those six: Focus Not Obscured, Dragging Movements, Target Size at 24 by 24 pixels, Consistent Help, Redundant Entry, and Accessible Authentication. The three AAA criteria are optional.
Sequence the work for the biggest win first. Most sites still fail the old criteria, with low-contrast text failing 83.9% of home pages (WebAIM Million, 2026), so clear those automatable defects in CI before you reach the 2.2 additions. Then run a human pass for the manual criteria, since tools catch only about 57% of issues (Deque, 2021). For the wider map of accessibility law and standards, see our web accessibility compliance guide, then gate your pipeline with accessibility testing in GitHub Actions.