A website accessibility audit should end with verified decisions, not a score
A useful website accessibility audit defines what is being evaluated, tests representative pages and complete user journeys, combines automated checks with expert manual review, and records evidence that a delivery team can act on. Before buying one, agree on the target standard, product scope, environments, sample, deliverables, owners, and retest. The result should tell you which barrier exists, who encounters it, where it appears, how to reproduce it, what requirement it relates to, and how the team will know the fix worked.
A scan can support that work, but it cannot replace it. W3C WAI states in its evaluation overview that no tool alone can determine whether a site meets accessibility standards. The buying decision is therefore not which dashboard has the cleanest score. It is whether the proposed method produces trustworthy, reusable evidence.
Buy the audit when a decision depends on the answer
Commission an audit when its findings can change a release, roadmap, procurement decision, redesign, or remediation plan. A pre-launch audit can catch barriers before they reach production. An audit of an existing product can establish a baseline and identify repeated component failures. A targeted audit can investigate one critical journey, such as account creation, checkout, booking, or submitting a support request.
Do not use a broad audit to avoid defining the business question. “Audit the whole website” sounds thorough but can produce hundreds of low-context findings while missing the path that matters. Start with the audience, the consequential tasks, the technologies in use, and the decision date. If the product is about to enter a website redesign, audit early enough for findings to change components and content patterns rather than merely decorate the launch backlog.
A preliminary review is appropriate when you only need to find obvious barriers or build internal awareness. It is not equivalent to a conformance evaluation. The scope and language of the report should make that distinction explicit.
Scope pages, states, components, and complete processes
The strongest proposals explain how the sample represents the product. W3C’s WCAG-EM 2.0 methodology structures evaluation around defining the scope, exploring the target, selecting a representative sample, evaluating that sample, and reporting findings. A representative sample is not simply the ten most visited URLs. It should include distinct templates, shared components, technologies, content types, responsive states, and complete processes.
Ask the auditor to name what is included and excluded. Logged-in areas, modals, validation errors, empty states, filters, maps, PDFs, video, third-party widgets, and mobile breakpoints often disappear from vague scopes. If checkout begins on one page and ends after authentication and payment, testing only the entry page proves very little about the process.
Consider a hypothetical subscription platform with forty marketing pages and one three-step cancellation flow. Sampling by traffic alone may emphasize the homepage and blog. Sampling by user consequence includes the cancellation flow, focus behavior after errors, confirmation messaging, and the account state after completion. That choice changes the value of the audit before a single criterion is tested.
Require manual tests that match the interface
Automated testing is valuable for repeatable checks, regression gates, and finding certain code-level patterns at scale. W3C’s guidance on selecting evaluation tools is equally clear about the limit: some checks require human judgment, and tools can return false or misleading results. A proposal should separate automated coverage from assisted and manual evaluation rather than presenting one percentage as total coverage.
Manual work should follow the product. For a content site, that may emphasize heading structure, links, zoom, reflow, media alternatives, and content clarity. For an application, it should also cover keyboard operation, focus order and visibility, accessible names, status messages, errors, authentication, time limits, dynamic updates, and recovery from failed actions. The auditor should state the browsers and assistive technologies used and why they fit the agreed scope.
The seductive shortcut is to buy an unlimited crawl and call it comprehensive. A crawler can visit more URLs than a person, but volume does not convert a machine-detectable rule into a complete assessment of an interaction. Use automation for breadth and consistency, then use expert review for meaning, behavior, and impact.
Demand evidence that survives the handoff to delivery
Every finding should be reproducible by someone who did not perform the audit. At minimum, request the affected URL or state, component, steps to reproduce, observed behavior, expected behavior, relevant success criterion, severity rationale, evidence, and a suggested direction for repair. Repeated instances should identify the shared cause so the team fixes the design system or component once instead of closing duplicate tickets page by page.
The report also needs a scope statement, method, dates, exclusions, tested environments, and reviewer expertise. The W3C WAI report template includes an executive summary, background, scope, reviewers, process, results, recommended actions, references, and appendices. That structure makes later comparison possible and prevents a screenshot folder from impersonating a decision document.
Ask how findings will enter your workflow. A polished PDF is useful for governance, while engineers often need issue-ready records with stable identifiers. Product, design, content, and engineering owners should be able to filter the same evidence without translating it into four competing spreadsheets.
Prioritize by user impact, reach, recurrence, and release risk
WCAG level and severity are not interchangeable. A useful remediation order considers whether the barrier blocks a task, how many journeys and users it affects, whether it repeats through a shared component, how safely it can be fixed, and when the affected code will ship. A keyboard trap in a shared dialog may deserve attention before dozens of isolated text alternatives because it can block every workflow that opens the dialog.
Assign one owner and one verification method to each repair. Design may need to change focus treatment, content may need to rewrite instructions, engineering may need to restore semantic behavior, and product may need to remove an unnecessary timeout. Complex interfaces benefit from the same explicit state thinking shown in Seuil’s AI product work: success, uncertainty, error, interruption, and recovery are all part of the experience.
Agree on retesting before remediation starts. The original steps and environments should be rerun, regressions checked, and residual limitations recorded. Without a retest, “fixed” means that code changed, not that the barrier disappeared.
User evaluation adds reality, but it does not replace conformance testing
Involving people with disabilities can reveal usability barriers that a standards review does not expose. W3C WAI recommends combining user involvement with conformance evaluation, because neither one alone establishes the experience for every disability, assistive technology, or situation. Recruit for the tasks and audience, document the participants and setup, and avoid generalizing one person’s experience to everyone.
This matters when an interface technically exposes the right semantics but remains exhausting, ambiguous, or difficult to recover from. A short moderated session on a critical prototype may change a design earlier than a late audit can. It is a complement with a different purpose, not a premium checkbox added to make the proposal look complete.
An audit is also a point-in-time evaluation of an agreed sample. It does not guarantee that future content, releases, or third-party changes remain accessible, and it is not legal advice. Lasting improvement needs accessible components, author guidance, acceptance criteria, automated regression checks, periodic expert review, and an escalation path when users report a barrier.
Website accessibility audit buying checklist
- Name the product, target standard, conformance level, dates, environments, and explicit exclusions.
- List priority user journeys, complete processes, templates, states, components, documents, and third-party surfaces.
- Ask how automated, assisted, manual, and user evaluation differ in the proposed method.
- Require reproducible evidence, stable finding IDs, impact-based priorities, shared-component analysis, and issue-ready exports.
- Assign product, design, content, engineering, and governance owners before the report arrives.
- Reserve time for clarification, remediation support, retesting, regression checks, and a dated residual-risk record.
The final buying test is simple: could your team estimate, assign, repair, and verify the work from the promised outputs? If not, the proposal is selling detection rather than improvement. To scope one useful slice, send Seuil Digital the priority journey, current stack, release context, and decision deadline. We can define the evidence the project needs before prescribing the size of the audit.