WCAG 2.2 Checklist

9 new criteria added in WCAG 2.2. Work through each one to reach compliance. Sign in to save progress across sessions and devices.

Your Progress 0 of 9 completed
WCAG 2.2 6 new AA criteria 3 new AAA criteria

Level AA - Required for Compliance

Focus Not Obscured (Minimum)SC 2.4.11AA

When a keyboard-focusable element receives focus, it must not be entirely hidden by sticky headers, footers, or overlapping content.

Keyboard users navigate by tabbing through elements. If a sticky header or cookie banner completely covers the focused element, keyboard users lose their place on the page and cannot continue navigating.

How to test
1Tab through every interactive element using only your keyboard
2Watch for sticky headers, footers, or banners that fully cover the focused element
3At least some part of the focused element must always remain visible
4Test after scrolling down — sticky elements behave differently mid-page
Common fail
Fix
W3C Understanding SC 2.4.11 ↗
Dragging MovementsSC 2.5.3AA

Any functionality using a dragging movement must also be achievable with a single pointer (click/tap) — no dragging required.

Users with motor disabilities, tremors, or switch access cannot reliably perform drag gestures. Every drag interaction needs an equivalent single-click alternative.

How to test
1Identify all drag interactions: sliders, reorder lists, resize handles, map panning, kanban boards
2For each one, verify a click or button alternative exists
3Test sliders respond to arrow keys and accept typed number input
4Check drag-to-reorder has up/down buttons or a keyboard shortcut
W3C Understanding SC 2.5.3 ↗
Target Size (Minimum)SC 2.5.8AA

Interactive targets must be at least 24x24 CSS pixels, OR have sufficient spacing so nearby targets don't overlap a 24px circle centered on each.

Small touch targets are extremely difficult for users with motor disabilities or tremors. A 24x24px minimum reduces missed taps and accidental activations.

How to test
1Open DevTools and inspect each button, link, and icon
2Check computed width and height — both must be at least 24px
3Inline text links within a sentence are exempt
4Padding counts toward the 24px — you don't need to change visual size
Common fail
Fix
W3C Understanding SC 2.5.8 ↗
Consistent HelpSC 3.2.6AA

Help mechanisms (chat, phone, FAQ, contact form) appearing on multiple pages must appear in the same relative position on each page.

Users with cognitive disabilities rely on consistency to find support. A chat button that moves between pages prevents these users from locating help when they need it.

How to test
1Identify all help mechanisms on your site (chat widget, phone number, help link)
2Visit at least 5 different pages and verify the help element appears in the same position
3Header help links, footer contact links, and fixed-position chat buttons all count
4User-initiated repositioning (moving a chat widget) is fine and does not fail this criterion
W3C Understanding SC 3.2.6 ↗
Redundant EntrySC 3.3.7AA

Information already entered by the user in the same process must not be required again — auto-populate or let them select it.

Re-entering data is cognitively taxing and error-prone, especially for users with memory, attention, or learning disabilities.

How to test
1Audit all multi-step forms and checkout flows
2Check if billing address defaults to shipping (with same-as checkbox)
3Verify search terms persist when filtering or paginating results
4Note: confirm-password and confirm-email fields are exempt as they verify, not repeat
Common fail
Fix
W3C Understanding SC 3.3.7 ↗
Accessible Authentication (Minimum)SC 3.3.8AA

Authentication must not require solving a cognitive function test — unless an alternative is available or a mechanism assists completion.

CAPTCHAs and memory puzzles are significant barriers for users with cognitive disabilities, dyslexia, or ADHD. Password autofill and magic links solve this.

How to test
1Check all login and registration flows
2If using CAPTCHA, verify an audio alternative is available
3Ensure password inputs allow autocomplete='current-password' so browser/manager can fill
4Consider adding OAuth (Sign in with Google/Apple) or magic link as an alternative
Common fail
Fix
W3C Understanding SC 3.3.8 ↗

Level AAA - Enhanced (Optional)

Focus Not Obscured (Enhanced)SC 2.4.12AAA

Stricter version of 2.4.11 — the focused element must be fully visible, with no part obscured by author-created content.

Same issue as 2.4.11 but with zero tolerance. The entire focused element, including its focus indicator, must be unobscured. This is the ideal for high-accessibility products.

How to test
1After passing 2.4.11, verify no part of any focused element is ever covered
2Check all scroll positions, especially with complex sticky layouts
3Test modals and overlays — focused elements behind them fail this criterion
W3C Understanding SC 2.4.12 ↗
Focus AppearanceSC 2.4.13AAA

The focus indicator must have an area at least as large as a 2px perimeter of the component, and at least 3:1 contrast between focused and unfocused states.

A thin or low-contrast focus ring is nearly invisible to users with low vision. This criterion ensures the focus indicator is genuinely perceivable to everyone.

How to test
1Check your :focus-visible styles — outline width must be 2px or more
2Use the Contrast Checker tool to verify the focus ring color vs adjacent background meets 3:1
3Never use outline: none without providing an equivalent custom focus style
4Test in both light and dark mode if your site has both
Common fail
Fix
W3C Understanding SC 2.4.13 ↗
Accessible Authentication (Enhanced)SC 3.3.9AAA

Stricter version of 3.3.8 — removes exceptions for object recognition and personal content. No cognitive function tests of any kind.

Even 'pick the images with bicycles' CAPTCHAs are banned at AAA — they require visual processing that may be impossible for some users. Magic links and passkeys work for everyone.

How to test
1Verify your auth flow has zero cognitive test requirements
2Image-recognition CAPTCHAs are not permitted even with audio alternatives
3Passkeys, magic links, and password-manager-compatible passwords all pass
4OAuth providers (Google, Apple) pass as long as they don't add their own CAPTCHAs
W3C Understanding SC 3.3.9 ↗