WCAG 2.2 became a W3C Recommendation in October 2023, and it is now the version most accessibility laws point to. If you build or maintain websites, it is the standard you will be measured against — by auditors, by procurement teams, and increasingly by courts. This checklist walks through what actually changed in 2.2, gives you real before-and-after code for the new requirements, and is honest about which of them an automated scanner can verify and which ones a human still has to test by hand.
We wrote this because most vendor "WCAG 2.2 guides" treat the new criteria as a footnote, show no code, and — surprisingly often — get the criterion count wrong. Let's fix that first.
How many success criteria does WCAG 2.2 actually have?
WCAG 2.2 contains 86 success criteria. Not 87. This trips people up because the arithmetic looks like it should be different: WCAG 2.1 had 78 criteria, WCAG 2.2 added 9 new ones, and 9 + 78 = 87. But WCAG 2.2 also removed one criterion — 4.1.1 Parsing — because the parsing problems it described are now handled by modern browsers and are effectively obsolete. So the real math is 78 − 1 + 9 = 86.
The W3C is explicit about this. The WCAG 2.2 Recommendation and its "What's New in WCAG 2.2" note both describe the removal of 4.1.1 Parsing and the addition of the nine new criteria. If a checklist tells you there are 87, it double-counted a criterion that no longer exists.
Those 86 criteria are still organized under the four familiar POUR principles — Perceivable, Operable, Understandable, Robust — and still split across three conformance levels: A, AA, and AAA. Nothing about that structure changed. What changed is the nine additions, so that is where the rest of this checklist focuses.
The 9 new WCAG 2.2 success criteria at a glance
Here are the nine new criteria and their conformance levels. Two are Level A, four are Level AA, and three are Level AAA.
| Criterion | Name | Level |
|---|---|---|
| 2.4.11 | Focus Not Obscured (Minimum) | AA |
| 2.4.12 | Focus Not Obscured (Enhanced) | AAA |
| 2.4.13 | Focus Appearance | AAA |
| 2.5.7 | Dragging Movements | AA |
| 2.5.8 | Target Size (Minimum) | AA |
| 3.2.6 | Consistent Help | A |
| 3.3.7 | Redundant Entry | A |
| 3.3.8 | Accessible Authentication (Minimum) | AA |
| 3.3.9 | Accessible Authentication (Enhanced) | AAA |
If you are targeting Level AA — which is the practical and legal bar almost everyone should aim for — you are on the hook for four of these: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), and Accessible Authentication (Minimum), plus the two Level A criteria, Consistent Help and Redundant Entry. The three AAA criteria are worth understanding but are not required for AA conformance.
The 9 new criteria, one by one — with code
2.4.11 Focus Not Obscured (Minimum) — Level AA
Plain English: When an element receives keyboard focus, it must not be entirely hidden by other content you authored — a sticky header, a cookie banner, a floating chat widget. At least part of the focused element has to remain visible.
Who it helps: Keyboard-only users and people with low vision who tab through a page. If the focused control scrolls behind a fixed header, they lose track of where they are.
The classic culprit is a sticky header combined with in-page anchor scrolling: the element gets focus, the browser scrolls it to the top of the viewport, and the sticky header sits on top of it. CSS scroll-margin-top is the fix — it reserves space so focused/scrolled targets clear the header.
/* Problem: a 72px sticky header hides focused targets */
header {
position: sticky;
top: 0;
height: 72px;
}
/* Fix: reserve scroll space so focused elements aren't obscured */
:target,
a:focus,
button:focus,
[tabindex]:focus {
scroll-margin-top: 88px; /* header height + a little breathing room */
}Testability: Mostly manual. A scanner can flag the presence of sticky/fixed elements but cannot reliably tell whether a given focused control ends up fully hidden — that depends on scroll position and layout at runtime.
2.4.12 Focus Not Obscured (Enhanced) — Level AAA
Plain English: The stricter sibling of 2.4.11. The focused element must be completely visible — no part of it obscured by author content.
Who it helps: The same audience, with a higher guarantee. Because it is Level AAA, it is not part of the standard legal bar, but it is a good target for content where keyboard navigation is central.
Testability: Manual, for the same reasons as 2.4.11.
2.4.13 Focus Appearance — Level AAA
Plain English: The visible focus indicator must be big enough and have enough contrast to be genuinely noticeable. Roughly, the focus indicator needs an area at least as large as a 2 CSS px thick perimeter of the component, and a contrast ratio of at least 3:1 between its focused and unfocused states.
Who it helps: Low-vision and keyboard users who need to see, at a glance, which control is focused. The single worst thing you can do here is outline: none with no replacement.
/* Anti-pattern: kills the focus indicator entirely */
button:focus { outline: none; }
/* Fix: a thick, high-contrast, offset focus ring */
button:focus-visible {
outline: 3px solid #1a1a1a;
outline-offset: 2px;
}Using :focus-visible rather than :focus means mouse users don't see a ring on click, while keyboard users still get a clear indicator — the best of both.
Testability: Partly automatable. Tools can detect a missing outline or a zero-width indicator, but judging whether the indicator meets the size and contrast thresholds against every possible background is unreliable, so treat this as manual-assisted.
2.5.7 Dragging Movements — Level AA
Plain English: Any functionality that works by dragging must also work with a single-pointer action that is not a drag — a tap or a click — unless dragging is essential. Sliders, drag-to-reorder lists, map panning, and "swipe to delete" all need a non-drag alternative.
Who it helps: People with motor impairments, tremors, or limited dexterity, and anyone using a head pointer, switch, or other assistive input where precise dragging is hard or impossible.
For a reorderable list, the fix is to add plain buttons alongside the drag handle:
<li>
<span>Item A</span>
<!-- Drag handle stays for mouse users -->
<span aria-hidden="true">⠿</span>
<!-- Non-drag alternative satisfies 2.5.7 -->
<button type="button" aria-label="Move Item A up">↑</button>
<button type="button" aria-label="Move Item A down">↓</button>
</li>For a slider, make sure the underlying <input type="range"> is still operable by clicking the track or using arrow keys, not only by dragging the thumb.
Testability: Manual. A scanner has no reliable way to know that a component depends on dragging or whether a non-drag path exists.
2.5.8 Target Size (Minimum) — Level AA
Plain English: Interactive targets should be at least 24 by 24 CSS pixels, so they are easy to hit. This is one of the most concrete new requirements — a real number you can check.
Who it helps: Touchscreen users, people with motor difficulties, and anyone poking at small icon buttons on a phone. Cramped icon toolbars and tiny "×" close buttons are the usual failures.
/* Fix: guarantee a 24x24 minimum hit area */
.icon-button {
min-width: 24px;
min-height: 24px;
/* Larger is better; 44x44 is a common mobile target */
}The criterion lists several exceptions where the 24px minimum does not apply:
- Spacing: the target is smaller than 24px but has enough space around it that a 24px circle centered on it does not overlap another target.
- Equivalent control: the same function is available through another control on the page that does meet the size.
- Inline: the target is a link inside a sentence or block of text, where sizing is constrained by the line.
- User-agent controlled: the size is determined by the browser and not modified by the author (for example, a native default checkbox).
- Essential: a particular presentation is legally required or essential to the information — for example, pins on a map at their true geographic positions.
Testability: Partly automatable but with big caveats. A tool can measure the rendered box of a control against 24px, but the spacing exception requires geometric reasoning about neighbors, and the equivalent control and essential exceptions require human judgment. Expect false positives from any tool that only measures boxes — verify flagged items manually.
3.2.6 Consistent Help — Level A
Plain English: If you offer help mechanisms — a contact link, a phone number, a chat widget, a help page, a self-help FAQ — they must appear in the same relative order on every page where they exist. Users shouldn't have to hunt for the help link because it moved.
Who it helps: People with cognitive and learning disabilities especially, but really everyone. Predictability reduces the effort of finding support.
Testability: Manual. Determining what counts as a "help mechanism" and whether its position is consistent across pages is a judgment call no scanner makes reliably.
3.3.7 Redundant Entry — Level A
Plain English: Within a single process (like a checkout), don't force people to re-enter information they already provided in the same session. Either auto-populate it or let them pick it from an available option. The obvious example: a "same as billing address" checkbox for shipping.
Who it helps: People with cognitive disabilities and memory limitations, and anyone for whom typing is effortful — but again, everyone benefits from fewer forms.
<label>
<input type="checkbox" name="shipping_same">
Shipping address is the same as billing
</label>
<!-- When checked, copy billing values into shipping
instead of asking the user to type them again -->Exceptions exist for information that must be re-entered for security (like re-typing a password) or where the previously entered value is no longer valid.
Testability: Manual. Recognizing that two fields ask for the same information across steps of a process is beyond reliable automated detection.
3.3.8 Accessible Authentication (Minimum) — Level AA
Plain English: Don't require a cognitive function test — remembering or transcribing a password, solving a puzzle, doing math, identifying images — as the only way to log in, unless there is an alternative, or the test has a mechanism to assist. In practice: allow password managers to paste and autofill, don't block copy/paste on password or one-time-code fields, and don't rely solely on a puzzle CAPTCHA.
Who it helps: People with cognitive disabilities, memory impairments, and dyslexia, who are disproportionately blocked by memory- and puzzle-based logins.
<!-- Anti-pattern: blocking paste defeats password managers -->
<input type="password" onpaste="return false">
<!-- Fix: allow paste + autofill, name the field correctly -->
<input type="password" name="current-password"
autocomplete="current-password">
<!-- One-time codes should autofill too -->
<input type="text" inputmode="numeric"
autocomplete="one-time-code">Testability: Partly automatable. A tool can catch things like an onpaste handler that blocks pasting, or missing autocomplete attributes. It cannot judge whether an image-recognition CAPTCHA has an accessible alternative — that needs a human.
3.3.9 Accessible Authentication (Enhanced) — Level AAA
Plain English: The stricter version. No cognitive function test at all — including object-recognition and personal-content tests — with no exception for offering assistance. This effectively pushes you toward passwordless methods, hardware keys, or email/OTP flows.
Who it helps: The same audience, with the exceptions removed. Being AAA, it is not part of the standard legal bar.
Testability: Manual.
Automated vs manual: what a scanner can and can't verify
This is where we part ways with the vendors who imply a widget or a scan makes you "WCAG 2.2 compliant." Most of the new 2.2 criteria are behavioral and contextual — they are about whether an alternative path exists, whether a component depends on dragging, whether help is in the same place across pages. Those are exactly the things static and even runtime automated tools are worst at. Here is an honest map.
| Criterion | Level | Automated detection |
|---|---|---|
| 2.4.11 Focus Not Obscured (Min) | AA | Manual — scanners can't judge runtime obstruction |
| 2.4.12 Focus Not Obscured (Enh) | AAA | Manual |
| 2.4.13 Focus Appearance | AAA | Partial — can catch missing outlines, not full thresholds |
| 2.5.7 Dragging Movements | AA | Manual — can't detect drag dependence |
| 2.5.8 Target Size (Min) | AA | Partial — can measure boxes; exceptions need review |
| 3.2.6 Consistent Help | A | Manual — cross-page judgment |
| 3.3.7 Redundant Entry | A | Manual — semantic, process-level |
| 3.3.8 Accessible Auth (Min) | AA | Partial — can flag paste-blocking / missing autocomplete |
| 3.3.9 Accessible Auth (Enh) | AAA | Manual |
Notice the pattern: not a single one of the nine is fully automatable. Three are partially detectable, and the rest require a human. That is not a knock on tools — it is a reason to use them for what they are good at and not to trust any claim that automation alone gets you to conformance.
Any product that promises a script, overlay, or widget will make your site "WCAG 2.2 compliant" is overclaiming. Automation finds a meaningful slice of issues fast; it does not replace manual review, and it certainly does not cover most of what is new in 2.2.
A working WCAG 2.2 checklist for your team
Use this as a practical pass over a page or component, on top of your existing 2.1 AA checks. For AA conformance, focus on the A and AA items.
- Target size (AA): Are all icon buttons, links-as-buttons, and touch controls at least 24×24 px, or do they qualify for an exception (spacing, inline, equivalent control, essential)?
- Dragging (AA): For every drag interaction — sliders, reordering, maps, swipe actions — is there a click/tap alternative?
- Focus not obscured (AA): Tab through the page. Does any focused control disappear behind a sticky header, banner, or floating widget?
- Accessible authentication (AA): Can users paste into password and OTP fields? Is
autocompleteset correctly? Is there a non-puzzle way to log in? - Consistent help (A): Do your help mechanisms appear in the same relative order across pages?
- Redundant entry (A): In multi-step flows, is previously entered information reused rather than re-requested?
- Focus appearance (AAA, recommended): Is the focus indicator thick and high-contrast? No bare
outline: none.
How to check your own site
A realistic testing strategy has three layers, in order of coverage.
1. Run an automated scan first. Open-source engines like axe-core are excellent at catching the mechanical, high-volume issues: missing alt text, form fields without labels, low color contrast, broken heading structure, missing language attributes. Industry rule of thumb — and axe-core's own maintainers say as much — is that automated testing reliably catches on the order of a third of WCAG issues. That third is still worth catching, because it is often the bulk of the raw error count and the cheapest to fix.
2. Test with a keyboard. Unplug the mouse. Tab through every interactive element. Can you reach everything, in a logical order, and see where focus is at all times? This is how you catch the Focus Not Obscured, Focus Appearance, and Dragging issues that scanners miss.
3. Test with a screen reader. Use VoiceOver (macOS/iOS), NVDA (Windows, free), or TalkBack (Android). Navigate by headings and landmarks, fill in a form, complete a checkout. This surfaces the naming, order, and context problems that only a human listening can judge.
If you want a fast starting point for layer one, you can run Inclusify's free WCAG scanner. It uses an axe-core-based engine to flag the automatable subset of WCAG 2.1 and 2.2 issues on a page and gives you a prioritized report. We will say the honest thing plainly: it catches the machine-checkable issues — the same roughly one-third — and it does not, and cannot, replace the keyboard and screen-reader review described above. Treat the scan as triage, not a certificate.
For teams that need ongoing coverage, our paid plans add scheduled re-scans and monitoring so regressions get caught as your site changes, and if you run a store, the Shopify integration wires the scanner and widget into your theme without touching code. But the widget and the scanner are aids to a real remediation process, not a substitute for one.
Where WCAG 2.2 fits legally
Level AA is the target that matters. In the United States, ADA-related settlements and the Department of Justice consistently reference WCAG at Level AA. In the European Union, the European Accessibility Act and the harmonized standard EN 301 549 are built on WCAG, and enforcement began in June 2025. Neither regime typically singles out "2.2" by number, but since 2.2 is backward-compatible with 2.1, meeting 2.2 AA is the safest way to satisfy what these laws actually require. If you conform to WCAG 2.2 at Level AA, you conform to 2.1 AA as well.
Frequently asked questions
How many success criteria does WCAG 2.2 have?
WCAG 2.2 has 86 success criteria. It added 9 new criteria to the 78 in WCAG 2.1 and removed 4.1.1 Parsing, which is now obsolete: 78 − 1 + 9 = 86. A count of 87 is a common error that forgets the removal of 4.1.1.
Is WCAG 2.2 legally required?
Most accessibility laws don't name a specific WCAG version in their text, but they point to WCAG, and Level AA is the practical benchmark used in ADA settlements and in the EU's European Accessibility Act and EN 301 549. Because WCAG 2.2 is backward-compatible with 2.1, conforming to 2.2 AA is the safest way to meet those obligations. Requirements vary by jurisdiction and sector, so confirm the specifics that apply to you.
Does WCAG 2.2 replace WCAG 2.1?
WCAG 2.2 is the latest version and the W3C recommends using it, but 2.1 and 2.0 remain valid W3C Recommendations rather than being withdrawn. Crucially, 2.2 is backward-compatible: content that meets 2.2 at a given level also meets 2.1 at that level (with the sole exception that 2.2 no longer includes 4.1.1 Parsing). In practice, target 2.2 AA and you cover the earlier versions too.
