What you are actually buying when you buy an audit

Scan, review, audit

A scan is automated and instant. It covers the machine readable criteria and reports them page by page.

A review is somebody knowledgeable spending an hour looking at your site and telling you the obvious problems.

An audit is systematic. A defined sample, every criterion that applies, tested by hand, written up with evidence. The difference is rigour, and that is what you pay for.

The word audit gets used for all three, which is why asking what the sample is tells you more than the price does.

How the sample is chosen

Nobody audits every page of a large site. A good auditor chooses a sample that covers every template, every component, and every important path through the site.

That means your homepage, a content page, the contact form, any booking flow, a search result page, and anything unusual.

Ask how the sample was chosen. A sample missing your booking flow has not tested the thing that matters most.

A sample missing your booking flow has not tested the thing that earns money, whatever else it covered.

What the report should contain

Each finding tied to a specific criterion, with the page and element, a description of the effect on a user, a severity, and how to fix it.

Screenshots or code snippets so a developer can find the problem without guessing.

A summary a non technical owner can read and act on. A report only a specializt can follow is half a job.

What it will not tell you

It is a point in time. A site that passes in March and adds forty pages by June has not been audited for those pages.

It is also not a legal opinion. An auditor tests against the criteria. They do not say whether a duty applies to your business.

And it is not a certificate. Anybody offering certification of accessibility is offering something the guidelines do not define.

It is a point in time, not a state. A site audited in March with forty pages added since has not been audited for those pages.

User testing is separate

A technical audit and testing with disabled users answer different questions. The audit asks whether criteria are met. User testing asks whether people can actually do the thing.

Both find problems the other misses, and user testing is often the more persuasive internally because you watch it happen.

If budget allows only one, audit first, because it removes the obvious barriers before you spend somebody's time.

Questions before you commission

Which version and level of the guidelines. What the sample will be. Which assistive technologies will be used. What the deliverable looks like.

Whether a retest after remediation is included, and what that costs. Fixing without retesting leaves you guessing.

Ask for an example report with the client details removed. It tells you more than any proposal.

• Which version of the guidelines, and which level
• What the sample will be, and how it was chosen
• Which assistive technologies will be used
• What the deliverable looks like — ask for an example
• Whether a retest after remediation is included
• What it costs if it is not
• Who will be available to explain a finding to a developer

What to do before one

Run the free passes first. A scan, a keyboard walk, a listen, a read of your own alt text. Fixing those means the audit spends its time on things you could not have found yourself.

Every page written by Website Builder Studio passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards, so the automated layer is already handled.

Nothing here is legal advice. An audit is a quality exercise, and treating it as one gets more out of it.

Run the free passes first so the audit spends its time on what you could not have found yourself, which is the order set out in the accessibility checklist.