All articles Engineering

A practical WCAG 2.2 AA checklist for product teams

Skip the 86-criterion slog. These are the WCAG 2.2 AA wins that catch the most real-world barriers — in plain English, with what to actually do.

WCAG 2.2 AA has 86 success criteria. Reading them cover to cover is a great way to lose a sprint and remember nothing. So here’s the version we actually use with product teams — grouped by where bugs really hide, in plain language.

This isn’t a substitute for a full audit. It’s the 20% that catches most of the damage.

1. Keyboard: can you use it without a mouse?

Unplug your mouse and try to complete your core flow.

  • Every interactive element must be reachable and operable with Tab, Enter, and Space.
  • The focus indicator must be visible at all times — no outline: none without a replacement.
  • Focus order should follow reading order. No surprise jumps.
  • New in 2.2: focus must not be hidden behind sticky headers or cookie banners (Focus Not Obscured).
/* Don't do this. */
:focus { outline: none; }

/* Do this — one loud, consistent focus style. */
:focus-visible { outline: 3px solid var(--focus-ring); outline-offset: 2px; }

2. Structure: does it make sense to a screen reader?

  • Use real semantic HTML<button>, <nav>, <main>, headings in order. A <div> with a click handler is not a button.
  • One <h1> per page; don’t skip heading levels for styling.
  • Provide a skip link to the main content.
  • Label every form field with a real <label>, not just a placeholder.

3. Colour & contrast

  • Body text needs a contrast ratio of at least 4.5:1; large text 3:1.
  • Don’t rely on colour alone to convey meaning — pair it with text or an icon (e.g. an error isn’t just red, it says what’s wrong).
  • Check both your light and dark themes. Dark mode contrast bugs are everywhere.

4. Targets & input

  • New in 2.2: interactive targets should be at least 24×24px (Target Size (Minimum)). We design to 44px because it’s kinder to everyone.
  • Don’t require dragging as the only way to do something (Dragging Movements) — offer a tap/click alternative.
  • Don’t make users re-enter information they already gave you (Redundant Entry).

5. Motion & media

  • Honour prefers-reduced-motion and give every animation a static end state.
  • Caption video; provide transcripts for audio.
  • Nothing should flash more than three times per second.

The fastest accessibility win on most sites is fixing focus styles and form labels. Start there.

How to test it

  1. Automated (catches ~30–40%): axe DevTools, Lighthouse, or pa11y in CI.
  2. Keyboard pass: tab through every flow.
  3. Screen reader pass: VoiceOver (Mac), NVDA (Windows) — even 15 minutes surfaces real issues.
  4. Zoom to 200% and check nothing breaks or gets cut off.

Automated tools are necessary but nowhere near sufficient — they find a minority of issues. The rest need a human, ideally one who uses assistive technology daily.

If you’d rather not run this gauntlet alone, book an audit. We’ll hand you a prioritised, plain-English list your team can ship against.

Want results like this for your product?

We turn accessibility from a risk into an advantage. Start a project or book an audit — we reply within one business day.