Something to know about before you start: The accessibility tree.
Start here
Three(ish) lists, they’re all good! The rest of this page is my recommendation for breaking down the first one.
- Accessibility audit process
- Accessibility Not-Checklist
- Related: Accessibility Acceptance Criteria app (currently in Alpha)
- Checklist - The A11y Project
- For understanding seriousness of issues: Accessibility Audit Severity examples.
- For writing up results: Accessibility Audit Guide: writing good words.
Quick accessibility (a11y) checks
A bit of framing/thinking: Efficient accessibility testing.
Overview and high-level version, good for just doing the testing:
- Quick A11y Checks (QAC! 🦆) (Keyboard, Headings, axe DevTools)
- Quick Accessibility Checks (QAC! 🐥) for mobile (Larger text, Greyscale, Scanner)
Some other quick versions.
- Easy Checks – A First Review of Web Accessibility – WAI
- Form design: from zero to hero all in one blog post
QAC in detail
More detailed version, good for understanding the why and the how and the nuances:
Further reading
More thorough checks
- A quick guide to text alternatives for images.
- Form and error guidelines. Extensive!
- Sounds like a good idea: how to get started testing with a screen reader.
Manual and automated testing, tool-assisted and experiential testing
Go to Projects that use axe-core and (hopefully!) find axe for your setup. Prefer end-to-end flavours to unit flavours: axe is best at testing a whole page, as it appears to the user.
Have a read through of the config options. It can handy to tweak these in the beginning, before running the default set eventually. For example: (temporarily!) including or excluding particular elements, or (temporarily!) excluding certain rules.