Website Accessibility Checklist (WCAG 2.2)
A practical WCAG 2.2 checklist: keyboard, focus, contrast, forms, media and screen reader checks. Run it before each release or as a periodic review.
- Typical schedule per release
- The checklist 6 sections, 28 items
- Variables
{{site}} - Start from CI
Use this checklist before launching a site, before a major release, and as a periodic review of a live site. It is organised around the WCAG 2.2 principles and focuses on the checks that catch the most real barriers: keyboard access, visible focus, contrast, form labels and text alternatives. Automated tools find only part of the issues, so most items here are manual checks.
Who owns it
A front-end developer or QA tester usually runs it, with a designer checking contrast and focus styles. For client work, the project lead decides which level (usually WCAG 2.2 AA) the project targets and records that in the contract.
Common pitfalls
- Relying on an automated score. Tools like axe or Lighthouse are a good start, but they cannot tell whether alt text is meaningful or whether a flow works with a keyboard.
- Accessibility overlays. Widgets that promise to fix a site with one script do not fix the underlying code, and many disabled users find them in the way.
- Testing only the home page. The barriers are usually in forms, checkout, modals and menus.
- Checking once. New content and components break accessibility over time. Repeat the check per release.
This is a practical checklist, not a full conformance audit or legal advice. Requirements such as the ADA in the US or the European Accessibility Act depend on your jurisdiction and sector. Trigger a run after each staging deploy so the check stays part of release work.
The checklist: Accessibility check for {{site}}
Automated scan
-
Automated scan run on key templates (e.g. axe DevTools, WAVE, Lighthouse)
Cover the home page, a content page, a form, search results and checkout or sign-up if present.
-
Every automated error reviewed and fixed or ticketed
Keyboard and focus
-
All interactive elements reachable and usable with the keyboard alone
-
Focus order follows the visual order of the page
-
Focus indicator is clearly visible on every interactive element
-
Focused elements are not hidden behind sticky headers, banners or chat widgets
WCAG 2.2 added a criterion for this (Focus Not Obscured).
-
No keyboard traps in menus, modals or embedded widgets
-
Skip link to the main content works
Visual design
-
Text contrast meets 4.5:1 for normal text and 3:1 for large text
-
Icons, input borders and focus indicators have at least 3:1 contrast
-
Page works at 200% zoom and reflows at 320 CSS pixels wide without horizontal scrolling
-
Information is not conveyed by colour alone (e.g. errors, required fields, chart series)
-
Touch and click targets are at least 24 by 24 CSS pixels or have enough spacing
Content and structure
-
Page has a descriptive title and a correct language attribute
-
Headings form a logical outline without skipped levels
-
Images have meaningful alt text, and decorative images have empty alt
-
Link and button text makes sense out of context
-
Videos have captions and audio content has a transcript optional
-
Auto-playing content can be paused or stopped optional
Forms and interaction
-
Every form field has a visible, programmatically linked label
-
Errors are described in text and linked to the field they belong to
-
Users are not asked to re-enter information they already gave in the same process
-
Login does not rely on a memory or puzzle test without an alternative
Allow paste and password managers in password fields, and offer an alternative to puzzle CAPTCHAs (WCAG 2.2 Accessible Authentication).
-
Drag-and-drop actions have a single-pointer alternative optional
Screen reader and sign-off
-
Main flows tested with a screen reader (e.g. NVDA, VoiceOver)
-
Modals, menus and dynamic updates are announced correctly
-
Remaining issues ticketed with severity and the related WCAG criterion
-
Accessibility statement updated if the site publishes one optional
Checklist as Markdown
Start this checklist from your pipeline
After a staging deploy, POST /api/v1/runs with template "Accessibility check for {{site}}" and site set to the staging URL.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Accessibility check for {{site}}", "variables": {"site": "…"}}'Frequently asked questions
What is new in WCAG 2.2?
WCAG 2.2 adds criteria for focus that is not hidden by other content, a more visible focus appearance (at AAA), dragging alternatives, minimum target size, consistent help, avoiding redundant entry, and accessible authentication. It also removes the old parsing criterion. Sites that met WCAG 2.1 AA mostly need to check the new focus, target size, form and login criteria.
Is this checklist enough for ADA or European Accessibility Act compliance?
No checklist can promise that. Laws refer to standards such as WCAG in different ways, and which ones apply depends on your jurisdiction, sector and organisation size. Use this list to find and fix common barriers, and get a specialist audit if you have a legal obligation.
Can accessibility testing be fully automated?
No. Automated tools reliably catch issues like missing labels and low contrast, but many criteria need human judgement. Combine an automated scan in CI with a manual keyboard and screen reader check on each release.
Updated