A website accessibility audit should do much more than run a scanner and export a list of errors. A useful audit defines what will be tested, evaluates representative pages and complete user journeys, combines automated checks with knowledgeable manual review, documents confirmed findings against an agreed accessibility standard, and gives your team enough evidence and remediation guidance to fix the barriers.
That distinction matters when you are comparing providers. Two companies can both sell an “accessibility audit” while delivering very different levels of testing, evidence, and follow-through.
Start With a Defined Audit Scope
A serious audit begins by documenting what is in scope. W3C’s WCAG Evaluation Methodology (WCAG-EM) 2.0, published in July 2026, starts with defining the evaluation scope, exploring the product, selecting a representative sample, evaluating that sample, and reporting the findings.
For a website, the scope may include:
- Key page templates such as the home page, product or service pages, articles, and contact pages
- Important components such as navigation menus, dialogs, accordions, tabs, carousels, and data tables
- Forms, validation, error messages, and confirmation states
- Critical user journeys such as registration, booking, checkout, search, login, or account management
- Third-party components such as payment tools, scheduling systems, chat widgets, or embedded forms
- Documents or media when they are part of an in-scope journey
For a large website, an audit does not necessarily test every URL individually. A representative sample can be appropriate when it covers the site’s common views, essential functionality, content types, technologies, and complete processes. The important point is that the sampling method should be deliberate and documented, not arbitrary.
The Audit Should Name the Accessibility Standard
Before testing starts, the report should state the target standard and conformance level. For many projects that means WCAG Level AA, but the exact version should be agreed in advance.
ADA Access Group currently evaluates against WCAG 2.1 Level AA by default and can include WCAG 2.2 criteria when the project, policy, or procurement requirement calls for them. If you need a refresher on the difference, see our guide to WCAG 2.1 AA and WCAG 2.2.
This prevents a common purchasing problem: receiving a report labeled “WCAG audit” without knowing which version or level was actually evaluated.
Automated Testing Is a Baseline, Not the Whole Audit
Automated tools are useful for identifying machine-detectable patterns efficiently. Depending on the page and tool, they may flag issues involving markup, some color contrast failures, missing attributes, invalid ARIA patterns, or label associations.
But W3C’s accessibility evaluation guidance is explicit that no tool alone can determine whether a site meets accessibility standards. Human judgment is required. A clean automated scan therefore does not mean the website is accessible, and a raw scanner export should not be presented as a complete audit.
For a deeper comparison, read Automated vs Manual Accessibility Testing.
Manual Testing Should Cover Real Interaction
Manual review is where an audit evaluates behaviors that automated tools cannot reliably interpret in context. The exact test plan depends on the agreed scope, but common checks include:
- Keyboard operation: Can people reach and operate menus, controls, dialogs, forms, and custom widgets without a mouse?
- Focus visibility and order: Is keyboard focus visible, logical, and correctly managed when content changes?
- Structure and semantics: Do headings, landmarks, links, buttons, labels, names, roles, and states communicate the intended structure and behavior?
- Forms and errors: Are fields labeled, instructions understandable, errors identified, and recovery steps usable?
- Visual presentation: Are contrast, reflow, zoom, non-color cues, and focus indicators usable within the target criteria?
- Dynamic content: Are updates, dialogs, expanded content, and validation messages exposed appropriately to assistive technology?
Forms deserve particular attention because technical labels alone do not guarantee a usable experience. Error recovery, focus movement, instructions, authentication, and repeated entry can all require human evaluation. Our article on accessible forms that still fail in practice shows why this layer matters.
Assistive-Technology Testing Should Be Defined
A strong audit should explain which assistive technologies and platform combinations were used when they are part of the test plan. Screen reader testing can reveal whether controls have useful accessible names, whether states are announced, whether headings and landmarks support navigation, and whether dynamic changes are communicated.
One screen reader or browser combination does not prove universal compatibility. The appropriate combinations should reflect the product, audience, project requirements, and agreed test environment. The report should document what was actually tested rather than implying broader coverage.
Critical User Journeys Need End-to-End Testing
WCAG conformance requirements address complete processes, not just isolated screens. That is especially important for commercial websites and applications.
An audit should therefore test important journeys from start to finish where they are in scope. Examples include selecting a product and checking out, completing an appointment booking, submitting an application, creating an account, recovering a password, or completing a multi-step form.
This also helps expose barriers in third-party tools. A booking widget or payment processor may sit outside your main codebase but still be part of the experience a customer must use to complete a task.
What Should Be in the Accessibility Audit Report?
The report is the main deliverable your developers, designers, content teams, and stakeholders will use after testing. It should be detailed enough to reproduce each confirmed barrier and practical enough to support remediation.
Useful findings typically include:
- The affected page, component, or user journey
- A concise description of the accessibility barrier
- The relevant WCAG success criterion
- User impact or the task that becomes difficult or impossible
- Evidence, such as a screenshot, code context, or documented test behavior where appropriate
- Reproduction steps
- Severity or remediation priority, with the rating method explained
- Practical remediation direction for the responsible team
WCAG itself does not prescribe a universal severity scale, so “critical,” “high,” or similar labels should not be treated as standardized WCAG terms. A good provider explains how it prioritizes findings.
Remediation Support and Retesting Should Be Clear Before You Buy
An audit identifies and documents barriers; remediation is the work of correcting them. Some providers include remediation support, while others sell it separately. The proposal should make that boundary clear.
Retesting is equally important. After fixes are implemented, significant findings should be checked against the original condition to verify that the barrier was actually resolved and that the fix did not introduce a new problem. ADA Access Group’s website accessibility audit service includes remediation support and a retest stage for significant fixes.
What Should Not Be Sold as a Full Accessibility Audit?
Be cautious if the deliverable is only a scanner score, a generic PDF with no reproducible findings, or a list of warnings without manual verification. Also be wary of claims that an audit automatically “certifies” a website as ADA compliant or guarantees that no accessibility complaint will occur.
Accessibility audits are technical evaluations. They can document how the tested scope performs against defined criteria and provide a practical basis for remediation, but they are not a substitute for legal advice and should not be presented as a guarantee of legal outcomes.
Questions to Ask Before Hiring an Accessibility Auditor
- Which WCAG version and conformance level will you evaluate?
- How will you select the pages, templates, components, and journeys in scope?
- What manual keyboard testing is included?
- Which assistive technologies and browser or platform combinations will you use?
- Will complete user journeys and third-party components be tested?
- What evidence and reproduction steps will each finding include?
- Will the report include developer-oriented remediation guidance?
- Is retesting included after fixes, and what exactly will be retested?
Those questions make it much easier to compare proposals on actual methodology and deliverables instead of price or an undefined promise of “compliance.”
What a Useful Audit Gives Your Team
The real value of a website accessibility audit is not the number of issues it lists. It is a clear, reproducible picture of where accessibility barriers occur, how they affect important interactions, which standard was applied, and what your team should address next.
If you are evaluating an existing site, preparing for a redesign, or need a developer-ready findings report, request a website accessibility audit to define the scope and testing approach before work begins.