Accessibility audits

An accessibility audit checks whether a product can be used by disabled people and meets standards such as WCAG. Stage 9 goes deeper; here we cover how to run an audit as part of testing.

Three layers

1. Automated tools (such as axe or Lighthouse) catch issues like missing alt text, low contrast and missing labels. They find only part of the problems.
2. Manual checks: use only a keyboard, zoom to 200% and 400%, check headings and focus order, check colour is not the only signal, and review content and error messages.
3. Assistive technology: test with a screen reader (such as NVDA, VoiceOver or TalkBack) and, ideally, include disabled participants in usability testing.

Auditing designs

You can audit before code: check contrast, target sizes, focus states, heading structure, labels, error messages and reading order in design files. Fixing issues in design is much cheaper.

Reporting

For each issue, note where it is, what is wrong, who it affects, the WCAG success criterion, severity and a recommended fix.

Accessibility problems exclude real people and can create legal risk. Automated tools alone miss many issues, so designers who can run manual checks and interpret results are valuable. Audits also build team awareness of how disabled people use products.

An automated scan of an events site shows only four issues. A manual check finds much more: the date picker cannot be used by keyboard, focus is invisible on the dark header, the "Book" buttons all read "Book" to screen readers with no event name, and error messages appear only in red.

The report lists each issue with WCAG references and fixes. The team fixes the keyboard and focus issues first because they block whole groups of users.