Accessibility Audit Scope: What to Include Before You Buy

Start with the decision the audit must support

An accessibility audit scope defines the digital property, standard, pages, processes, testing methods, and deliverables included in an evaluation. It lets a buyer compare proposals that might otherwise use the same phrase, "WCAG audit," for very different work.

Write down what you need the report to support: a remediation project, a website launch, a procurement response, or an ongoing accessibility program. Identify the person who will receive the findings and the team that will fix them. A developer needs reproduction steps and affected components; a project owner also needs priorities, exclusions, and an estimate of the work still to be assigned.

The checklist below is a suggested purchasing brief. W3C's conformance evaluation guidance provides the underlying evaluation framework. For the sequence of an engagement, read the audit process guide.

Define the website and its complete processes

List the domains, applications, languages, and authenticated areas included. Record which systems belong to your organization and which are supplied by vendors. A booking widget, payment service, or login provider can be part of a visitor's task even when another company hosts it.

Group the site by templates and functions rather than treating every URL as a unique design. Then identify complete processes: the steps required to register, book, purchase, apply, submit a form, or manage an account. Tell the evaluator about less visible states, including form errors, empty results, expired sessions, and confirmation messages.

For example, a proposed store audit might include a category page, two materially different product templates, search and filters, cart, and the full checkout process. That is an illustrative scope, not a fixed minimum or a claim about your store. The evaluator should explain how the sample represents the actual site.

Agree on the standard and testing methods

The proposal should name the WCAG version and conformance level. Do not use "ADA audit" as a substitute for that specification. The applicable legal requirements and the technical evaluation target are related but separate decisions; our coverage guide explains the distinction.

Ask for the browser and assistive technology combinations, keyboard testing, mobile coverage, zoom and reflow checks, and automated tools. The provider should explain why those methods fit the product and audience. If testing with people with disabilities is included, identify the tasks and research method separately from standards conformance evaluation.

A free scan is useful for an initial view of detectable issues. It does not establish that a page, process, or whole site conforms. W3C's Easy Checks likewise describes a first review rather than a comprehensive assessment.

Request findings that a team can reproduce

Ask for a sample report before selecting a provider. A useful issue record should identify the affected URL or component, tested state, steps to reproduce, observed behavior, user impact, relevant criterion, and enough evidence to understand the problem. Separate severity from the commercial priority assigned to the fix.

Record the tested version and evaluation date. If the site changes while the audit is underway, agree on which release the report describes. A report about an older build should not be presented as an assessment of the current website without checking the differences.

W3C's WCAG-EM Report Tool illustrates structured evaluation reporting. A polished PDF alone is not evidence of a thorough audit; inspect the scope and the findings it contains.

Set remediation ownership and retesting terms

Confirm whether the provider fixes issues, advises your developers, or only delivers the initial report. Assign third-party issues to someone who can work with the vendor. Include a process for accepting a replacement component when the original cannot be repaired by your team.

Ask what retesting includes: the number of rounds, the time allowed after fixes, whether shared components are checked across affected templates, and how new regressions are handled. Closed findings should have a recorded result. If something remains unresolved, the final report should say so.

For budget planning, compare the cost guide with the actual scope. A lower price can reflect fewer templates, a narrower method, or excluded retesting. No price range on an educational page can replace a quote for your product.

A brief you can send with your request

Include these fields in the same request to each provider:

• Property: domains, apps, languages, and authenticated areas.
• Purpose: launch, remediation, procurement, or recurring review.
• Target: WCAG version and level, plus separately identified contractual requirements.
• Sample: templates, components, complete processes, documents, and third-party services.
• Methods: manual, automated, browser, device, and assistive technology coverage.
• Deliverables: sample report, issue format, limitations, and handoff session.
• Responsibility: who fixes each type of finding and how questions are resolved.
• Retesting: included rounds, timing, acceptance evidence, and treatment of regressions.

If you are still defining the property, request a preliminary accessibility review. If you want to compare suppliers, the agency evaluation checklist we publish is a separate Grow Wild Agency resource; assess each supplier against your scope rather than treating inclusion as proof of suitability.