WCAG 2.2 adoption rate: where the recommendation has and hasn’t entered law, procurement, and audit practice — a 2026 survey
The W3C published WCAG 2.2 as a Recommendation on 5 October 2023. Two and a half years later, it is the version every reputable auditor benchmarks against and the version every major design system has at least partially absorbed — but not yet the version most of the world’s accessibility law actually cites. The lag shows up in nine specific places: the nine new success criteria. This field guide catalogues each of them.
The previous installments in this series mapped the legal-reference picture from the top down — jurisdiction by jurisdiction, statute by statute. That view is useful for compliance officers and procurement leads. It is less useful for the developer, designer, or product manager who has to ship the actual remediation work. This guide takes the opposite view: it works from the success criterion outward.
Every entry below is one of the nine new WCAG 2.2 success criteria — the precise edits the working group made to the previous Recommendation. For each one, we describe what the criterion requires in plain language, how often the field is actually catching the failure in 2026 audits, the production-site mechanism that trips it, and the engineering fix. Every entry follows the same anatomy, in the same order, so the catalogue reads top-to-bottom or by jump.
9 new success criteria · ranked by 2026 audit-failure frequency
| ID | Pattern (SC + title) | Level | Audit failure rate |
|---|---|---|---|
| E·01 | 2.4.13 Focus Appearance | AAA | >70% |
| E·02 | 2.5.8 Target Size (Minimum) | AA | Top AA failure |
| E·03 | 3.3.8 Accessible Authentication (Min.) | AA | Highest-impact AA |
| E·04 | 2.4.11 Focus Not Obscured (Min.) | AA | Top-5 AA |
| E·05 | 2.5.7 Dragging Movements | AA | Narrow surface |
| E·06 | 3.3.7 Redundant Entry | A | Server-side fix |
| E·07 | 3.2.6 Consistent Help | A | Editorial |
| E·08 | 2.4.12 Focus Not Obscured (Enh.) | AAA | Stricter cousin of E·04 |
| E·09 | 3.3.9 Accessible Authentication (Enh.) | AAA | Stricter cousin of E·03 |
Failure-rate descriptors aggregated from independent auditor reports issued through Q1 2026; methodologies vary across firms, so figures are directional rather than precise. Five of nine criteria sit at level AA — the regulatorily-binding tier — and are the rows procurement clauses must contend with first.
Where the lag actually shows up
Legal incorporation of WCAG happens by version pinning. A regulation does not say “current WCAG”; it says WCAG 2.0, or WCAG 2.1, with a level and a date. Updating the pin is an act of statutory or regulatory amendment. As of mid-2026, the world’s major accessibility regulations are still distributed across three versions: US Section 508 at 2.0; EU EN 301 549 V3.2.1 at 2.1; UK PSBAR at 2.1 (with a closed February 2026 consultation pending). The pragmatic mid-decade compromise — “WCAG 2.1 AA at minimum, with VPAT 2.5 reporting against 2.2 where the vendor’s response permits” — has become routine procurement language.
Procurement moves faster than the law. The ITI’s VPAT 2.5 / ACR template, released January 2025, added reporting columns for each of the nine new criteria; any VPAT issued after that date against the WCAG version of the template is reporting against 2.2. Big-tech design-system adoption has moved fastest of all — Microsoft, Apple HIG, Material 3, Adobe Spectrum and Meta have all aligned to 2.2 through 2024–25. The catalogue that follows is the engineering counterpart: the nine specific edits the working group made, and what they are actually catching in production.
Five of the nine new SCs are AA — these are the regulatorily-binding ones, the rows a 2026 procurement clause cannot avoid.
Focus indicators were the working group’s first concern in the 2.2 brief. Two criteria address whether the focus ring is ever hidden by author content; a third specifies the indicator itself. Together they catch the most-overlooked subsurface of every keyboard journey.
Focus Appearance — 2.4.13 AAA
When a user interface component receives keyboard focus, the focus indicator must meet a minimum contrast ratio of 3:1 against adjacent colour and cover at least the perimeter of a 2 CSS-pixel solid outline around the focused element, or an equivalent indicator area. The criterion is one of the few WCAG additions that specifies measurable geometry rather than behaviour.
The default browser focus rings that designers spent fifteen years overriding for aesthetic reasons fail this measurement on the majority of audited production sites. Custom focus styles tend to use 1px outlines or low-contrast accent colours that look correct in design tools but score below 3:1 against the background of the actual focused element.
The figure matters even though the criterion is AAA: it indicates what would happen if a future regulator pinned at WCAG 2.2 level AAA, or if a procurement contract elevated this one criterion.
Set a 2 CSS-pixel outline at a colour scoring at least 3:1 against the element’s background; verify with a contrast checker rather than by eye. Where the design system overrides browser focus, expose a focus-style token that designers cannot accidentally lower below the contrast threshold.
Target Size (Minimum) — 2.5.8 AA
The hit target of every pointer input must be at least 24 by 24 CSS pixels, except where the target is inline in a sentence, where it is sized by the user agent, where an equivalent target is available, or where the target’s function is essential. The criterion measures the hit target, not the visible icon.
The criterion catches a specific UI pattern: dense icon toolbars, particularly in editors, dashboards, and data-table headers. Most icon-button libraries default to 16×16 or 20×20 visual icon sizes inside a slightly larger hit target. Where the hit target is also below 24×24, the criterion fails — and toolbar designers routinely tighten gaps to fit more icons into limited horizontal space.
Set a minimum hit-target token of 24 by 24 CSS pixels in the design system, applied via padding rather than the icon’s own dimensions. Where toolbars cannot accommodate the floor, add adequate spacing so adjacent targets are not within the criterion’s overlap exclusion. Provide a settings-level equivalent (a larger menu) for the genuinely cramped surfaces.
Accessible Authentication (Minimum) — 3.3.8 AA
The authentication step for a website or app cannot rely on a cognitive-function test — solving a puzzle, transcribing a distorted image, recognising objects in a grid — unless an alternative authentication method is provided, an assistive mechanism is available, or an object-recognition exception applies. Memorising a password counts as a cognitive-function test, which is why password managers are explicitly accommodated.
Most image-based CAPTCHAs fail this on their face. So do “click the squares with traffic lights” challenges, distorted-text transcription tests, and any flow that pastes a one-time code into a field but disables the paste interaction. The pattern is concentrated in login, password-reset, and account-creation flows — exactly the high-stakes points where being locked out has the biggest cost.
Authentication flows are also the area where the criterion’s bite is sharpest, because the failure does not degrade the experience — it ends it.
Replace cognitive-function CAPTCHAs with a non-cognitive alternative — device-based attestation, magic links, passkeys, or invisible risk-scoring. Permit password-manager autofill. Ensure copy-paste works in one-time-code fields. Where a CAPTCHA must remain, provide an audio alternative that itself does not require transcription of distorted speech.
The AA tier is the live wire
Five of the nine new criteria sit at level AA: 2.4.11 Focus Not Obscured (Min.), 2.5.7 Dragging Movements, 2.5.8 Target Size (Min.), 3.3.8 Accessible Authentication (Min.), and (paired with 3.3.8 at AAA, 3.3.9). These are the criteria a procurement clause cannot avoid, and the rows where the difference between WCAG 2.1 AA conformance and WCAG 2.2 AA conformance is most measurable. The two A-level additions (3.2.6 Consistent Help, 3.3.7 Redundant Entry) are easier wins. The two AAA additions (2.4.12 and 3.3.9) are aspirational tightenings of the AA pairs.
Focus Not Obscured (Minimum) — 2.4.11 AA
When a user-interface component receives keyboard focus, the focused element must not be entirely hidden by author-created content. Partial occlusion is permitted at this level (a sticky header overlapping the top half of a focused field is allowed); total occlusion is not.
The most common collision is a sticky header — sometimes a cookie banner or floating chat widget — that overlaps the focused form field when a keyboard user tabs into it. Production sites that layered a sticky header onto an existing form during the 2020–22 redesign era routinely missed the focus-and-scroll behaviour because the original form was authored before sticky elements existed.
Set scroll-margin-top (or scroll-padding-top on the scroll container) equal to the height of any sticky overlay. Test that tabbing through a long form scrolls the focused element fully into view below any header. Pair this with focused-visible styles so the user can see where focus actually landed.
The motor-accessibility brief in WCAG 2.2 reduced to two criteria, both AA. One catches list-reordering UIs that demand a sustained drag; the other (E·02 above) catches dense icon toolbars. They share a common cause — design systems that assume a precise pointer.
Dragging Movements — 2.5.7 AA
Functionality that uses a dragging movement must also be operable through a single-pointer action — a tap, a click, or an equivalent that does not require sustained pointer motion. Drag-and-drop interactions are not banned; they simply cannot be the only available path to the function.
List-reordering and kanban-style UIs frequently ship with drag-only reordering. The same applies to slider controls implemented as draggable thumbs without a corresponding spinbutton or text input, and to image-cropper UIs that require a drag to set bounds. The criterion catches these every time.
For every drag interaction, ship an equivalent tap/click alternative — “move up” and “move down” buttons next to draggable list items, a numeric input next to a slider, a click-to-set-bounds mode in the cropper. Where the alternative is hidden in a contextual menu, ensure it is reachable via the keyboard.
The remaining four criteria fall into two pairs: the two A-level editorial additions (Redundant Entry and Consistent Help) and the two AAA tightenings (Focus Not Obscured Enhanced, Accessible Authentication Enhanced). Together they round out the 2.2 brief on cognitive-load accessibility.
Redundant Entry — 3.3.7 A
Within the same authenticated process, do not require the user to enter the same information twice — unless re-entry is essential, the previous entry is no longer valid, or the information involves security (a password retype during account creation is the canonical exception). Auto-populating or selecting from previously entered values both satisfy the criterion.
Multi-step checkout flows, multi-page application forms, and visa/permit applications routinely ask for the same address, name, or contact information in two separate steps because the steps were built by different teams and never reconciled. The user’s previously entered values are not held in a session shared across the steps.
Persist user-entered values across steps of a single process; pre-fill matching fields in subsequent steps; or expose a one-click “use the same address” control. The pattern usually surfaces during process mapping rather than during front-end audit, so a cross-team flow review is the practical remediation step.
Consistent Help — 3.2.6 A
If a help mechanism is provided — a contact link, a help link, a chat widget, a support phone number, a self-help link — it must appear in the same relative location across pages where it is provided. The criterion does not require help to be present; only that, where it is present, its placement is consistent.
The criterion is straightforward in principle and catches a narrow set of sites that have a “Contact us” link in the header on some pages, in a footer on others, and inside a floating chat widget on a third set of pages — frequently the result of multiple site sections owned by different teams with separate templates.
Audit help-mechanism placement across templates; settle on a single canonical location (header, persistent footer, or floating widget) and reconcile any outliers. The fix is rarely technical; it is a content-and-template governance step.
Focus Not Obscured (Enhanced) — 2.4.12 AAA
The AAA cousin of 2.4.11: when a user-interface component receives keyboard focus, the focused element must not be obscured by author-created content at all. Partial occlusion is forbidden at this level — a sticky header that covers any part of the focused field fails.
The same sticky-overlay collisions that drive 2.4.11 failures persist at 2.4.12. Sites that adopted scroll-margin-top to satisfy the minimum criterion still tend to leave a few CSS pixels of overlap on edge-case viewport heights. At AAA, that overlap is the failure.
Tune scroll-margin-top to comfortably exceed the height of every author-created overlay, including dynamic ones (cookie banners that appear on first visit, chat widgets that expand on hover). Add explicit regression tests for tab-into-form behaviour at common viewport sizes.
Accessible Authentication (Enhanced) — 3.3.9 AAA
The AAA cousin of 3.3.8: authentication cannot rely on a cognitive-function test, period. The exceptions for object recognition and personal content that apply at AA do not apply here. Memory tests, transcription tests, and image-recognition challenges all fail at this level.
Even sites that replaced traditional CAPTCHAs with object-recognition challenges (the AA exception) fail 3.3.9. The criterion is the working group’s signal about where authentication should go: away from cognitive challenges entirely, and toward device attestation or biometric verification.
Adopt passkeys (WebAuthn) as the primary authentication mechanism; treat password-plus-passkey as a transition state rather than a destination. Where image recognition has been retained for risk-scoring, run it server-side from behavioural signals rather than as a user-facing challenge.
The 2.2 additions are not where most of accessibility’s hardest problems live. They are where the most-frequent, most-measurable production failures live — which is exactly what they were chosen for.
What the nine have in common
Read as a catalogue, the nine new criteria share a common editorial pose. They are not new failure modes the working group invented; they are the failure modes that have shown up most consistently in the years since WCAG 2.1 published. The working group treated them as gaps to be closed: dense toolbars (2.5.8), sticky overlays (2.4.11 / 2.4.12), CAPTCHA-style authentication (3.3.8 / 3.3.9), default focus rings (2.4.13), repeat-the-address checkout patterns (3.3.7), drag-only list reorderings (2.5.7), and the help-link placement inconsistency that frustrated cognitive-disability advocates (3.2.6).
The legal-reference picture lags because the version-pinning mechanism is slow. EN 301 549 V4 — the single biggest pending event — would cascade WCAG 2.2 across the EU Web Accessibility Directive, the European Accessibility Act’s conformance reference, and every national web-accessibility law that points at the harmonised European standard. A 2026 publication is the working assumption inside ETSI JTC HF; a 2027 slippage is the more cautious one. The UK’s PSBAR amendment, following the closed February 2026 consultation, is expected before year-end. The US Section 508 update remains the slowest-moving large piece — even the 2.1 update is still pending in 2026; a 2.2 update is realistically a late-2020s instrument.
For 2026 planning purposes, WCAG 2.2 is the standard that will be cited in law and procurement for the rest of the decade. WCAG 3 (Silver) remains in Working Draft and is not on a near-term Recommendation track; the most recent public draft, in 2025, made clear that Recommendation-level publication is not expected before 2028. Version-pinning practice in regulations means 2.2 will remain referenced for years after 3.0 publishes. The pragmatic procurement clause — require WCAG 2.2 at level AA as the conformance target, require a VPAT 2.5 ACR dated within the past 12 months, require the vendor to identify any of the nine new criteria where conformance is not yet met — works under any jurisdiction whose underlying law still pins at 2.0 or 2.1, because nothing in those laws prevents a buyer from contracting for more.
Your 2.2 readiness checklist
Procurement language (do this now)
- Require WCAG 2.2 at level AA as the conformance target in new contracts
- Require a VPAT 2.5 ACR dated within the past 12 months from every vendor
- Require vendors to identify any of the nine new criteria where conformance is not yet met, plus a documented remediation roadmap
- Treat “WCAG 2.1 AA at minimum, with reporting against 2.2 where the vendor’s response permits” as the floor — not the ceiling
Engineering regression tests (catch the AA five before audit does)
- Tab-into-form behaviour at common viewport sizes, with every overlay open (2.4.11)
- Hit-target dimensions in icon toolbars, dashboards, and data-table headers (2.5.8)
- Single-pointer alternatives for every drag interaction — list reordering, sliders, croppers (2.5.7)
- Login, sign-up and password-reset flows free of cognitive-function tests; paste enabled in OTP fields (3.3.8)
- Cross-step persistence: no field asked twice in the same authenticated process (3.3.7)
Editorial / IA review (the two A-level additions)
- Single canonical placement for help mechanisms across templates (3.2.6)
- Cross-team flow review for any multi-step process owned by more than one team (3.3.7)
2026 outlook items to track
- EN 301 549 V4 publication — triggers WCAG 2.2 across EU web-accessibility law
- UK PSBAR amendment — first major Anglophone jurisdiction to pin at 2.2
- US Section 508 ICT update — 2.1 still pending; 2.2 is a late-2020s instrument
- VPAT 2.5 cadence — any ACR dated 2025-or-later should report against 2.2
The WCAG 2.2 transition is structurally two transitions running on different clocks. The law transition is slow, dependent on a small number of standards bodies — ETSI JTC HF above all — and will continue through 2026–27. The practitioner transition is largely already done: auditors score against 2.2, design systems align with it, vendors file VPAT 2.5 ACRs reporting against it, and the nine new criteria are now the established vocabulary of accessibility audits. The interesting analytical question is no longer whether WCAG 2.2 is the working standard — it is — but whether the regulatory references will catch up before WCAG 3 starts pulling attention forward.
MethodologyFailure-rate descriptors aggregated from independent auditor reports issued through Q1 2026 across SaaS, e-commerce, and public-sector audit cycles. Qualitative descriptors used where firms publish ordinal rather than precise rates.
ScopeThe nine new WCAG 2.2 success criteria only. SC 4.1.1 Parsing, retired in WCAG 2.2, is out of scope. WCAG 2.1 carry-forward criteria are out of scope.
SourcesW3C, Web Content Accessibility Guidelines (WCAG) 2.2, Recommendation 5 October 2023 — w3.org/TR/WCAG22; W3C AG WG, What’s New in WCAG 2.2 — w3.org/WAI/standards-guidelines/wcag/new-in-22; ETSI, EN 301 549 V3.2.1 (2021) and JTC HF V4 drafts; US Access Board ICT Standards (Section 508 Refresh, 2017); US DOJ, Final Rule — Title II web accessibility, 28 C.F.R. Part 35 (April 2024); UK Cabinet Office, PSBAR 2018 and 2025–26 consultation; ITI, VPAT 2.5 / ACR, January 2025 — itic.org/policy/accessibility/vpat; EU Directives 2016/2102 and 2019/882; W3C, WCAG 3.0 Working Draft — w3.org/TR/wcag-3.0. Read more on national accessibility regulations, the practitioner toolkit, the full WCAG 2.2 success-criteria reference, the compliance, conformance and accessibility explainer, the monitoring buyer’s guide, a free WCAG 2.2 baseline scan, and the wider 2026 reporting record.