Manual Accessibility Testing

Manual accessibility testing is the evaluation of a website or app by a person, using a keyboard, assistive technologies and their own judgment, to find barriers that software can’t reliably detect. An automated scan can tell you that an image has no alt attribute. It takes a person to tell you that the alt text it does have describes the wrong thing.

Most organizations need both kinds of testing. Automated checks give you coverage across thousands of pages, and manual testing tells you whether those pages work for the people who use them. For how the two compare and how to combine them, see manual vs. automated testing.

What automated testing can’t judge

Automated tools are good at rules a machine can verify, such as a missing form label, a duplicate ID or the contrast between two flat colors. They struggle with anything that depends on meaning, context or the experience of operating a page. When the UK Government Digital Service ran 13 automated accessibility testing tools against a page containing 142 deliberate barriers, the best tool found 40% of them (GDS accessibility tool audit). Tools have improved since, but the kinds of issues they miss have stayed much the same:

• Whether alt text conveys what an image is for
• Whether link and button text makes sense out of context
• Whether the focus order follows the logic of the page
• Whether error messages explain how to fix the problem
• Whether text placed over images or video is readable

How to perform manual accessibility testing

Start by defining the scope: your most-used page templates, plus every complete process a user has to finish, such as a form, a checkout or a login. WCAG conformance applies to full pages and complete processes, so testing one step of a three-step form doesn’t tell you whether the form is accessible. Then work through these checks.

1. Keyboard only. Put the mouse aside and use Tab, Shift+Tab, Enter, Space and the arrow keys, as a keyboard-only user would. Check that you can:
   • Move between sections of a web page
   • Access all menus
   • Use a skip link to jump straight to each page’s main content
   • See which link or form field has focus at every step
   • Leave every component you enter, without getting trapped
2. Screen readers. Test with at least two screen reader and browser pairings, for example NVDA with Firefox or Chrome on Windows and VoiceOver with Safari on macOS or iOS. Listen for whether headings, landmarks, links, buttons and form fields are announced with names that make sense. See screen reader testing for a fuller walkthrough.
3. Zoom and reflow. Zoom to 200% and check that no text is cut off or overlapping. At 400% zoom on a standard desktop window, content should reflow into a single column without scrolling sideways.
4. Color and contrast in context. Check text over images, gradients and video with a color contrast checker, since scans often can’t measure it. Confirm that color is never the only way information is conveyed, as in a required field marked only in red.
5. Forms and errors. Submit forms with deliberate mistakes. Each error should be identified in text, tied to the field it belongs to and explain how to fix it.
6. Page titles and headings. An automated scan can find a missing title. Only a person can judge whether the title and headings describe the page clearly enough to navigate by.
7. Motion, timing and media. Check that moving or auto-playing content can be paused, that time limits can be extended and that captions are accurate rather than raw auto-captions.
8. Code that assistive technology depends on. Custom controls built with HTML and WAI-ARIA need to expose the right role, name and state. Checking this takes someone familiar with how assistive technology reads code.

Record each issue with the page, the steps to reproduce it, the assistive technology used and the WCAG success criterion it fails, so developers can fix it and testers can retest it. A structured manual review like this is also the core of a full accessibility audit.

Who should do manual accessibility testing

Manual testing is most reliable when trained testers do it. They need to know how people with different disabilities use the web, how to operate assistive technology the way its everyday users do, and what WCAG requires. WCAG 2.2 is the current version, but many laws and contracts reference WCAG 2.1 or 2.0 at Level AA. Test against the version and level your obligations name, and use 2.2 where you have the choice.

Testers can’t replace user testing with people with disabilities. Sessions with people who rely on screen readers, magnification, voice control or switch access every day surface problems a tester simulating that experience will miss. Feedback from one person with a disability doesn’t represent everyone with that disability, so recruit across a range of disabilities and prepare the assistive technology each participant needs before the session.

How often to test manually

Automated monitoring can run continuously. Manual testing can’t, so it needs a schedule. Test new templates and components before they launch, retest after significant design or code changes, and review your most important user journeys at regular intervals. Every change a developer or content editor makes can introduce a new barrier, which is why manual testing belongs in routine website maintenance rather than in a one-off project.