Skip to main content
WCAGrules
Quick navigation

Glossary · Accessibility term

Accessibility audit

An accessibility audit is a structured evaluation of a website against WCAG, ending in a documented pass or fail for every applicable rule with the evidence attached. W3C publishes a method for it, and testing is only one of five steps. You define the scope, explore the product, select a sample, evaluate that sample, then report what you found. The two steps before testing are where cheap audits actually go wrong, because a sample chosen badly makes everything after it unreliable. A real audit also uses more than one kind of pass. A machine finds what machines can decide, an expert reviews the judgment calls, and somebody who uses assistive technology daily works through the journeys that matter.

In practice

The word covers wildly different work, which is why quotes for the same site come back anywhere from a few hundred to five figures. At one end it is a scanner export with a logo on it. At the other it is three passes over a sample somebody chose deliberately. 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 the machine pass is where an audit starts rather than what it consists of. A list of top issues is a sample of a sample, and it cannot answer the question a customer is asking when they ask whether you meet Level AA.

Two things a buyer can ask about separate the real thing from the export, and both come out of W3C's own method. It wants two samples, one chosen structurally and one chosen at random, then compared. If the random one turns up failure types the structured one missed, the structured sample was not representative and the audit knows it before you do. It also wants the accessibility support baseline settled before any testing starts, meaning which browser and assistive technology pairings the work is judged against. Almost nobody publishes that, and it is the single commonest reason two audits of the same site disagree.

Processes are the exception to sampling. Once a checkout, a booking or an application is in scope, every page of it has to be in the sample set, because conformance for any one of those pages depends on all of them. Recording a URL is not enough there either, since a step is identified by what somebody did rather than where they were standing when they did it.

Why it matters

Two limits are worth saying out loud, and one of them costs us money. W3C's position is that a sampled evaluation cannot support a conformance claim for an entire site, because there is always the possibility of an error on a page nobody opened. So an honest audit answers what it found on what it looked at, and anybody selling a site-wide conformance verdict off a sample is selling something the standards body says they cannot deliver. The other limit runs the other way. W3C is equally plain that no tool on its own can determine whether a site meets the standard, and that knowledgeable human evaluation is required. That is the sentence that decides what an audit has to contain, and it is stronger than any statistic either of us could quote at you.

What to ask a vendor

Does the report give a pass or fail for every applicable rule, or a list of top issues? Which browser and screen reader pairings is it judged against? Is every checkout step in the sample? Does somebody who uses a screen reader daily work the flows? And is the retest included in the price, or billed again?

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