Skip to main content
WCAGrules
Quick navigation

Glossary · Accessibility term

Manual testing

Manual testing is a person working through a page against the rules a machine cannot decide. Unplugging the mouse and driving everything by keyboard. Listening to the page in a screen reader. Reading the alt text and asking whether it is true, reading the error messages and asking whether they help, and watching where focus goes when a dialog opens. It is not a supplement to a scan. It is the part of the standard scanning cannot reach, and W3C says as much in its own words, that evaluation tools cannot determine accessibility and can only assist in doing so. The strongest version of it adds testers who use assistive technology in daily life. Knowing how people with disabilities actually use the web is named as its own kind of expertise, separate from knowing the standard.

In practice

On our own classification, 10 of the 356 techniques we graded can be checked fully by a machine, 228 can be checked in part, and 118 need a person from start to finish. The library holds 432, and the rest serve rules an audit does not test. Several criteria have no defined automated test method at all, including pointer gestures, reading level and sign language, so for those the choice is not between a tool and a person. There is no tool.

Even where a machine can test something, it usually tests presence rather than correctness. Of the ten published test rules that name the control-naming criterion as the thing they check, seven ask only whether the name is empty. So a button whose accessible name is the word button passes all seven. That is the whole argument for human review in one example, and it comes from W3C's own test methods rather than from us.

It is done with a keyboard, a browser narrowed to 320 pixels, developer tools and a screen reader, and every finding leaves with evidence attached. A finding a developer cannot reproduce is a complaint, not a defect. Record which build you tested and when, because a staging copy is a perfectly valid target as long as the report says so and the copy is genuinely representative of what shipped.

It is not a case against scanning. Automated tools found 56.1 detected barriers per home page across a million pages in February 2026, which is a lot of real problems caught cheaply. The honest position is about sufficiency rather than value. Run the scan, then start on everything it structurally could not look at.

Why it matters

Manual testing is where an audit earns its fee, and it is the part a cheap quote leaves out. That is how two reports on the same site can differ by a factor of ten and both be honest about their method. The tool makers say it themselves. WebAIM's note on its own data says that the absence of detected errors does not indicate a page is accessible or conformant. On their February 2026 run, the true rate of full conformance sat below the 4.1% of pages where their scanner found nothing. That gap is the manual testing gap, and it is the number to hold up when somebody waves a green dashboard. Ask what the scan could not see.

What only a person finds

Whether the alt text is true. Whether the link text means anything read out of context. Whether the focus order still makes sense after the CSS moved a column. Whether an error message helps somebody fix the thing or only tells them they were wrong. No scanner judges meaning, and every one of those is the difference between a page that passes and a page that works.

Where this shows up on the site

Related terms

Knowing the word is the easy part.

Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.

Run the free scan

Go somewhere useful

Find tools, resources and your workspace.

29 destinations