Manual accessibility testing and screen reader testing: a beginner's checklist
Automated scanners are a great start, but they can only test part of WCAG. Many success criteria need a person to judge them: is this alt text accurate? Does focus move in a sensible order? Does the error message make sense? Manual testing is how you find the barriers that matter most to real people. A good routine is to start with a free website accessibility test or another scanner, then test by hand.
What manual testing covers that scanners don't
- Whether alt text actually describes the image's purpose
- Whether headings and link text make sense
- Keyboard access, focus order, and visible focus in real use
- Whether menus, pop-ups, and custom widgets work with assistive technology
- Whether error messages and instructions are understandable
- Whether content reflows at high zoom without losing anything
Keyboard testing checklist
- Press Tab from the top of the page. Is the first stop a "skip to content" link?
- Keep tabbing. Is focus always visible and in a logical order?
- Activate links with Enter and buttons with Enter or Space.
- Open menus, accordions, and dialogs. Can you close them with Esc? Does focus return to where you were?
- Use the arrow keys in drop-downs and radio groups. Nothing should happen until you confirm a choice.
- Check you never get trapped (2.1.2 No Keyboard Trap) and that focus is never hidden behind sticky headers or banners (2.4.11 Focus Not Obscured, new in WCAG 2.2).
Screen reader testing: getting started
You don't need to be a fluent screen reader user to find big problems. Pick one setup and learn a few commands:
| Screen reader | Platform | Common browser pairing | How to get it |
|---|---|---|---|
| NVDA | Windows | Chrome or Firefox | Free download from NV Access |
| VoiceOver | macOS | Safari | Built in; Apple's VoiceOver guide |
| VoiceOver | iPhone and iPad | Safari | Built in (Settings, Accessibility) |
| TalkBack | Android | Chrome | Built in on most devices |
What to listen for
- Page title: announced first; does it say what page this is?
- Headings list: open the headings list (NVDA: Insert+F7; VoiceOver on Mac: the rotor, VO+U). Does it outline the page?
- Landmarks: can you jump to the main content and navigation?
- Images: are they described usefully, or announced as file names?
- Links and buttons: does each one have a clear name?
- Forms: does every field announce its label, hints, and errors?
- Changes: when something updates, such as a cart count or an error, is it announced?
Visual checks
- Zoom to 200%, then 400%. Nothing should overlap or be cut off, and at 400% you shouldn't need to scroll sideways to read (1.4.4, 1.4.10).
- Check contrast of text, buttons, and focus indicators.
- Make sure color isn't the only way information is shown, for example red-only error fields.
- Check that moving content can be paused.
Write down what you find
Note the page, the element, what happened, what should happen, and the WCAG criterion. That makes issues easy to fix and re-test. Our sample audit report shows one way to lay this out.
New to all this? Start with our step-by-step audit guide.