Website accessibility audit: what it covers, how it’s done, and what drives the cost

A website accessibility audit tests a defined sample of your site against a standard, usually WCAG 2.1 or 2.2 at Level AA, and reports every failure it finds with where it is, the evidence and how to fix it. A competent audit combines automated checks, manual inspection by someone who knows WCAG, and testing with assistive technology such as screen readers. It ends with a report, not a certificate: an audit tells you what fails, and re-testing after your fixes tells you which of them are no longer found.

This guide follows W3C’s evaluation methodology through scope, sampling, testing and reporting, then adds the step that comes after: fixing and auditing again. The step numbers below are this guide’s own, not WCAG-EM’s. Along the way it covers what each layer of testing can and cannot establish, what a useful report holds, and what drives the price.

What an audit is, and what it is not

W3C’s WCAG Evaluation Methodology (WCAG-EM 2.0, a W3C Group Note published on 23 July 2026) is the closest thing to a reference process. It has five steps: define the scope, explore the site, select a sample, evaluate the sample, and report. Many professional audits follow that shape, whether or not they name it. For the target, it calls WCAG 2 Level AA “the generally accepted and recommended target”.

Three things get called audits and are not:

• An automated scan. Tools are part of an audit, but W3C’s own guidance is blunt: evaluation tools “can not determine accessibility, they can only assist in doing so”, and they sometimes “produce false or misleading results”. A scan report is an input, not the audit.
• A conformance certificate. WCAG-EM says that conformance claims “cannot be made for entire websites based upon the evaluation of a selected sub-set”, and that in most situations the methodology alone does not let you make one. An audit of a sample tells you about the sample and what it represents. It does not make your site compliant with any law.
• User research. Testing with disabled people can find barriers an expert evaluation misses, including some that pass every success criterion. WCAG-EM strongly recommends involving them but does not require it, so an audit may not include it unless you ask for it.

Whether a law applies to your site depends on what you offer, to whom, the size of your business, and national law. If one does, the audit is evidence you keep, not the compliance itself. For the EU, see what the European Accessibility Act asks a website to prove.

Step 1: set the scope and the target

Every later decision depends on four choices made before any testing.

What is in scope. List the domains, subdomains and sections the audit covers, so that, in WCAG-EM’s words, “for each view it is unambiguous whether it is within the scope of evaluation or not”. Decide about signed-in areas, embedded third-party widgets (chat, maps, payment, video), and PDFs and other documents. WCAG conformance is for full pages: you cannot exclude the part of a page you don’t like. For content you genuinely do not control, such as user comments or ads inserted by a third party, WCAG allows a “statement of partial conformance”: it says the page does not conform, but would without those parts. Signed-in pages need a test account and their own sample.

The conformance target. Usually Level AA: every Level A and Level AA success criterion, 55 of them in WCAG 2.2. Which version you test against depends on why you are auditing. In the EU, EN 301 549 V3.2.1, the harmonised standard under the Web Accessibility Directive, adopts WCAG 2.1 Level AA. No harmonised standard is cited yet under the European Accessibility Act, and V4.1.1, on WCAG 2.2 Level AA, awaits citation (see what EN 301 549 V4.1.1 changes). WCAG 2.2 Level AA includes every WCAG 2.1 A and AA success criterion except 4.1.1 Parsing, which 2.2 removed; if a law or contract names WCAG 2.1 or EN 301 549 V3.2.1, you may still need to test and report 4.1.1. Don’t make Level AAA the target for a whole site: WCAG itself advises against it, because some content cannot meet every AAA criterion.

The accessibility support baseline. WCAG-EM asks you to name the browsers and assistive technologies the site must work with, for example a screen reader and browser pair on desktop and another on mobile. This list is what the assistive-technology testing in step 3 runs on, so it also drives the cost.

Screen sizes. WCAG counts each responsive variation of a page as part of that page, and “each of these variations needs to conform”. An audit that only looks at desktop has not tested the page you ship to phones.

Step 2: choose the pages

Few sites can be tested page by page, and WCAG-EM does not ask you to. It does recommend evaluating everything when that is feasible. Otherwise, it builds the sample in three parts:

