WCAG 2.2 Level AA Requirements: The Complete List
“WCAG 2.2 AA conformance” means satisfying all 55 Level A and Level AA success criteria — 31 at Level A plus 24 at Level AA — on every page you claim conformance for. This page lists every one of them, grouped by the four POUR principles, with each requirement linking to a full reference page with examples and testing steps.
55
Criteria required for AA
31
Level A criteria
24
Level AA criteria
6
New in WCAG 2.2
What “WCAG 2.2 AA conformance” means
WCAG organizes its requirements into three cumulative conformance levels. Level A covers the most basic barriers — things like text alternatives for images and keyboard operability. Level AA adds the requirements that make content usable in practice: sufficient color contrast, text resizing, visible focus, consistent navigation, and error recovery. Level AAA is the enhanced tier, which even the W3C does not recommend requiring for entire sites.
The levels nest: a Level AA conformance claim requires passing every Level A criterion and every Level AA criterion. In WCAG 2.2 that is 31 + 24 = 55 success criteria. The 6 criteria marked New in 2.2 below were added in the October 2023 release — if you previously met WCAG 2.1 AA, those are your entire gap (see our WCAG 2.1 vs 2.2 comparison for the details).
Conformance is assessed per page: a single failing criterion anywhere on a page means that page does not conform. The requirements below are grouped by WCAG's four founding principles — Perceivable, Operable, Understandable, Robust (POUR). Every criterion links to its entry in our WCAG 2.2 reference hub.
The complete WCAG 2.2 AA requirements checklist
1. Perceivable (20 criteria)
Information and user interface components must be presentable to users in ways they can perceive — text alternatives for images, captions for media, adaptable structure, and sufficient contrast.
Guideline 1.1 Text Alternatives
- 1.1.1 Non-text ContentLevel A
All non-text content has appropriate text alternatives that serve the equivalent purpose.
Guideline 1.2 Time-based Media
Provide alternatives for prerecorded audio-only and video-only content.
- 1.2.2 Captions (Prerecorded)Level A
Captions are provided for all prerecorded audio content in synchronized media.
Audio description or full text alternative is provided for prerecorded video content.
- 1.2.4 Captions (Live)Level AA
Captions are provided for all live audio content in synchronized media.
Audio description is provided for all prerecorded video content.
Guideline 1.3 Adaptable
- 1.3.1 Info and RelationshipsLevel A
Information, structure, and relationships can be programmatically determined.
- 1.3.2 Meaningful SequenceLevel A
Content can be presented in a meaningful sequence without losing meaning.
Instructions don't rely solely on sensory characteristics of components.
- 1.3.4 OrientationLevel AA
Content does not restrict its view to a single display orientation.
- 1.3.5 Identify Input PurposeLevel AA
The purpose of input fields can be programmatically determined.
Guideline 1.4 Distinguishable
- 1.4.1 Use of ColorLevel A
Color is not used as the only visual means of conveying information.
- 1.4.2 Audio ControlLevel A
Audio that plays automatically can be paused, stopped, or controlled.
- 1.4.3 Contrast (Minimum)Level AA
Text has a contrast ratio of at least 4.5:1 (3:1 for large text).
- 1.4.4 Resize TextLevel AA
Text can be resized up to 200% without loss of content or functionality.
- 1.4.5 Images of TextLevel AA
Text is used instead of images of text, except for customizable or essential images.
- 1.4.10 ReflowLevel AA
Content can be presented without horizontal scrolling at 320 CSS pixels width.
- 1.4.11 Non-text ContrastLevel AA
UI components and graphical objects have sufficient contrast (3:1 minimum).
- 1.4.12 Text SpacingLevel AA
No loss of content when text spacing is adjusted within certain parameters.
- 1.4.13 Content on Hover or FocusLevel AA
Additional content triggered by hover or focus can be dismissed and doesn't interfere.
2. Operable (20 criteria)
User interface components and navigation must be operable — everything works with a keyboard, users get enough time, nothing triggers seizures, and targets are easy to find and hit.
Guideline 2.1 Keyboard Accessible
- 2.1.1 KeyboardLevel A
All functionality is available from a keyboard interface.
- 2.1.2 No Keyboard TrapLevel A
Focus can be moved away from any component using standard keyboard methods.
Single character key shortcuts can be turned off or remapped.
Guideline 2.2 Enough Time
- 2.2.1 Timing AdjustableLevel A
Users can turn off, adjust, or extend time limits.
- 2.2.2 Pause, Stop, HideLevel A
Moving, blinking, or auto-updating content can be paused, stopped, or hidden.
Guideline 2.3 Seizures and Physical Reactions
Content does not contain anything that flashes more than three times per second.
Guideline 2.4 Navigable
- 2.4.1 Bypass BlocksLevel A
A mechanism is available to bypass blocks of content that are repeated.
- 2.4.2 Page TitledLevel A
Web pages have titles that describe topic or purpose.
- 2.4.3 Focus OrderLevel A
Focusable components receive focus in an order that preserves meaning.
The purpose of each link can be determined from link text or context.
- 2.4.5 Multiple WaysLevel AA
More than one way is available to locate a page within a set of pages.
- 2.4.6 Headings and LabelsLevel AA
Headings and labels describe topic or purpose.
- 2.4.7 Focus VisibleLevel AA
Any keyboard operable interface has a visible focus indicator.
When a component receives keyboard focus, it is not entirely hidden.
Guideline 2.5 Input Modalities
- 2.5.1 Pointer GesturesLevel A
Functionality that uses multipoint or path-based gestures has alternatives.
- 2.5.2 Pointer CancellationLevel A
Functions triggered by single pointer can be cancelled or undone.
- 2.5.3 Label in NameLevel A
The accessible name contains the visible label text.
- 2.5.4 Motion ActuationLevel A
Functionality triggered by device motion can be disabled and has alternatives.
Functionality that uses dragging has a single pointer alternative.
Target size is at least 24 by 24 CSS pixels except in specific cases.
3. Understandable (13 criteria)
Information and the operation of the user interface must be understandable — readable language, predictable behavior, and help avoiding and correcting mistakes.
Guideline 3.1 Readable
- 3.1.1 Language of PageLevel A
The default human language of each page can be programmatically determined.
- 3.1.2 Language of PartsLevel AA
The human language of each passage can be programmatically determined.
Guideline 3.2 Predictable
- 3.2.1 On FocusLevel A
When a component receives focus, it does not initiate a change of context.
- 3.2.2 On InputLevel A
Changing settings of a component does not automatically cause context changes.
- 3.2.3 Consistent NavigationLevel AA
Navigational mechanisms are repeated in the same relative order.
- 3.2.4 Consistent IdentificationLevel AA
Components with the same functionality are identified consistently.
Help mechanisms appear in the same relative order across pages.
Guideline 3.3 Input Assistance
- 3.3.1 Error IdentificationLevel A
Input errors are automatically detected and described to the user.
- 3.3.2 Labels or InstructionsLevel A
Labels or instructions are provided when content requires user input.
- 3.3.3 Error SuggestionLevel AA
Input error suggestions are provided when errors are detected.
Important transactions can be reversed, checked, or confirmed.
Information previously entered is either auto-populated or selectable.
Authentication methods don't rely solely on cognitive function tests.
4. Robust (2 criteria)
Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies like screen readers.
Guideline 4.1 Compatible
- 4.1.2 Name, Role, ValueLevel A
Name, role, and value can be programmatically determined for UI components.
- 4.1.3 Status MessagesLevel AA
Status messages can be programmatically determined through role or properties.
Why Level AA is the legal standard
Regulators around the world have converged on Level AA as the enforceable benchmark, because Level A alone leaves obvious barriers (it does not even require minimum color contrast) while Level AAA is not achievable for all content:
- ADA Title II (U.S. public sector): the Department of Justice rule requires state and local government web content to meet WCAG 2.1 AA — see our Title II deadline analysis.
- ADA Title III (U.S. private sector): no formal regulation names a standard, but WCAG AA is the benchmark in virtually every settlement and consent decree, and thousands of lawsuits are filed each year — tracked in our accessibility lawsuit database.
- Section 508 (U.S. federal): requires WCAG 2.0 AA for federal agencies and their procurement.
- European Accessibility Act / EN 301 549 (EU): the harmonized standard maps to WCAG 2.1 AA and applies to private-sector products and services sold in the EU.
All of these cite WCAG 2.0 or 2.1 today, and WCAG 2.2 AA conformance satisfies them all — WCAG versions are backwards compatible, so meeting the 2.2 AA list above automatically meets the older references. Meeting WCAG 2.2 AA is therefore the single target that covers current U.S. and EU obligations and the ones coming next. (The next generation, WCAG 3.0, is still years away and will not change this picture soon.)
How to verify WCAG 2.2 AA conformance
No single method covers all 55 criteria. A credible verification process layers three approaches:
- Automated scanning. Tools catch the machine-detectable failures — missing alt text, low contrast, unlabeled fields, empty links — quickly and repeatably, but they can only detect a minority of WCAG issues. Start with our URL accessibility auditor and the rest of our free tools, including the contrast checker for 1.4.3 and 1.4.11.
- Manual, criterion-by-criterion testing. Keyboard-only navigation, screen reader passes, 200% zoom and reflow checks, and focus-order review cover what automation cannot. Work through the interactive WCAG 2.2 checklist so every criterion gets an explicit pass/fail, and use our keyboard accessibility and screen reader testing guides for the manual techniques.
- Professional audit. When conformance carries legal or contractual weight — a VPAT/ACR, procurement requirement, or litigation exposure — have experts test representative pages against all 55 criteria and document the evidence. Our accessibility audit service delivers exactly that, with prioritized remediation guidance.
Then keep it conformant: re-scan on every release, include accessibility checks in code review and QA, and re-audit after major redesigns. Conformance is a property of the current state of a page, not a one-time certificate.
Start checking your site against all 55 criteria
Scan for the machine-detectable failures first, then track your manual review in the interactive checklist.
Frequently asked questions
What does WCAG 2.2 Level AA conformance actually mean?
WCAG 2.2 Level AA conformance means your content satisfies every Level A success criterion (31 criteria) plus every Level AA success criterion (24 criteria) — 55 requirements in total. The levels are cumulative: you cannot claim AA while failing any Level A criterion. Level AAA criteria (a further 31) are not required for an AA conformance claim. Conformance applies per page, and every page in the claimed scope must pass all 55 criteria.
How many success criteria are in WCAG 2.2 Level AA?
55. WCAG 2.2 contains 86 success criteria in total: 31 at Level A, 24 at Level AA, and 31 at Level AAA. A Level AA conformance claim covers the Level A and Level AA criteria — 31 + 24 = 55. Six of those 55 are new in WCAG 2.2: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, and 3.3.8 Accessible Authentication (Minimum).
Why is Level AA the standard instead of A or AAA?
Level A alone leaves major barriers in place — it does not even require sufficient color contrast. Level AAA is not achievable for all content (for example, some media simply cannot meet every AAA requirement), and the W3C itself says AAA should not be required as a general policy for entire sites. Level AA is the balance point: it removes the most significant barriers while remaining achievable for real-world products, which is why regulators worldwide — the DOJ under ADA Title II, the EU via EN 301 549, and courts in ADA Title III settlements — consistently set AA as the requirement.
Do U.S. laws require WCAG 2.2 AA or WCAG 2.1 AA?
Current U.S. regulations cite WCAG 2.1 AA (the DOJ ADA Title II rule) or WCAG 2.0 AA (Section 508); the EU's EN 301 549 also references 2.1 AA. No major law names 2.2 yet. But WCAG 2.2 is backwards compatible — conforming to 2.2 AA automatically satisfies 2.1 AA — so targeting 2.2 AA meets every current legal reference while future-proofing you for when standards bodies update their citations. There is no scenario where meeting 2.2 AA leaves you short of a 2.1 AA obligation.
How do I verify WCAG 2.2 AA conformance?
Combine three methods. First, automated scanning catches machine-detectable failures like missing alt text, contrast issues, and unlabeled form fields — typically 30-40% of real issues. Second, manual testing covers what automation cannot: keyboard-only navigation, screen reader output, focus order, and reflow. Third, work criterion by criterion through a structured checklist so nothing is skipped. For high-stakes conformance claims (legal exposure, procurement, VPAT/ACR documentation), commission a professional audit that tests representative pages against all 55 criteria and documents the evidence.
Does every page of my site need to meet all 55 criteria?
Yes — WCAG conformance is defined per page, and a conformance claim covers full pages, not fragments. If one criterion fails anywhere on a page, that page does not conform. In practice, teams audit a representative sample: key templates (home, navigation, search, forms, checkout), highest-traffic pages, and each distinct component pattern. Because most sites are template-driven, fixing a template or design-system component usually fixes every page that uses it.
How long does it take to reach WCAG 2.2 AA?
It depends on the starting point. A site built with semantic HTML and an accessible design system may need only weeks of focused fixes. A legacy site with custom widgets, PDF libraries, and third-party embeds can take several months of prioritized remediation. The efficient sequence is: run an automated scan and fix everything it flags, then remediate keyboard and screen reader blockers found in manual testing, then close the remaining criterion-by-criterion gaps — highest-traffic templates first. Document progress as you go; demonstrated, ongoing remediation also reduces legal risk before you reach full conformance.