WCAG 2.2 Success Criteria Explained: Pass and Fail Examples for Devs and Auditors

I once spent three days auditing a retail site that was “fully WCAG compliant” according to its vendor’s automated scan. The scan missed nine WCAG 2.2 failures, including a checkout flow that trapped keyboard users on a disabled submit button. The client got a demand letter two months later anyway.

WCAG 2.2 added nine new success criteria on top of 2.1. Most automated tools still catch fewer than half of them. In benchmark testing across all 87 WCAG 2.2 criteria using axe-core, only 29 criteria have automated rule mappings, while 58 criteria have zero automated coverage. At Level AA, the coverage is even starker: only 7 of 24 criteria can be detected by static rule engines, leaving 17 out of 24 criteria requiring hands-on manual verification. The WebAIM Million study, which scans the top million home pages every year, found detectable WCAG failures on 95.9 percent of them in its latest edition, with an average of 56.8 errors per page. If you audit sites or build them, you need to know what the nine 2.2 criteria actually require and how to test them by hand.

What Changed From WCAG 2.1 to 2.2

WCAG 2.2 became a W3C Recommendation on October 5, 2023. It keeps all 2.0 and 2.1 criteria, removes one (4.1.1 Parsing, because browsers now handle parsing reliably), and adds nine new ones: two at Level A, four at Level AA, and three at Level AAA. The W3C publishes the full normative text in the official WCAG 2.2 specification, and the WAI maintains a plain-language breakdown of every addition in what’s new in WCAG 2.2.

The new criteria cluster around three themes: keyboard and focus control, pointer and touch usability, and help with forms and redundant entry. Two target cognitive accessibility directly.

Regulators have already moved. In April 2024 the U.S. Department of Justice finalized a rule under Title II of the ADA requiring state and local government web content and mobile apps to conform to WCAG 2.1 AA, with deadlines in April 2026 and 2027 depending on jurisdiction size. See the DOJ’s web and mobile accessibility rule. Private businesses sit outside that rule, but courts and demand letters keep borrowing its reasoning, and Section 508 already binds federal agencies through the U.S. Access Board’s standards.

For broader context on how these fit into your overall compliance posture, our web accessibility and WCAG guide covers the framework from first principles. If you are wondering why this matters commercially, the pattern of litigation is laid out in our breakdown of ADA website lawsuit trends.

Level A Criteria: The Non-Negotiables

Two new Level A criteria apply to every site. These are the easiest failures for plaintiffs’ attorneys to demonstrate, so treat them as blockers.

3.2.6 Consistent Help

What it requires: If a page offers help mechanisms (chat, phone number, FAQ link), they appear in the same relative order across pages. One can be missing on a page, but the ones present must stay in order.

Pass example: “Contact support” sits last in the header nav on every page of the marketing site.

Fail example: The phone number appears in the header on the homepage, in the footer on product pages, and inside a hamburger menu on checkout. Users who rely on consistent placement lose it exactly when they are stuck.

3.3.7 Redundant Entry

What it requires: If information was already entered, do not ask for it again within the same process, unless it is needed for security. Auto-population or selectable prior values count as passing.

Pass example: A checkout flow auto-fills the shipping email into the account-creation step, editable but pre-filled.

Fail example: A job application that asks for your full work history in a text field, then demands the same history re-entered into twelve separate date-range fields. This is the single most common 2.2 failure I find in form-heavy SMB sites, and it disproportionately hits users with memory impairments.

Level AA Criteria: Where Most Audits Fail

The four new Level AA criteria are where I spend most of my billable hours. These map directly to cognitive load and motor accessibility, and two of them (2.4.11 and 2.5.8) are the ones automated tools most often miss entirely.

2.4.11 Focus Not Obscured (Minimum)

What it requires: When a component receives keyboard focus, it must not be fully hidden by sticky headers, footers, cookie banners, or chat widgets. Partially obscured is allowed; fully hidden is not. Note this criterion sits at Level AA, not A.

Pass example: A page with a 72px sticky header adds scroll-margin-top: 90px to focused elements, so a focused link always sits visibly below the header.

Fail example: An Intercom-style chat bubble covers the focused “Submit” button on a mobile viewport. The user tabs, the focus indicator disappears under the widget, and keyboard navigation dies.

Test procedure:

1. Load the page at 360px and 1280px widths.
2. Tab through every interactive element, including elements inside dialogs.
3. Watch for any focused element that is 100 percent hidden by sticky content.
4. Scroll the focused element into view with a sticky banner open and repeat.

