Accessibility QA Checklist

Accessibility testing means real interaction — not running an automated scan and calling it a day.

01 — Purpose

Test with your hands and ears

Automated tools find some issues. They do not find whether a real person can complete the task.

Use this checklist for manual accessibility QA on changed flows. Combine keyboard-only navigation with at least one screen reader spot check on critical paths — VoiceOver on Safari or NVDA on Firefox are common choices. For forms, compare against the GOV.UK validation pattern and our accessible forms guide.

02 — Keyboard

Keyboard access

If it cannot be reached and operated from the keyboard, it is not finished.

  • all interactive elements reachable in a sensible tab order
  • focus visible on every control — never removed without a stronger replacement
  • no keyboard traps — Escape closes dialogs, menus, and overlays
  • custom widgets match expected keys — arrows in menus, Enter to activate
  • skip link to main content works on first Tab from the top of the page

03 — Screen readers

Screen reader checks

Listen for missing names, wrong roles, and silent state changes.

  • page title and h1 describe the page purpose
  • headings reflect structure — not visual styling alone
  • dialogs announce name, trap focus appropriately, and return focus on close
  • form fields have understandable names; errors are announced and associated
  • dynamic updates use live regions thoughtfully — not noisy repetition

04 — Forms

Forms and validation

GOV.UK-tested error recovery is the bar for any form you ship.

  • every control has a visible label — not placeholder-only
  • hints and errors referenced with aria-describedby; invalid fields use aria-invalid="true"
  • failed submit shows error summary and per-field messages with matching text
  • focus moves to error summary or first invalid field; page title includes “Error: ” where applicable
  • error messages say how to fix the problem — compare with GOV.UK error messages

05 — Visual

Visual accessibility

Contrast and zoom failures block people who never touch a screen reader.

  • text and interactive elements meet contrast requirements on real backgrounds
  • information not conveyed by colour alone — use text, icons, or patterns too
  • page usable at 200% zoom — no clipped content or overlapping controls
  • prefers-reduced-motion respected — no essential information in animation only

06 — Sign-off

Before you sign off

Accessibility testing should involve real interaction — every release.

  • critical journeys completed keyboard-only
  • screen reader spot check on new or changed components
  • automated scan run — failures triaged, not ignored as “false positives”
  • known issues logged with severity and owner — not filed under “later”