WCAG 2.2 AA Checklist: All Success Criteria Explained

1. WCAG 2.2 Overview: What Changed from 2.1

WCAG 2.2 was published by the W3C on October 5, 2023, superseding WCAG 2.1 (June 2018). It is backward compatible — any website meeting WCAG 2.2 AA automatically meets WCAG 2.1 AA and WCAG 2.0 AA.

The update focuses on three main areas where WCAG 2.1 had gaps:

• Mobile and touch usability — target sizes, dragging interactions
• Cognitive accessibility — accessible authentication, redundant entry, consistent help
• Improved focus visibility — more specific requirements for keyboard focus indicators

One criterion was removed: Parsing (4.1.1), which required valid HTML to ensure screen readers could parse markup correctly. Modern browsers handle malformed HTML gracefully, making this criterion redundant.

2. New Success Criteria in WCAG 2.2

WCAG 2.2 introduces 9 new success criteria. If you currently meet WCAG 2.1 AA, these are the additional criteria you need to address to reach WCAG 2.2 AA:

3. Perceivable — Checklist

Information and user interface components must be presentable to users in ways they can perceive.

1.1 Text Alternatives

• 1.1.1
  Non-text Content (A) — All images, icons, and non-text UI elements have descriptive alt text. Decorative images use alt="".

1.2 Time-based Media

• 1.2.1
  Audio-only and Video-only (A) — Prerecorded audio has a text transcript. Prerecorded silent video has a text description.
• 1.2.2
  Captions (Prerecorded) (A) — Synchronized captions for all prerecorded audio in video content.
• 1.2.4
  Captions (Live) (AA) — Captions for all live audio content in synchronized media.
• 1.2.5
  Audio Description (Prerecorded) (AA) — Audio description for all prerecorded video content.

1.3 Adaptable

• 1.3.1
  Info and Relationships (A) — Structure conveyed through presentation (headings, lists, tables) is also communicated programmatically via HTML semantics.
• 1.3.2
  Meaningful Sequence (A) — Reading and navigation order is logical when CSS is removed or linearized.
• 1.3.3
  Sensory Characteristics (A) — Instructions don't rely solely on shape, color, size, visual location, or sound (e.g., "click the round green button").
• 1.3.4
  Orientation (AA) — Content doesn't restrict its view to a single display orientation (portrait or landscape) unless essential.
• 1.3.5
  Identify Input Purpose (AA) — Input fields for personal data (name, email, address) use autocomplete attributes so browsers can pre-fill them.

1.4 Distinguishable

• 1.4.1
  Use of Color (A) — Color is not the only visual means of conveying information (e.g., error states use icon + text, not just red color).
• 1.4.2
  Audio Control (A) — Audio that plays automatically for more than 3 seconds can be paused, stopped, or volume-controlled independently.
• 1.4.3
  Contrast Minimum (AA) — Most Common Failure — Normal text (under 18pt/14pt bold) must have a contrast ratio of at least 4.5:1. Large text must have at least 3:1.
• 1.4.4
  Resize Text (AA) — Text can be resized up to 200% without loss of content or functionality (no horizontal scrolling or clipped text).
• 1.4.5
  Images of Text (AA) — Text is used instead of images of text except for logos or where a specific visual presentation is essential.
• 1.4.10
  Reflow (AA) — Content can be presented in a single column at 320 CSS pixels wide without horizontal scrolling (responsive design).
• 1.4.11
  Non-text Contrast (AA) — UI components (buttons, inputs) and informational graphics have a 3:1 contrast ratio against adjacent colors.
• 1.4.12
  Text Spacing (AA) — No content loss when line height, letter spacing, word spacing, and paragraph spacing are overridden by user stylesheets.
