WCAG 2.2 New Requirements: What Changed (and What It Means for ADA Lawsuit Risk)

What Actually Changed in WCAG 2.2

The W3C's WCAG 2.2 was published on 5 October 2023. It supersedes 2.1 as the standard, but 2.1 AA is still the most-cited line in current ADA web demand letters — that gap is closing fast. The version-2.2 churn is small in number and large in impact: nine new criteria, one obsolete, and almost all of the additions target the kinds of interactive failures a keyboard user hits on a typical small-business site.

Here are the nine new success criteria, grouped by level. The plain-English phrasing below is derived from the W3C's What's New in WCAG 2.2 guidance and the canonical criteria registry:

SC	Name	Level	Plain English
2.4.11	Focus Not Obscured (Minimum)	AA	When a UI element receives keyboard focus, nothing you authored (sticky headers, chat widgets, cookie banners) is allowed to fully cover it.
2.5.7	Dragging Movements	AA	If your UI lets users drag a slider or reorder a list, you must also offer a single-pointer alternative (a tap target, a button).
2.5.8	Target Size (Minimum)	AA	Every pointer target — a button, a link, a checkbox — must be at least 24 by 24 CSS pixels unless an adjacent control makes it effectively larger.
3.3.4	Error Prevention (Legal, Financial, Data)	AA	Checkout, account deletion, and other "consequential" actions must be reversible, checked, or confirmed.
3.3.8	Accessible Authentication (Minimum)	AA	Authentication must not require a cognitive function test (memorizing a password, transcribing a CAPTCHA) unless an alternative is offered.
3.2.6	Consistent Help	A	If a page lists a help mechanism — contact details, self-help links, a support form — that mechanism appears in the same relative order on every page.
3.3.7	Redundant Entry	A	If the user already entered their shipping address on page 1, page 2 of the checkout must not ask for it again.
2.4.12	Focus Not Obscured (Enhanced)	AAA	The focused indicator must never be hidden by author content — no hiding at all, even partially.
2.4.13	Focus Appearance	AAA	The focus indicator itself must meet a contrast ratio and a minimum visible area.

The single obsolete criterion is 4.1.1 Parsing — removed because HTML parsing requirements are now handled by the browser itself, and the criterion was famously unevaluable. If your scanner or vendor still cites 4.1.1 as a failure, they're testing a dead rule.

Why ADAflags' Evidence-Only Real-Chrome Runners Matter

Two of the five AA criteria are geometry problems. You cannot find them by parsing HTML or running axe-core against a JSDOM tree, because the failure only shows up when a real browser has actually rendered the page, executed the JavaScript, and laid the elements out at a real viewport width. Static analysis will report "manual review required" and move on. That is insufficient evidence to fix the issue, and it is certainly insufficient evidence to claim a passing site — which is the only thing that actually protects you in court.

ADAflags runs two purpose-built real-Chrome runners alongside the standard axe-core pass:

• Focus Not Obscured (2.4.11): a Chrome DevTools Protocol probe that opens the page in headless Chromium, walks the keyboard focus ring (up to 50 Tab presses per viewport, with an end-of-DOM loop guard), captures every focused element's bounding rect and computed z-index, then cross-checks them against every position: fixed and position: sticky element on the page. If a fixed header, an exit-intent modal, or a chat-widget launcher covers the focused element, the runner records the pair.
• Target Size (Minimum) (2.5.8): a real-browser runner that executes axe-core's experimental target-size rule (layout: true, allowExperimentalRules: true) across both desktop (1280×800) and mobile (390×844, 2× DPR) viewports, at zoom levels 1 and 2. The runner annotates nodes where axe-core flags a horizontal-adjacent target, a complex-control, or a user-agent-default equivalent — these are the documented exceptions SC 2.5.8 itself allows.

How WCAG 2.2 Maps onto ADA Lawsuit Risk

The new AA criteria add five new automated-failure surfaces that plaintiff scanners will begin tripping as soon as WCAG 2.2 is the cited line in a demand letter. The pattern is identical to what happened with WCAG 2.1: plaintiff firms ran the same scanners business owners could run, and the same scanners that flag missing alt text today will start flagging missing focus indication, undersized touch targets, and inaccessible authentication flows tomorrow.

Three of the five are particularly high-risk because they trip on patterns common to small-business sites:

Compare the big overlay vendors

Overlay widgets specifically fail every AA criterion in WCAG 2.2 that targets interaction geometry. Their floating toolbars cover the focused element (fails 2.4.11), their injected buttons drop below 24×24 (fails 2.5.8), and their injected DOM sits on top of native focus indicators (fails 2.4.11 a second time). The vendor-by-vendor breakdown:

How to Check Your Site Against WCAG 2.2 Today

ADAflags' free scan walks the live WCAG 2.1 AA checklist first, then layers in the WCAG 2.2 profile where the criterion has an automated test or a dedicated real-Chrome runner. You get a per-criterion verdict — passing, failing, manual review required, evidence gathered — and a ranked list of fixes. The two real-Chrome runners (2.4.11 and 2.5.8) attach evidence to the row regardless of whether a static scanner would have flagged the rule at all.

One scan is a snapshot — the same scanner plaintiff firms use runs every quarter against your site, and the violations they find in month 6 will look just like the ones a paid monitor finds in week 1. For ongoing protection, our Starter ($9.99/mo) and Pro ($29/mo) plans rescan your site monthly and email you the deltas.

Frequently Asked Questions

When does WCAG 2.2 become the legally cited standard?

WCAG 2.2 was published as a W3C Recommendation on 5 October 2023. Section 508, EN 301 549, and most enterprise RFP vehicles have rolled the new version in. Plaintiff firms follow the same adoption curve, so 2.2 is already a defensible cited standard in ADA web demand letters in 2026 — not a future concern.

Which new WCAG 2.2 success criteria are automatable?

Seven of the nine new criteria require manual review or a real browser. The exceptions — 3.3.7 Redundant Entry (heuristic) and 2.5.7 Dragging Movements (page-scripted) — have weaker axe coverage. 2.4.11 and 2.5.8 specifically need a real browser; ADAflags' two purpose-built runners cover both.

Can an accessibility overlay widget satisfy WCAG 2.2 AA?

No. WCAG 2.2 specifically tightens focus visibility and target size — both criteria directly affected by overlay toolbars that inject floating buttons over your content. Courts have repeatedly held that overlays do not satisfy WCAG 2.1 AA, and the 2.2 additions make the overlay failure even harder to argue around.

What does ADAflags scan that axe-core alone cannot?

ADAflags adds two real-Chrome runners on top of axe-core: a focus-not-obscured probe that walks the keyboard focus ring through the live DOM, and a target-size runner that runs axe's experimental target-size rule in a real browser at desktop and mobile viewports with zoom 1 and 2. Both persist evidence only — never a pass/fail claim they didn't actually verify.

Related reading: For the lawsuit-risk context that frames these new criteria, see ADA Website Lawsuit Risk. For the overlay breakdown against the new rules, see ADAflags vs. AccessiBe, ADAflags vs. UserWay, and ADAflags vs. AudioEye. For monthly scan monitoring after your first 2.2-aware check, see the Starter ($9.99/mo) or Pro ($29/mo) plans.