Sampling for WCAG Audits: How Many Pages Prove Anything at All

2026-10-24

Every audit begins with an argument about scope. Testing every page of a large site is unaffordable, but testing ten pages chosen by the team being audited invites the obvious criticism that the audit measured the shop window, not the store.

Sampling is the honest middle path, borrowed from every other audit discipline. Done with a stated method, it produces findings that generalize. Done casually, it produces a report nobody should rely on, including the team that commissioned it.

Start with structure, not pages

Map the site into templates and components first. Every distinct template gets tested, because templates carry the shared barriers: navigation, headers, forms, and footers repeat everywhere, and a failure there is a failure on every page using it.

Then map complete user journeys: browse, search, buy, register, get support. Every step of the critical journeys enters the sample, because a single inaccessible step blocks the whole journey regardless of how clean the other pages are.

Add a random content layer

Beyond templates and journeys, draw a random sample of content pages, weighted by traffic so the pages real users hit dominate. Randomness is what stops the sample from being a highlight reel, and weighting is what keeps it relevant.

Record how the sample was drawn: the date, the method, the weighting, and any pages replaced and why. That record is what makes the audit repeatable next year and comparable across vendors.

How large is large enough

Sample size depends on template count and content variety more than raw page totals. A site with eight templates and uniform content may need forty pages. A sprawling site with forty templates and mixed media needs several times that, plus samples per media type.

Be suspicious of fixed numbers quoted before anyone has seen the site's structure. Any auditor who names a page count before mapping templates is selling a package, not an audit.

Reporting what the sample can claim

The report should state coverage plainly: which templates, journeys, and proportion of traffic the sample represents, and which areas it does not cover. Findings from templates can be stated site wide. Findings from content samples should be stated as patterns with the sample described.

That honesty strengthens rather than weakens the audit. Decision makers can price remediation properly when they know whether a barrier is a template fix or a thousand page problem.

Related reading

These earlier guides go deeper on connected questions: Color Contrast Monitoring: Metrics for a Problem That Keeps Coming Back, Accessibility Training Metrics: Proving Your Team Actually Learned Something, and Procurement Accessibility Metrics: VPAT Review Turnaround and Coverage.

Frequently asked questions

Can an audit test every page instead of sampling?

On small sites, yes, and it should. On large sites the cost is usually prohibitive and the value low, because most pages share templates. Structured sampling plus full template coverage finds the overwhelming majority of barrier patterns.

Why include random pages if templates are covered?

Because content teams create barriers inside templates: missing alt text, poor headings, inaccessible documents and media. Random content sampling is the only way to measure how often that happens in practice.

Who should choose the audit sample?

The auditor, using a documented method, with traffic data from the site owner. The team being audited should not hand pick pages, because even honest picking biases toward pages they maintain well.

How should sample limits appear in the report?

State the method, the templates and journeys covered, the share of traffic represented, and explicit exclusions. A reader should be able to repeat the audit from the report alone and get a comparable sample.

Get a free accessibility scan of your website

Free accessibility scan