1. A structured sample. First explore the site: its common views (typically the pages linked from the home page and from the header, navigation and footer), its essential functionality, the different types of page, the technologies it relies on, and pages that matter especially to disabled people, such as help, contact and the accessibility statement. The sample then covers each of them. In practice, page templates are how you cover “types of page”: one product page, one category page, one article, one search results page, each chosen as the most complete instance.
2. A random sample on top, 10% the size of the structured one. Its job is to check the structured sample: if the random pages turn up new kinds of content or new failures, the structured sample was not representative, and you add pages.
3. Complete processes. If a sampled page is part of a process, such as sign-up, checkout or a booking, every page in that process joins the sample: at least its default path, plus the branches that are commonly used and critical to completing it. WCAG is strict here: if one step fails, no page in the process conforms.

We go deeper into choosing the representative pages, and what that leaves out, in template-based auditing.

Step 3: test, layer by layer

Each sampled page is checked against every success criterion in the target, at every screen size in scope. No single method can do that. Each layer of testing establishes different things, and a good audit says which layer produced each result.

Automated rules come first because they are fast and repeatable, and every failure they remove is one an evaluator does not need to log by hand. They cannot finish the job. W3C’s methodology puts it plainly: “most accessibility checks are not fully automatable”. We go through which criteria an automated rule can check, and which only a person can, criterion by criterion.

Be wary of anyone who gives you a single percentage of WCAG that automation “covers”. The answer depends on the criterion, the page and the rule.

Step 4: report what was found, and what was not tested

The report is what you pay for. WCAG-EM asks for the outcome of every step to be documented, and a useful report makes each finding actionable on its own. For every finding:

• the success criterion it fails, with the WCAG version and level;
• where it is: the page, the element (a selector or a screenshot), and the screen size;
• the evidence: the measured value, what a screen reader announced, or the steps to reproduce it;
• the severity, meaning how badly it blocks people, since WCAG itself has no severity scale;
• how to fix it, in terms a developer can act on;
• which layer found it: an automated rule, a manual check, or a test with assistive technology.

And for the audit as a whole: the scope, the sample (every URL), the baseline, the dates, and which success criteria were not tested or not present on the sample. A report that only lists failures leaves you guessing about everything else.

Be careful with scores. WCAG-EM lists an aggregated score as optional and warns that such scores “can be misleading” and “do not provide sufficient context and information to understand the actual accessibility” of a site. A number out of 100 tells you less than the list behind it.

Step 5: fix, then audit again

Fix in the order that unblocks the most people: failures that stop someone completing a task first (a keyboard trap in the checkout, an unlabelled sign-in field), then those that repeat on every page because they live in a shared template or component. A fix in one shared component can clear many findings at once.

Then test again. A re-audit, sometimes called a retest, re-runs the same checks on the pages that failed and reports which failures are no longer found. Run the random sample again too: a fix in a shared component can break a page you did not look at. Automated rules re-run cheaply; anything a person judged needs a person again.

“No longer found” is the honest wording. A later test that does not find a failure shows the failure is gone from what was tested. It does not prove the fix is right for every user, which is one more reason to keep assistive technology and real users in the loop.

What drives the cost

Audits are priced per page or screen, per day, or as a fixed engagement, and the published figures vary widely. We compare them, with sources, in what an accessibility audit costs. Whatever the unit, the same things move the price:

• The number of distinct templates and states, more than the number of URLs. A thousand product pages built from one template are largely one template to test; a checkout with six steps and three error states is nine views.
• Complete processes, because every step must be tested.
• The accessibility support baseline. Each extra screen reader and browser combination repeats the assistive-technology testing.
• The conformance target, and whether you need WCAG 2.2’s newer criteria.
• What the report must include, such as a conformance report in a fixed format for procurement.
• Retest rounds, which may or may not be included.

Running automated checks before an auditor starts, and fixing what they find, means more of the paid hours go to the criteria only a person can test.

Questions to ask an auditor

• How do you build the sample? You want an answer that names templates, processes and a random sample, not “your top 10 pages”.
• Which WCAG version and level, and which assistive technologies? Get the baseline in writing.
• Will the report list what was not tested? Criteria marked “not tested” or “not present” are as important as failures.
• Who tests, and with what? Ask whether the manual testing is done by people experienced in WCAG evaluation, and whether disabled testers take part.
• Is a retest included? And how many rounds, within what time.
• Can we see a sample report? It tells you more than the sales page.
• What do you claim at the end? Be wary of promises of “compliance”, a certificate, or a single score. An audit gives you findings and evidence. Products that add a script to your pages and promise to fix accessibility are a different thing from an audit.

When the audit is done, the report is what you build from. We set out what an audit report should contain, with a template you can copy.