Accessibility standard

WCAG 2.2 AA

The W3C Web Content Accessibility Guidelines 2.2, Level AA, define 86 success criteria across four principles — Perceivable, Operable, Understandable, Robust — and form the technical baseline referenced by the EAA, Section 508, RGAA, and ADA Title III.

ActiveW3C / WAI2023

What is WCAG 2.2 AA?

WCAG 2.2 AA, published by the World Wide Web Consortium on 5 October 2023, is the current recommended version of the Web Content Accessibility Guidelines. It supersedes WCAG 2.1 AA (2018) and introduces 9 new success criteria at Level A and AA, while retiring one criterion (4.1.1 Parsing, removed as obsolete). The guideline applies to web content, web applications, and digital documents intended for public use. It is organized around four core principles — Perceivable, Operable, Understandable, and Robust (POUR) — and 13 guidelines containing 86 testable success criteria in total (Level A: 30, Level AA: 20 new in 2.2, Level AAA: 28).

WCAG 2.2 AA compliance is required or strongly recommended for: (1) any organization subject to the European Accessibility Act (private sector, from 28 June 2025); (2) US federal agencies and their contractors under Section 508 (by reference via the 2017 ICT Refresh); (3) French public bodies and many private organizations under RGAA 4.1.2; (4) any US business subject to ADA Title III litigation risk — 3,117 federal ADA website lawsuits were filed in 2025, a 27% year-over-year increase. Private companies are not legally required to meet WCAG in most jurisdictions, but courts routinely use it as the accessibility benchmark in settlement negotiations.

Three major bodies of law explicitly reference WCAG 2.2 AA or its predecessors as the technical standard. The EAA Directive 2019/882 delegates technical details to EN 301 549, which from v4.1.1 (October 2026) will cite WCAG 2.2. The US Department of Justice finalized its ADA Title II web rule in April 2024, mandating WCAG 2.1 AA — courts typically apply equivalent reasoning to Title III. The W3C note states that WCAG 2.2 AA is backward-compatible with WCAG 2.1 AA: content that passes 2.2 automatically satisfies 2.1. Organizations that already comply with WCAG 2.1 AA need only address the 9 new criteria to reach 2.2 compliance.

Key criteria

The 10 requirements most frequently flagged in automated audits by scan-access.com.

2.4.11
Focus Not Obscured (Minimum)
When a UI component receives keyboard focus, it must not be entirely hidden by other content (e.g., a sticky header). At least part of the focused component must remain visible.
Official spec →WCAG 2.4.11
2.4.12
Focus Not Obscured (Enhanced)
The focused component must be fully visible with no part covered by other content. This is a Level AAA criterion; Level AA requires 2.4.11 (partial visibility).
Official spec →WCAG 2.4.12
2.5.7
Dragging Movements
All functionality that uses dragging (e.g., sliders, kanban boards) must be achievable with a single pointer without dragging — typically a click or tap alternative.
Official spec →WCAG 2.5.7
2.5.8
Target Size (Minimum)
Interactive targets (buttons, links) must have a minimum size of 24×24 CSS pixels, or adequate spacing must exist around smaller targets to prevent accidental activation.
Official spec →WCAG 2.5.8
3.2.6
Consistent Help
If a mechanism for seeking help is provided (phone number, chat, FAQ link), it must appear in a consistent location across all pages of the same set.
Official spec →WCAG 3.2.6
3.3.7
Redundant Entry
Information previously entered by users and required again in the same process must be auto-populated or made available for selection, unless re-entry is essential (e.g., password confirmation).
Official spec →WCAG 3.3.7
3.3.8
Accessible Authentication (Minimum)
Authentication steps must not require solving a cognitive function test (e.g., a CAPTCHA puzzle) unless an accessible alternative is provided, such as email magic link or object recognition.
Official spec →WCAG 3.3.8
1.1.1
Non-text Content
All non-text content (images, icons, charts) must have a text alternative. Decorative images use empty alt=''. This core criterion is referenced by every downstream standard.
Official spec →WCAG 1.1.1
1.4.3
Contrast (Minimum)
Text must have a contrast ratio of at least 4.5:1 (3:1 for large text). One of the highest-frequency violations found by automated tools on e-commerce sites.
Official spec →WCAG 1.4.3
4.1.2
Name, Role, Value
All UI components (form inputs, buttons, custom widgets) must expose their name, role, and current state/value to assistive technologies via valid ARIA or semantic HTML.
Official spec →WCAG 4.1.2

