A useful accessibility audit sample explains why its pages were chosen. Selecting the first twenty URLs from a crawl is easy, but it can miss a rare form, a legacy layout, or the final step in a critical transaction. Selecting only the busiest pages has a similar weakness: traffic does not describe every interaction people depend on.
Build the sample around coverage questions, then use URLs as references to the examples that answer them. This makes the selection easier to review and easier to expand when the site reveals something unexpected.
Build an inventory of differences
Begin with the website inventory, but add information that URL paths alone cannot tell you. Identify page families, shared components, interactive controls, content formats, language differences, and essential user tasks. Note which information was observed and which came from the product team.
Two article pages may use the same layout but differ because one contains a data table and another contains an embedded video. Conversely, hundreds of product URLs might share a common layout with only text and images changing. Neither situation should be reduced to a page count.
Use initial captures to spot differences, then ask owners about hidden states and less visible sections. A crawl can help organize the inventory; it cannot guarantee that every role, modal, or form error was exercised. The crawl coverage checklist helps separate discovered pages from unresolved gaps.
Map the sample to coverage reasons
Create a matrix in which each chosen example has at least one clear reason for inclusion. The following is an illustrative sample for a fictional education website, not a minimum required sample size.
| Example | Why include it? | Additional state or context |
|---|---|---|
| Course directory | Search, filtering, and result announcements | No results and active filters |
| Course detail | Main content layout and enrollment entry point | Expanded prerequisites |
| Enrollment process | Essential multistep task | Validation, review, and confirmation |
| Fees page | Complex table and explanatory notes | Narrow viewport and zoom |
| Recorded lesson | Media and transcript presentation | Player controls and captions |
| Older policy page | Separate legacy template | Shared navigation differences |
The matrix makes a weak choice visible. If five selected pages all say “same article layout,” ask what the additional four contribute. They may still be valuable content variations, but that reason should be explicit.
Include processes and exceptional states
A complete process can cross several URLs or stay on one URL while the interface changes. Count the meaningful steps and states rather than assuming one address equals one test case.
For enrollment, the sample should identify how a user reaches the form, chooses an option, enters information, receives errors, reviews the submission, and recognizes completion. Add the contexts that materially change the experience, such as an expired session or an unavailable course, when they fall within the agreed scope.
WCAG-EM 2.0 describes structured and random sampling and the inclusion of complete processes. Use that methodology to inform the evaluation design. A sampled evaluation still needs carefully bounded conclusions; the sample itself does not establish whole-site conformance.
Record safe test data and a way to reset the process. A task that works only once with an account nobody else can access is difficult to reproduce and retest.
Add variety without an arbitrary percentage
A fixed rule such as “audit ten percent of pages” can create false precision. Ten percent of a repetitive documentation site and ten percent of a complex service application describe very different work.
After assembling the structured sample, use additional selections to challenge your assumptions. Pick examples from different publication periods, content owners, or sections where that variation matters. Keep the selection method visible, including any genuinely random selection used by the evaluator. Do not call a handpicked set random.
Suppose the initial sample suggests that all department pages share one template. An extra selection reveals a legacy navigation system. That discovery should change the inventory and may expand the sample. It is evidence that the original grouping was incomplete, rather than a reason to discard the awkward page.
Agree on expansion rules before testing
Write down what will cause the sample to grow. Practical triggers include a newly discovered template, a component that behaves differently in another section, an unrecorded step in a critical journey, or a finding whose spread is uncertain.
For each trigger, define the next decision. A repeated navigation defect may require checking whether the same component is deployed across all templates. A single unusual document may require a separate content review. Neither automatically requires testing every URL, but both require an explicit response.
This approach also improves estimates. Reserve time for exploration and scope updates rather than pretending the first inventory is final. Estimating effort from templates and journeys makes those assumptions visible to the people commissioning the work.
Deliver a sample another reviewer can understand
The final selection should include a stable page reference, its coverage reason, relevant states, test conditions, and any unresolved access limitation. Keep a record of replacements. If a selected page disappeared during the audit, explain what replaced it and whether the coverage reason still holds.
Review the matrix with both the evaluator and the product owner. The evaluator can challenge whether it represents technical variation. The product owner can identify missing tasks and seasonal or role-specific content. Agreement between those perspectives is more useful than a long unexplained URL list.
The OnChange sample scoping report shows how page groups and captured evidence can make this conversation concrete. Use the report as input to the selection, then preserve the rationale alongside your audit scope. That rationale is what lets a later team assess whether a redesign or new feature requires a different sample.