An accessibility audit becomes easier to commission, perform, and act on when everyone agrees what is being examined. A list of URLs is a useful start, but it does not describe a login journey, a validation error, a mobile menu, or the version of the website that was tested. Those details belong in the scope.
Use the outline below to turn an initial website inventory into an agreement that a reviewer and a delivery team can both understand. It is a planning template, not a declaration that a website meets WCAG.
Start with the decision the audit must support
Write one sentence explaining why the work exists. For example: “Evaluate the public appointment booking experience before its next release, identify barriers, and provide evidence that developers can reproduce.” That is more useful than “check accessibility,” because it identifies a product boundary and an intended outcome.
Separate discovery from evaluation. An early scoping exercise may identify page families, obvious automated findings, and unanswered questions. A full evaluation involves additional work, including manual examination of relevant interactions. WAI explains the role and limitations of evaluation tools; an automated scan alone does not establish conformance.
Record the intended accessibility standard and level, the product version, and who can approve changes to the scope. If any of these are undecided, give the decision an owner instead of quietly making an assumption.
Define pages, journeys, and states together
A URL boundary answers where the audit starts. A journey boundary answers what a person needs to accomplish. A state boundary answers which versions of the interface must be examined.
Consider a fictional appointment service. Its public pages include a home page, a service directory, service details, and a booking form. The booking journey also includes choosing an appointment, entering details, correcting errors, and reaching confirmation. A capture of the empty form does not cover that journey.
| Scope dimension | Example entry | Question to resolve |
|---|---|---|
| Website boundary | Public appointment service on the agreed production hostname | Are help articles on another hostname included? |
| Page families | Directory, detail, booking, confirmation | Are there older templates still in use? |
| Complete journey | Find a service and request an appointment | Who supplies a safe test appointment? |
| Interface states | Menu open, validation errors, unavailable appointment | How can each state be reproduced? |
| User context | Signed-out visitor, agreed language and viewport | Does another role receive different controls? |
Define these entries before selecting the final sample. Otherwise, the easiest pages to crawl can accidentally become the entire audit.
Use a scope outline that can be approved
The following fields work well as a starting document. Keep the answers specific enough that another reviewer could recognize the same product and test conditions.
- Purpose: the decision this evaluation will support and its intended audience.
- Product boundary: hostnames, sections, applications, languages, and relevant versions.
- Target requirements: the agreed standard and level, plus any separately identified organizational requirements.
- Journeys and states: essential tasks, exceptional states, and role differences.
- Sample rationale: how common layouts, unusual components, and complete processes will be represented.
- Test conditions: browsers, assistive technologies, viewport conditions, and available accounts.
- Evidence and delivery: finding format, page references, report outputs, and ownership.
- Constraints and unresolved gaps: inaccessible environments, unavailable content, and questions still awaiting answers.
- Retesting: what fixes will be checked, by whom, and against which release.
- Approval: the scope owner, reviewer, date, and change procedure.
Treat the outline as a working agreement. A change log can be as simple as a dated row explaining why a newly discovered payment step was added and whether the estimate changed.
Describe exclusions without hiding missing coverage
“Outside scope” and “not reached” have different meanings. A separately owned support application might be deliberately excluded. A booking confirmation page that could not be reached is an unresolved gap in an included process.
Keep those categories separate in both the plan and final report. For an excluded area, explain the boundary and the consequence for interpreting results. For a blocked area, record the obstacle, owner, and next action. Avoid treating an authentication failure as evidence that there were no relevant pages.
WCAG-EM 2.0 provides an evaluation methodology that includes defining the evaluation scope and selecting a sample. Its use of sampling does not make a small set of tested pages proof that every page conforms. State conclusions at the level the evaluation actually supports.
Connect the scope to evidence and effort
Assign stable references to sampled pages and journeys. A reviewer should be able to move from a scope item to the page evidence, then to a finding or a recorded test result. Avoid references such as “the second screenshot,” which become ambiguous when the document changes.
Use representative page sampling to explain the selection, and estimate audit effort from the actual interactions and review work. Large URL inventories can contain many repeated templates, while a small application can contain difficult multistep workflows.
Before commissioning the work, ask a second person to read the scope and describe what remains unknown. If their description differs from yours, clarify the document. You can also open the public OnChange scoping report to see how an inventory, captured evidence, and automated findings can support the planning stage. The sample is a discovery aid; the written scope still needs the human decisions described here.