scan-access.com coverage

scan-access.com detects ~35% of WCAG 2.2 AA violations automatically

scan-access.com uses axe-core 4.11 rules mapped against all 86 WCAG 2.2 AA success criteria. Fully automated checks cover contrast ratios (1.4.3), missing alt attributes (1.1.1), form label associations (1.3.1), ARIA usage (4.1.2), focus order (2.4.3), and 30+ more rules. The remaining 65% of WCAG 2.2 AA criteria require human judgment — target size context (2.5.8), dragging alternatives (2.5.7), cognitive flow testing (3.3.8) — and are flagged as 'manual review required' in the report. Every scan produces a timestamped, hash-signed legal-defense PDF that documents automated findings and manual review checklists, providing a defensible compliance record.

35% automated

Run a free WCAG 2.2 AA scan

Free scan against WCAG 2.2 AA. No account required.

Frequently asked questions

What is WCAG 2.2 AA compliance?

WCAG 2.2 AA compliance means your website or application meets all 86 Level A and Level AA success criteria defined in the W3C Web Content Accessibility Guidelines version 2.2 (published October 2023). Level AA is the widely accepted legal benchmark — it excludes the stricter Level AAA criteria that are not feasible for all content types.

What are the 9 new criteria in WCAG 2.2?

WCAG 2.2 added 9 new success criteria compared to WCAG 2.1: 2.4.11 Focus Not Obscured (Minimum), 2.4.12 Focus Not Obscured (Enhanced, AAA), 2.4.13 Focus Appearance (AAA), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, 3.3.8 Accessible Authentication (Minimum), and 3.3.9 Accessible Authentication (Enhanced, AAA). Criterion 4.1.1 Parsing was removed. At Level AA, the practical additions are 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7, and 3.3.8.

Is WCAG 2.2 mandatory?

WCAG 2.2 is not a law itself — it is a technical standard. However, multiple laws mandate conformance with WCAG or equivalent: the European Accessibility Act (via EN 301 549, expected to reference WCAG 2.2 in v4.1.1 from October 2026), France's RGAA (WCAG 2.1 now, WCAG 2.2 expected in RGAA 5 late 2026), and the US DOJ ADA Title II rule (WCAG 2.1 AA, April 2024). Organizations that meet WCAG 2.2 AA automatically satisfy WCAG 2.1 AA requirements.

What is the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 adds 9 success criteria to 2.1 (6 at AA level) and removes the obsolete 4.1.1 Parsing criterion. The new criteria focus on: keyboard focus visibility (2.4.11 Focus Not Obscured), pointer interaction (2.5.7 Dragging, 2.5.8 Target Size), user experience consistency (3.2.6 Consistent Help, 3.3.7 Redundant Entry), and cognitive accessibility in authentication (3.3.8 Accessible Authentication). Content passing WCAG 2.2 AA is backward-compatible with 2.1 AA.

How long does WCAG 2.2 compliance take?

The timeline depends heavily on the current state of the site. For a new project built accessibility-first, WCAG 2.2 compliance can be achieved from the start at near-zero additional cost. For an existing e-commerce site, a typical audit-and-remediation cycle takes 4–12 weeks: 1–2 weeks for automated scanning and manual audit (130+ hours for a large site), 2–6 weeks for developer remediation, and 1–2 weeks for retest. scan-access.com's automated scan gives you the critical-severity issues in under 60 seconds — a practical first step.

Does WCAG 2.2 apply to mobile apps?

WCAG 2.2 is primarily a web standard (HTML/CSS/JS). Mobile native apps are covered by separate standards: for EU, EN 301 549 Chapter 11 (non-web software) applies; for iOS/Android, Apple and Google publish platform-specific accessibility APIs. WCAG 2.2 principles are widely used as a reference for mobile audits, but the technical implementation differs from web. The upcoming RGAA 5 explicitly extends scope to mobile applications.