Does a completed screen-reader task establish WCAG conformance?

No. Our NVDA example verifies one heading-validator journey in one recorded configuration. It does not cover every applicable criterion, page, state or technology. Keep the actual task result separate from the scope of a complete conformance evaluation.

How many pages should an accessibility audit include?

There is no universal page count. Define the website boundary, identify its templates and functionality, and select a representative sample that includes complete processes. A store with several product templates and an interactive checkout needs a different scope from a small information site.

Should a quote include retesting?

Ask explicitly. The proposal should identify whether retesting is included, which fixes it covers, the number of rounds, and how unresolved findings will be documented. An initial audit report alone does not show that later fixes worked.

Is an automated scan the same as a manual audit?

No. Automated checks identify some detectable issues. A manual evaluation also examines operation, content meaning, assistive technology behavior, and complete tasks. Both methods should be described in the scope.

WCAG Audit Scope: Checklist and a Completed Test Example

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.

Use the scope builder to draft your own boundary. For a concrete comparison, jump to our completed limited-review example, assembled from retained October 19 test records.

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.

Completed example: our own tool review

On October 19, 2026, Grow Wild tested parts of the What Is ADA tools we maintain. The following scope is a retrospective record of completed work, assembled from the original test files. It was not a whole-site WCAG audit or a client engagement, and it should not be read as a scope agreed before those sessions.

The purpose was to check specific tool behavior and a visitor’s route through an input error. That narrow purpose matters: a useful result can support a maintenance decision without supporting a conformance claim.

The boundary we can substantiate

Property and views: the heading validator and color contrast checker on whatisada.com. These two tools were selected for maintenance work; they were not a representative sample of the entire site.
Heading task: reach the sample controls, load mismatched tags, submit, read the result, return to the input, correct it and inspect the new result. The NVDA session also reached the examples download link, but did not activate it.
Additional tool checks: nine synthetic heading inputs and six opaque sRGB color pairs. These checked the tools’ responses, not real client pages or a site-wide issue count.
Technical target: selected behavior relevant to accessibility testing. We did not evaluate every WCAG 2.2 A and AA criterion. A future complete audit would need an explicit version, level, product boundary and evaluation plan.
Evidence: input fixtures, keyboard observations, captured NVDA speech, page state and a screenshot. Each source retains its own date and environment; the tests did not all run on the same build or browser.
Outside the completed scope: VoiceOver/Safari speech, mobile assistive technology, participant usability, authenticated journeys, third-party transactions and full-site conformance.

For a broader evaluation, W3C’s WCAG-EM 2.0 methodology describes defining scope, exploring the product, choosing a sample, evaluating it and reporting findings. Our maintenance example illustrates evidence boundaries; it does not claim to have completed that methodology.

Four methods, four different kinds of evidence

Heading input checks. The nine downloadable inputs include a deeper heading-level jump, a return to a parent section and malformed markup. The tool rejects the mismatched input <h2>Products</h3> as an unrecognized line. An outline with no structural observations can still contain unrecognized input. The heading validator explanation shows why the input coverage and the heuristic observations must be read together. Neither count is a count of WCAG violations.

Color contrast checks. The six-pair record compares an independent calculation with the tool’s displayed results at revision ef105fa. One useful boundary example is #707972 on white: its ratio is approximately 4.499795, although the display rounds to 4.50. The tool’s normal-text AA result is Fail. This verifies the unrounded threshold decision for that pair; it does not establish the contrast of an actual page, image, gradient or state. The WCAG reference worked examples connect the calculation to its limits.

Keyboard task. Our keyboard-only session recorded focus and visible results at revision dfa5ba7, using the Codex in-app browser on macOS 27.0 at 1280 × 720. The browser engine version was not exposed and was not recorded. No screen reader was running. This evidence supports the recorded keyboard route, not a claim about spoken labels or announcements.

Actual screen-reader task. The NVDA session used NVDA 2026.2, Chromium 156.0.8078.4 and Windows Server 2022 at revision 01beb11. Guidepup operated real NVDA and retained its speech messages. The captured automatic output after submission announced the results heading; explicit Down Arrow reading then exposed the counts and correction instructions. After reading those details, three Shift+Tab presses reached the input. This is a different observation from the direct return path in the keyboard session, not evidence that either record should be silently rewritten.

These methods answer different questions. A screenshot corroborates visible state but cannot prove what NVDA said. A speech log does not establish that a color pair meets a threshold. Keep the evidence attached to the claim it actually supports.

Download the completed scope and evidence map

The map points to the original records rather than changing their dates or combining them into a new test. Checksums identify the exact downloaded files; they do not certify the quality or completeness of an evaluation. The Markdown download contains a filled example followed by a blank brief for a different project. Replace the example’s boundary and methods with your own requirements.

What we would add before making a wider claim

First inventory the wider product and identify the tasks, templates, content and states the two tools do not represent. Agree on the applicable criteria and supported technology combinations. Assign the missing evaluations, record barriers and retest repairs against the same task and environment where appropriate. Keep usability research with people with disabilities identifiable as its own work.

For this example, “NVDA task completed” is a defensible result. “Website passes WCAG 2.2 AA” is not supported by these records. An audit proposal should make the work needed to close that gap visible.

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.