WCAG 2.2 AA Checklist

Who this is for: Marketing Managers, Website Owners, and IT Managers who want practical, business-friendly steps to achieve WCAG 2.2 AA compliance without getting lost in technical terms.

What you’ll get: A copy-paste checklist, a quick 15-minute test routine, and straightforward explanations of what “excellent” looks like—plus a downloadable CSV at the end.

Tip: Combine this checklist with a swift automated page scan to catch easy improvements.

What is WCAG 2.2 AA (in 30 seconds)?

WCAG (Web Content Accessibility Guidelines) is the global standard for making websites accessible to everyone, including people with disabilities. 2.2 is the latest update, building on 2.1. “AA” is the most common compliance target for organizations.

What’s new in 2.2? Additional requirements around:

• Clear, visible focus states that aren’t hidden

• Appropriate target sizes and spacing for touch

• Alternatives to dragging gestures

• Authentication that doesn’t rely on memory puzzles

• Consistent help across pages

• Preventing redundant entry (don’t make people re-enter data)

No need to memorize codes—use the checklist below and execute the quick tests.

How to use this checklist (and who should do what)

• Marketing / Content: headings, media text alternatives, link text, readability, captions/transcripts.

• Website Owner / Product: prioritization, acceptance criteria, release sign-off, accessibility statement.

• IT / Dev: semantics, keyboard support, focus order, forms, components, performance.

Work page-by-page on high-traffic and key conversion screens first (home, product, pricing, checkout, contact) before moving onto the remaining pages on your website.

Page structure & semantics

• One clear H1 per page; headings in logical order (no style-only headings).

• Each Page title accurately describes the page; updates on state change (e.g., “Thank you”).

• Landmarks used sensibly (header, nav, main, footer, aside).

• Lists are real lists; tables are for data with headers (th, scope).

• Links have meaningful text (avoid “click here” where possible).

• Language attribute set on the page and on inline language changes.

Keyboard access & focus order

• Everything is operable with a keyboard (Tab/Shift+Tab/Enter/Space/Arrows).

• A Skip to content link is visible on focus and functions correctly.

• Visible focus: definitive, high-contrast focus indicator on every interactive element.

• Focus order follows the visual order; no traps in modals/menus.

• When dialogs open/close, focus moves logically (into the dialog and back to trigger).

• Fixed headers/overlays don’t obscure the focused element.

Forms & errors

• Every input has a programmatic label (not placeholder-only).

• Groups of inputs (e.g., radios) use fieldset + legend.

• Instructions appear before input fields; required fields are clearly marked.

• Errors are distinct, specific, and announced to assistive tech (e.g., live regions).

• Inline validation: don’t block typing; validate on blur/submit with helpful fixes.

• Autocomplete attributes set where possible (name, email, address-line1, etc.).

• Avoid requiring users to re-enter the same data within a journey (use stored/contextual info).

Images & media

• Informative images have brief, precise alt text.

• Decorative images use empty alt (alt="") or CSS backgrounds.

• Complex graphics (charts) have a text summary or data table.

• Video features captions; audio/video includes transcripts; auto-play is avoided or muted with controls.

• Avoid placing crucial text solely in images; provide live text alternatives.

Color & contrast

• Text contrast meets AA against its background (body, small text, text on buttons).

• UI components (buttons, inputs, toggles) and their states have adequate contrast.

• Do not rely on color as the sole means to convey information (add icons, text, patterns).

• Provide a visible focus style distinct from hover/active.

• Check content in dark mode and over imagery/gradients.

Need a refresher on practical ratios and tokens? See Color Contrast Accessibility.

Interaction patterns (menus, dialogs, carousels)

• Menus: keyboard operable; arrow keys within menus; Esc closes; focus returns to trigger.

• Tabs/accordions: ARIA roles where appropriate; arrow keys switch tabs; panels labeled.

• Modals/dialogs: focus is trapped inside; background is inert; screen readers see a labeled dialog.

• Carousels: pause/stop controls; don’t auto-advance swiftly; are keyboard and screen reader friendly.

• Status messages (success/error/updates) are announced via polite live regions.

Mobile & touch targets

• Touch targets are comfortably large and well spaced (avoid cramped controls).

• Provide alternatives to dragging (e.g., buttons for sliders/sort).

• Content reflows without horizontal scrolling at 320px width.

• Zoom is not disabled; text can scale without disrupting layout.

• Respect reduced motion preferences; avoid parallax/auto-animation where it could hinder usability.

Quick 15-minute testing routine (per page)

1. Keyboard sweep (5 min)
   Tab through the page: are you able to reach everything in a sensible order? Is the focus always visible? Can menus, tabs, accordions, and modals be opened/closed and returned to the previous state?

2. Screen reader smoke test (3–5 min)
   Using NVDA/VoiceOver: confirm page title; skim headings; activate key controls; ensure labels and error messages are clear.

3. Automated checks (2–3 min)
   Run a quick scan for conspicuous violations (missing labels, low contrast, ARIA misuse). Triage noise, log actual issues.

4. Mobile spot check (3–5 min)
   On a phone: target sizes, reflow, zoom, motion. Perform key tasks: open menu, submit a simple form, dismiss a dialog.

Save results in a straightforward sheet: Page → Issue → Severity → Owner → Due date.

Accessibility statement & ongoing governance

• Publish an accessibility statement (what you support, how to contact you): refer to Accessibility Statement Template.

• Include accessibility checks in definition of done and release gates (refer to Accessibility CI/CD).

• Re-test top pages monthly or when significant UI changes are implemented.

• Train content editors on alt text, headings, and link text; add concise guidance to your CMS.

FAQs

Do we need AAA?
Most organizations target AA, which balances usability, effort, and legal expectations. Choose a few AAA items where they make sense for your audience.

Will an accessibility toolbar make us compliant?
A toolbar enhances usability options (e.g., contrast toggles) but does not resolve structural issues like headings, labels, or focus order. Use it alongside solid foundations.

How often should we re-test?
Treat accessibility like performance: keep it continuous. Run quick scans in CI, perform keyboard checks on every new component, and conduct a quarterly audit of key flows.

What’s the fastest way to start?
Address headings, link text, alt text, and visible focus/contrast issues on your top 5 pages—then tackle forms and core components.

Copy-paste checklist (Markdown)

Smart next steps

• Conduct a quick scan on a key page.

• Share this checklist with your team.

• When ready, advance to Accessibility Quick Wins and Keyboard Accessibility for rapid enhancements, and Accessibility and SEO to align with marketing objectives.