• 1.4.13
  Content on Hover or Focus (AA) — Tooltip/hover content must be dismissible, hoverable (mouse can move over it), and persistent (doesn't disappear on its own).

4. Operable — Checklist

User interface components and navigation must be operable.

2.1 Keyboard Accessible

• 2.1.1
  Keyboard (A) — Critical — All functionality is accessible via keyboard alone without requiring specific timing. No keyboard traps.
• 2.1.2
  No Keyboard Trap (A) — Keyboard focus can always be moved away from a component using standard keys (Tab, Esc, Arrow keys).
• 2.1.4
  Character Key Shortcuts (A) — Single-character keyboard shortcuts can be remapped, disabled, or active only on focus.

2.4 Navigable

• 2.4.1
  Bypass Blocks (A) — Skip navigation links allow keyboard users to jump past repeated blocks (header/nav) to main content.
• 2.4.2
  Page Titled (A) — Most Common Failure — Every page has a descriptive, unique <title> tag that describes its purpose.
• 2.4.3
  Focus Order (A) — Focus order preserves meaning and operability (logical top-to-bottom, left-to-right sequence).
• 2.4.6
  Headings and Labels (AA) — Headings and labels are descriptive (not vague like "Click Here" or "Read More").
• 2.4.7
  Focus Visible (AA) — Critical — Keyboard focus indicator is visually apparent (not hidden by outline: none without replacement).
• 2.4.11 ✨
  Focus Not Obscured — Minimum (AA) — NEW in 2.2 — When a keyboard-focused element receives focus, it must not be entirely hidden behind sticky headers, cookie banners, chat widgets, or other overlaid content.
• 2.4.13 ✨
  Focus Appearance (AA) — NEW in 2.2 — Keyboard focus indicator must have a contrasting area at least as large as the component perimeter with a 3:1 color contrast ratio between focused and unfocused states.

2.5 Input Modalities

• 2.5.1
  Pointer Gestures (A) — All multi-point (pinch, swipe) or path-based gestures have a single-pointer alternative.
• 2.5.3
  Label in Name (A) — For UI components with visible text labels, the accessible name contains the visible label text.
• 2.5.7 ✨
  Dragging Movements (AA) — NEW in 2.2 — All drag-and-drop functionality has a single-pointer alternative (e.g., a button to move items, click-to-select then click-to-place).
• 2.5.8 ✨
  Target Size Minimum (AA) — NEW in 2.2 — Interactive targets are at least 24×24 CSS pixels, OR the spacing between targets ensures a 24×24 hit area, OR the target is inline text, OR the size is determined by the user agent.

5. Understandable — Checklist

Information and the operation of the user interface must be understandable.

3.1 Readable

• 3.1.1
  Language of Page (A) — Most Common Failure — The <html lang="en"> attribute identifies the default human language of the page.
• 3.1.2
  Language of Parts (AA) — Passages in a different language are marked with lang attributes on the containing element.

3.2 Predictable

• 3.2.1
  On Focus (A) — Keyboard focus doesn't trigger context changes (no form submissions or page redirects when tabbing to an element).
• 3.2.2
  On Input (A) — Changing a setting doesn't automatically trigger context changes unless users are warned beforehand.
• 3.2.3
  Consistent Navigation (AA) — Navigation menus appear in the same relative order on every page of the website.
• 3.2.4
  Consistent Identification (AA) — Components with the same function are identified consistently (same label, icon, or accessible name) across the site.
• 3.2.6 ✨
  Consistent Help (A) — NEW in 2.2 — Help mechanisms (live chat, phone number, FAQ link) appear in the same location relative to page content across multiple pages.

3.3 Input Assistance

• 3.3.1
  Error Identification (A) — Critical — Input errors are identified and described to users in text (not just red borders).
• 3.3.2
  Labels or Instructions (A) — Most Common Failure — All form inputs have visible labels or instructions. Placeholder text alone is insufficient.
• 3.3.3
  Error Suggestion (AA) — If an input error is detected and suggestions are known, the suggestion is provided (e.g., "Please use MM/DD/YYYY format").
• 3.3.4
  Error Prevention — Legal/Financial/Data (AA) — Pages with legal, financial, or data-modification actions are reversible, verifiable, or confirm-able before final submission.
• 3.3.7 ✨
  Redundant Entry (A) — NEW in 2.2 — Information already provided in a session (e.g., name, address) is auto-populated or selectable rather than requiring re-entry.
• 3.3.8 ✨
  Accessible Authentication — Minimum (AA) — NEW in 2.2 — Login and authentication processes must not require users to solve cognitive tests (like transcribing distorted text). Copy-paste and password manager support must be allowed. Object recognition (select all images with bikes) is a permissible exception.

6. Robust — Checklist

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

4.1 Compatible

• 4.1.2
  Name, Role, Value (AA) — Critical for dynamic content — All UI components have programmatically determinable name, role, and current state. Custom widgets use ARIA roles and properties. ARIA aria-expanded, aria-selected, aria-label used correctly.
• 4.1.3
  Status Messages (AA) — Status messages (success, errors, loading states) are programmatically determined without requiring focus (use role="status" or role="alert" for live regions).

7. How to Test for WCAG 2.2 Compliance

No single tool catches all WCAG violations. Effective testing combines automated scanning with manual review:

8. WCAG 2.2 and the ADA Title II Deadline

The DOJ's final rule (April 2024) requires state and local government entities to meet WCAG 2.1 Level AA by April 24, 2026. The rule does not require WCAG 2.2.

However, since WCAG 2.2 is backward compatible with WCAG 2.1, targeting WCAG 2.2 AA is the recommended approach:

• Meets the ADA Title II requirement (since it includes all of WCAG 2.1 AA)
• Aligns with the current W3C standard — WCAG 2.1 is no longer the latest version
• Future-proof — if future regulations reference WCAG 2.2, you're already compliant
• Better user experience — the new criteria improve usability for everyone

For private businesses under ADA Title III, there is no specific WCAG version mandated — courts apply a "functional equivalence" standard. Targeting WCAG 2.2 AA is the safest approach.