If you build for the web, WCAG 2.2 is no longer optional. It became a W3C Recommendation on October 5, 2023, and it’s already referenced by the EU’s European Accessibility Act (enforced since June 2025) and increasingly cited in ADA lawsuits in the U.S.
The good news: WCAG 2.2 is fully backward-compatible with 2.1. You don’t have to re-test everything — just layer in the 9 new success criteria (SC) on top of what you already have.
The less-good news: 6 of those 9 are Level AA, which means they’re the minimum legal bar in most jurisdictions. You need to know them.
Here’s a practical breakdown of all 9, grouped by what they actually try to solve.
Group 1: Keyboard focus should never be hidden
Two closely related criteria about sticky headers and footers eating your keyboard focus.
2.4.11 Focus Not Obscured (Minimum) — Level AA
What it requires: When an element receives keyboard focus, at least part of it must remain visible. Sticky headers, cookie banners, or floating chat widgets cannot fully cover the focused element.
Why it matters: Keyboard users navigate by Tab. If a sticky header covers the focused input, they literally cannot see where they are on the page.
Common failure: A sticky position: fixed header that’s 80px tall. When the user tabs down to an input, the input scrolls into view — but behind the header.
Quick fix: Add scroll-padding-top: 80px; to your html element so the browser scrolls focused elements into a safe zone below fixed headers.
html {
scroll-padding-top: 80px;
}
2.4.12 Focus Not Obscured (Enhanced) — Level AAA
Same idea, stricter: no part of the focused element can be hidden. Level AAA, so not a legal baseline for most orgs, but worth targeting for government and healthcare.
Group 2: Focus indicators should be visible and strong
2.4.13 Focus Appearance — Level AAA
What it requires: Focus indicators must be thick enough and have enough contrast to actually be seen. Specifically: a perimeter at least as thick as a 2-CSS-pixel-wide line around the focused element, with a 3:1 contrast ratio against the unfocused state.
Why it matters: A faint 1px dotted outline on a light grey background is technically a focus indicator. It’s also invisible to anyone over 40.
Practical baseline: A solid 2px outline with a high-contrast color. Don’t disable browser defaults unless you’re replacing them with something better.
:focus-visible {
outline: 2px solid #0066ff;
outline-offset: 2px;
}
Group 3: Input should work without fine motor control
2.5.7 Dragging Movements — Level AA
What it requires: Any functionality that works via dragging must also work via a single-pointer alternative (tap, click). Exception: when dragging is genuinely essential (like drawing on a canvas).
Why it matters: Users with tremors, limited grip strength, or who use switch devices cannot drag reliably.
Common failure: A Kanban board where the only way to move a card between columns is drag-and-drop.
Fix: Add a menu, keyboard shortcuts, or a “move to” button next to each draggable item.
2.5.8 Target Size (Minimum) — Level AA
What it requires: Interactive targets must be at least 24x24 CSS pixels, unless they’re inline in text, part of a sentence, or the user agent handles sizing.
Why it matters: Small buttons are a barrier for anyone with motor issues and extremely frustrating on mobile.
Common failure: A close button that’s 16x16px in the corner of a modal.
Fix: Even if the icon is small, pad the clickable area to at least 24x24.
.close-button {
width: 24px;
height: 24px;
padding: 4px;
}
Group 4: Help users remember less
3.2.6 Consistent Help — Level A
What it requires: If help mechanisms (contact info, help links, chat widgets, FAQs) appear on multiple pages, they must appear in the same relative order across those pages.
Why it matters: Users with cognitive disabilities build a mental map of where things are. Moving the chat icon from bottom-right to top-left between pages forces them to re-learn the layout each time.
Fix: Pick a spot for help and stick to it across the entire site.
3.3.7 Redundant Entry — Level A
What it requires: If a user has already entered information in the same session, don’t ask them to enter it again. Auto-populate, offer to copy from a previous step, or let them select from earlier entries. Exceptions: re-entry for security (password confirmation) or when the original info is no longer valid.
Why it matters: Multi-step checkout flows that ask for the shipping address, then ask for the billing address again with no “same as shipping” option. Painful for everyone, impossible for some.
Fix: A simple “Same as shipping” checkbox, or prefill billing from shipping by default.
3.3.8 Accessible Authentication (Minimum) — Level AA
What it requires: Authentication cannot rely on a cognitive function test (like remembering a password, transcribing a code, or solving a puzzle) without an alternative. Allowed alternatives: password managers (don’t block paste!), biometrics, magic links, passkeys, or object recognition (but not text-based puzzles).
Why it matters: Remembering complex passwords is a cognitive test. So is typing a 6-digit code from an SMS while it’s still visible. People with dyslexia, dyscalculia, or memory issues are locked out.
Common failure: Login forms that disable paste on the password field.
Fix: Enable paste. Support password managers. Offer magic link or passkey as an alternative.
3.3.9 Accessible Authentication (Enhanced) — Level AAA
Same as above, but stricter: even object recognition and personal content tests are disallowed as the primary method. Level AAA, relevant for high-security contexts where you still want to be accessible.
Quick reference table
SC 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
To hit WCAG 2.2 Level AA (the practical legal baseline), you need all the A and AA criteria — 6 of these 9.
What automated tools can and can’t catch
Automated scanners can reliably flag target size issues, focus indicators missing outright, and some dragging/keyboard problems. They struggle with:
• Whether a specific drag-drop interaction has a keyboard alternative
• Whether help placement is “consistent” across pages
• Whether a user is actually being asked for redundant information
Plan for automated scans to catch roughly half. The rest needs manual testing — real keyboard navigation, real screen reader walkthrough, real users with disabilities where possible.
One more thing
I’ve been building AccessCheck AI — an AI-powered scanner that goes beyond flagging violations and actually generates ready-to-paste Before/After code fixes for the issues it finds. Free plan includes 3 scans a month, no credit card. Built it because every other scanner I tried gave me a 300-row CSV and left me to figure out how to fix things.
Would love feedback, especially if you find edge cases on your own sites. Drop a reply here or DM me.
Sources
• W3C WCAG 2.2 Recommendation
• What’s New in WCAG 2.2 (W3C WAI)
• U.S. Access Board announcement