Failure mode I’ve seen: Cookie consent banners that re-render on scroll and re-cover the focused element after the browser scrolls it into view. The fix is usually CSS scroll-margin plus keeping banner z-index below focused elements.

2.5.7 Dragging Movements

What it requires: Any action done by dragging must also work with a single pointer action (click or tap), unless dragging is the core mechanic (a drawing app, for example).

Pass example: An image carousel has drag support, but also left and right arrow buttons that advance slides.

Fail example: A Kanban-style task board where moving a card requires drag and drop with no alternative. Users with tremors, limited range of motion, or a trackball cannot complete it.

Test procedure:

1. Identify every draggable element: sliders, cards, map pins, crop handles.
2. Try to complete each action with mouse clicks only. No press-and-move.
3. Check that an equivalent single-pointer control exists and is keyboard reachable.

2.5.8 Target Size (Minimum)

What it requires: Interactive targets must be at least 24 by 24 CSS pixels, or have enough spacing that a 24px circle centered on the target does not overlap another target. Inline links in sentences are exempt.

Pass example: Icon buttons of 28px each, arranged with 8px gaps in a toolbar.

Fail example: A row of 18px social icons with 2px gaps. Tapping the intended icon on a phone hits a neighbor half the time. I measured this exact pattern on a dental clinic site last year; the mobile conversion form sat right below it, and bounce rates on iOS were 34 percent higher than Android.

Test procedure:

1. Zoom the page to 100 percent at a mobile viewport.
2. For each target, imagine a 24px circle centered on it. Check for overlap with adjacent targets.
3. Flag any overlapping pair. DevTools’ element inspector gives you exact bounding boxes.

3.3.8 Accessible Authentication (Minimum)

What it requires: No cognitive function test is required to log in, unless it provides an alternative. That means no CAPTCHAs that depend on memorization, transcription, or puzzles, and no password-only recall demands without some assistance. Object-recognition CAPTCHAs (“click the traffic lights”) are still allowed at this level; the stricter 3.3.9 (below) removes even those.

Pass example: Login with a passkey, magic link, or “paste is allowed” password field.

Fail example: A login page that blocks password managers and requires solving a math puzzle (“what is 7 plus 3?”) before the field accepts input.

Tooling note: hCaptcha offers an accessibility mode on its paid tiers; Cloudflare Turnstile is free, runs no visual puzzle, and satisfies this criterion out of the box. Budget either one instead of rolling your own.

2.5.3 Label in Name (from 2.1, now critical for 2.2 audits)

While not new in 2.2, I flag it here because every 2.2 remediation project I have run surfaces it: the accessible name of a control must contain its visible text. A button reading “Buy now” must not have an accessible name of “cta_primary_1.”

Level AAA Criteria: Plan Ahead, Do Not Panic

The three new Level AAA criteria are not required for AA conformance, the level regulators, courts, and contracts almost always reference. I still test against them: AAA today tends to become the AA floor in the next WCAG cycle, and fixing them early is cheaper. This is also where most published guides get the standard wrong, listing all nine additions as “Level A and AA” and scaring teams into over-scoping (treating AAA items as legal blockers) or under-scoping (missing that 2.4.11 is AA, not A). Get the levels right first, then prioritize.

2.4.12 Focus Not Obscured (Enhanced)

Same theme as 2.4.11 but stricter: no part of the focused component may be covered by authored content. A sticky header overlapping even 10 percent of a focused button fails this at Level AAA.

Test procedure: Repeat the 2.4.11 tab-through, but flag any partial overlap. Overlaying cookie banners while tabbing is the repeat offender here.

2.4.13 Focus Appearance

What it requires: The keyboard focus indicator must have an area at least as large as a 2 CSS pixel thick perimeter around the component, and a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.

Pass example: A 2px solid outline offset 2px from a button, in a color 4:1 against both the button and the background.

Fail example: A barely-visible 1px dotted outline in a color 1.5:1 against the page background. Browser defaults fail this on many dark themes out of the box. If you are already working on visual consistency issues, our technical SEO audit checklist overlaps with accessibility checks more than most teams expect.

3.3.9 Accessible Authentication (Enhanced)

The strict version: no cognitive function test at all for login. Object-recognition CAPTCHAs fail. Passkeys, magic links, and copy-paste-friendly fields pass. If your auth flow still leans on puzzles, this is your migration target for 2026.

