WCAG 2.2 AA Checklist

Who this is for: Marketing Managers, Website Owners, and IT Managers who want practical, business-friendly steps to meet WCAG 2.2 AA without drowning in jargon.

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

Tip: Pair this checklist with a quick automated page scan to catch easy wins.

What is WCAG 2.2 AA (in 30 seconds)?

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

What’s new in 2.2? Additional requirements around:

• Clear, visible focus states that aren’t hidden

• Reasonable target sizes and spacing for touch

• Alternatives to dragging gestures

• Authentication that doesn’t rely on memory puzzles

• Consistent help across pages

• Avoiding redundant entry (don’t make people re-type data)

You don’t need to memorise codes—use the checklist below and run 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: prioritisation, 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 rest of the pages on your website.

Page structure & semantics

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

• Page title 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 works.

• Visible focus: clear, 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; required fields are indicated.

• Errors are clear, 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.).

• Don’t force re-entering the same data within a journey (use stored/contextual info).

Images & media

• Informative images have concise, accurate alt text.

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

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

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

• Don’t put important text only in images; provide live text alternatives.

Colour & contrast

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

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

• Colour is not the only way 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 labelled.

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

• Carousels: pause/stop controls; don’t auto-advance quickly; keyboard and SR friendly.

• Status messages (success/error/updates) 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 breaking layout.

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

Quick 15-minute testing routine (per page)

1. Keyboard sweep (5 min)
   Tab through the page: can you reach everything in a sensible order? Is focus always visible? Can you open/close menus, tabs, accordions, and modals and get back to where you were?

2. Screen reader smoke test (3–5 min)
   With NVDA/VoiceOver: announce page title; skim headings; activate key controls; confirm labels and error messages make sense.

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

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

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

Accessibility statement & ongoing governance

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

• Add accessibility checks to definition of done and release gates (see Accessibility CI/CD).

• Re-test top pages monthly or when you ship major UI changes.

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

FAQs

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

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

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

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

Copy-paste checklist (Markdown)

Smart next steps

• Run a quick scan on a key page.

• Share this checklist with your team.

• When ready, move on to Accessibility Quick Wins and Keyboard Accessibility for rapid improvements, and Accessibility and SEO to align with marketing goals.