Skip to main content
WCAGrules
Quick navigation

Glossary · Accessibility term

Automated testing

Also called: Accessibility scanning

Automated testing is software that checks a page's code for the accessibility failures a machine can prove. An image with no alt attribute. A form field with no label. Text measuring below the contrast threshold. Run it, because it is fast, it is cheap, and what it measures it measures the same way every time. What it cannot do is decide conformance, and that is not a gap in the tools. W3C says outright that no tool alone can determine whether a site meets the standard, and that knowledgeable human evaluation is required. So passing the scanner and being accessible are two separate claims, and only one of them is a thing a machine can settle.

In practice

Scanners are excellent at what they can decide. Contrast ratios, missing attributes, heading sequence, ARIA validity, and coverage across thousands of pages without ever getting bored. Put them in your build pipeline, where the job is catching regressions before they ship rather than issuing verdicts. They are also better than their reputation on some judgment calls, flagging repeated and suspicious alt strings even though they cannot tell you whether a description is true.

They are silent on everything that needs a person. Whether the alt text is accurate. Whether link text means anything out of context. Whether an error message helps. Whether a checkout can be finished by ear. On our own classification we graded 356 of W3C's 432 techniques and documented failures. Of those, 10 can be decided by a machine outright, 228 only partly, and 118 not at all. So 2.8% of what we graded can be automated end to end, and 118 of them no tool touches.

The structural version of the argument is stronger than the counting version, and it does not rest on anybody's classification. Three of WCAG's five conformance requirements are not properties of a page's code at all. Every page in a process has to conform. Only accessibility-supported ways of using a technology can be relied on. And four rules apply to all content on the page whether you rely on it or not. A tool does not know what your checkout process is, and it does not know which browser and screen reader pairings you are claiming support for, so it cannot reach any of the three.

Why it matters

W3C's own automated rules are the cleanest evidence here, because every rule publishes what its result means. On 59 of the 87 live rules, a clean pass is recorded as meaning the success criterion needs further testing. Only four rules in the whole set can clear a criterion outright. And 49 of the standard's 86 criteria have no rule written against them at all. So a failure from a scanner is decisive, while a pass is a question the standards body has already told you is still open. That asymmetry is why a percentage on a dashboard means so little. WCAG carries no scoring formula of any kind, which means every score you have ever been shown came out of a tool's own arithmetic, over whatever it happened to look at.

What a clean scan proves

Automated detection alone found WCAG failures on 95.9% of the top million home pages in 2026. The people who ran it drew the only honest conclusion available, which is that real conformance must be lower still than the 4.1% left over. A scan gives you a ceiling on how accessible a page might be. It never gives you a floor.

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