A Testing Workflow You Can Run Today

Manual testing catches what automation cannot. axe DevTools (free browser extension; Deque sells team and CI licensing for the pro tooling) covers roughly 40 percent of 2.2 criteria. The rest is hands-on. Here is the sequence I run on every audit, in order, because early failures mask later ones:

1. Zoom and reflow. Set viewport to 320px wide, zoom to 400 percent. Check for horizontal scrolling and lost content. (1.4.10, carried over, but it breaks the tab order for 2.2 tests.)
2. Keyboard-only pass. Unplug the mouse. Work through the full task flow: search, add to cart, checkout, login. Log every point where focus disappears, gets trapped, or skips a control.
3. Focus appearance check. For each focused element, measure indicator thickness and contrast against both states. DevTools computed styles plus a contrast checker like the TPGi Colour Contrast Analyser (free) handles this.
4. Sticky content sweep. Re-run the keyboard pass with the cookie banner accepted, dismissed, and mid-animation. Watch for obscured focus on every state change.
5. Drag and target audit. List every draggable and every target under 24px. Try single-pointer alternatives.
6. Form flow test. Complete a real transaction with password manager disabled, then enabled. Note every re-requested data point (Redundant Entry) and every login friction point (Accessible Authentication).
7. Help consistency pass. Skim five representative pages and record the position of every help mechanism. Compare relative order.

Total time for a five-page SMB site: about 90 minutes once you have done it a few times. First pass, budget half a day.

Common Failure Modes by the Numbers

Across the last 23 SMB sites I audited in 2025 and 2026, here is the distribution of 2.2 failures:

Criterion	Sites failing	Root cause
2.4.11/2.4.12 Focus obscured	17 of 23	Sticky headers and chat widgets with no scroll-margin
3.3.8/3.3.9 Accessible authentication	14 of 23	Legacy CAPTCHAs, blocked password managers
2.5.8 Target size	12 of 23	16px icon buttons in mobile navs
3.3.7 Redundant entry	9 of 23	Multi-step forms rebuilt per step from scratch
2.4.13 Focus appearance	8 of 23	Browser default outline removed, nothing replaced it
2.5.7 Dragging movements	6 of 23	Sliders and upload widgets without click alternatives
3.2.6 Consistent help	5 of 23	Template drift across page types

Two patterns repeat. First, focus management bugs almost always trace back to a third-party widget the marketing team installed without engineering review. Second, authentication failures trace back to a security decision made years ago that nobody documented. When you remediate, write the decision down.

Remediation Priority for Small Teams

You cannot fix everything in a sprint. Here is the order I recommend, ranked by lawsuit exposure and user impact:

1. Kill the CAPTCHA problems (3.3.8, 3.3.9). Swap to Turnstile or passkeys this quarter. Highest legal exposure, lowest effort.
2. Fix focus visibility and obscuring (2.4.11, plus AAA headroom from 2.4.12 and 2.4.13). Mostly CSS: restore outlines, add scroll-margin-top, audit z-index. One to two days of work for most sites, and it future-proofs you if the AAA criteria drop to AA in a later WCAG version.
3. Enlarge mobile targets (2.5.8). Set a 44px minimum in your design system going forward; 24px is the floor, not the goal.
4. Audit drag interactions (2.5.7). Add arrow-button alternatives to sliders and drag-and-drop boards.
5. Wire form state through the whole flow (3.3.7). Persist entered data across steps. This one is engineering-heavy but it also lifts conversion rates, so frame it that way to the business.
6. Template audit for help placement (3.2.6). A half-day content audit once your templates stabilize.

Budget reality: for a typical WordPress or Shopify SMB site, items 1 through 3 run $1,500 to $4,000 with a freelance accessibility dev, or about four to six days of internal engineering time. Items 4 through 6 roughly double that. Waiting for a demand letter triples it, because now you are paying for rush work plus counsel review.

Conclusion

WCAG 2.2’s nine new criteria are not exotic. They are the mechanical failures I find on almost every SMB site I audit: hidden focus, tiny targets, puzzle logins, and forms that make users retype their own lives. Automated scanning alone will not catch most of them. A 90-minute manual pass with the checklist above will catch nearly all of them. Fix the authentication and focus issues first, document your decisions, and retest after every new third-party widget lands on the page. Compliance is not a one-time certificate; it is a maintenance habit, and it is far cheaper than the alternative.