Accessibility audit reports: 11 straight answers

An accessibility audit report is a dated record of what was tested on a website, what was found, which WCAG success criteria each problem breaks, and what to do about it. It is a document, not a dashboard: something a client can open, read without training, and file.

A client — or their marketing lead, or whoever signs it off — expects four things. The scope: which pages, tested when, by what method. The findings: what is wrong, where on the page, how serious, and which criterion it breaks. The fixes: specific enough for a developer to act on without asking what you meant. And the limits: what was not tested, so nobody reads the report as a clean bill of health. Put your name and the date on it. The reports that get argued about later are the ones with no scope and no limits.

A client who wants something published on their own site is asking for a different document — the public-facing half of the pair is the accessibility statement template.

No. No tool can, and any tool that says otherwise is selling you something it cannot deliver. WCAG 2.2 describes how a page behaves with a keyboard, a screen reader, at 200% zoom, with reduced motion, under cognitive load. Most of that cannot be judged from HTML alone.

An automated scanner sees patterns: an image with no alt attribute, an input with no label, a heading that jumps from h2 to h4. It cannot tell you whether the alt text is useful, whether focus is visible, or whether a screen reader announces your dialog sensibly.

What automation does catch, it catches reliably and cheaply: AuditReady's 12 checks are deterministic — the same HTML always produces the same finding — and every finding names its WCAG 2.2 criterion. That is a real, repeatable baseline. It is not legal advice, and an AuditReady report is not a compliance certificate.

An automated scan reads the HTML the server sends and flags patterns it can prove are wrong. It is fast, repeatable, and it never gets bored on the fortieth page — which is why it should run first and on every deploy. A manual audit is a person using the site the way disabled users do: keyboard only, screen reader on, zoomed to 200%, in the states that only appear after interaction.

They find different things. Automation is good at missing alt attributes, unlabelled fields, duplicate ids, positive tabindex, tables without headers. It cannot measure contrast against a background image, judge whether link text means anything in context, or notice that focus order is confusing. Everyone who has measured this lands in the same place: automation catches a minority of real issues, and the rest needs a person with an afternoon and a keyboard.

The order to work in — machine pass first, then the keyboard pass, then the checks only a person can make — is set out in the accessibility audit checklist.

One page is a snapshot, not a crawl. That is exactly what AuditReady does: it fetches the single address you give it, runs 12 deterministic checks on the HTML that came back, and reports on that page as it was at that moment.

A snapshot is the right buy when you need a specific page checked: a landing page before launch, a checkout step the client is worried about, a template you have just rebuilt, or a regression check after a fix. It is the wrong buy when the client needs a site-wide statement, when the site has several distinct templates, or when the page is client-rendered — no JavaScript runs, so a React or Vue site can look far cleaner than it is. Then scan at least one page per template, and crawl or test by hand for the rest.

Three different purchases hide under that question.

Free tools cost nothing but your hours, and on a real site the hours are the bill: a keyboard pass and a screen-reader pass across a handful of templates is a day of work, not an hour.

An independent consultant or agency audit is priced in human days. That lands in the hundreds for a focused review of one template and in the thousands for a full multi-template site with a written report. Prices vary by market, scope and who signs it.

Subscription and monitoring platforms are largely quote-only, priced per page or per site, and they sell ongoing monitoring rather than a document you hand over.

AuditReady is the cheap part: $29 once per site for the report itself.

The good ones are free, and you should use several: WAVE from WebAIM for a visual overlay of problems drawn on the page; Lighthouse, built into Chrome DevTools and PageSpeed Insights, as a repeatable signal in CI; axe DevTools from Deque, whose axe-core engine most other tools embed; Pa11y for scripted, open-source runs across many URLs; Accessibility Insights for Web from Microsoft, which pairs automated checks with a guided manual assessment. Add NVDA or VoiceOver — both free — because nothing replaces listening to the page.

None of them hands you the deliverable. Each gives you a list of issues inside a tool's interface, and then you spend the afternoon rebuilding that list as a document with criteria, severities, fixes and your name at the top. AuditReady exists for that step: the same kind of deterministic HTML checks, laid out as the report you hand over.

You assess against the criteria; you do not "run a compliance check". Conformance is a claim about a defined scope on a defined date, so write both down first: target WCAG 2.2 level AA, these templates, these states.

Then work in layers. Clear the mechanical failures with an automated scan — missing alt attributes, unlabelled fields, broken heading order, no page language — because they are cheap to fix and they will show up in every audit. Then do the human passes: keyboard only through each main journey, a screen-reader pass on the same journeys, measured contrast, 200% zoom and a 320px viewport, forms and error messages, anything that moves or times out. Record what you tested and what you could not.

Each of those layers, in order, with the stopping rule for when the work is finished, is the accessibility audit checklist.

W3C's WCAG-EM methodology describes this process properly if you want a structure to follow.

Run the free tools, fix what is mechanical, then do the manual work and write it up. The write-up is where the hours disappear, and it is the only part you can shorten without cutting corners.

Minimum viable format: a table of page, element, what is wrong, WCAG 2.2 criterion, severity, evidence, suggested fix, status. Put a cover line on it — who prepared it, for which site, on what date — and a final page listing what you did not test.

AuditReady produces that document for one page: 12 deterministic checks, every finding tagged with its WCAG 2.2 criterion and a copy-paste fix, grouped by severity, plus the coverage disclosure and the manual checklist. You pay $29 once, the report opens, and you print or save it as PDF yourself.

The document a client may have to publish on their own site is a separate thing, written for a different reader — the accessibility statement template covers that half.

Traceability, scope and a next step. Our report is built to that shape, so here it is directly.

At the top: the site, the date and time of the scan, and "Prepared by" with your agency's name. Then what the report is based on — page scanned, page title, response size and fetch time, how many checks ran, and the check-set version, so anyone can reproduce it. Then a summary with counts by severity: critical, serious, moderate, minor.

Each finding follows: what is wrong, how many times it occurs, the offending elements with their location in the page, the WCAG 2.2 criterion and level it breaks, and a concrete fix. After the findings: a coverage table of every check that ran and what it examined, then the manual review checklist with the criteria each item maps to. Clients accept a report that shows its own limits.

Yes — type your agency's name and it appears at the top of the report as "Prepared by", with a line saying the findings come from AuditReady's automated checks. That is a label on a document, not access control: the name is a URL parameter, so anyone with the link opens the same report, and changing the parameter changes the name.

Use it the way a designer uses a title block — as attribution for a document you are handing over — not as a way to keep a report private. If the report is confidential, print or save it as PDF and send the file through a channel you already trust. Full white-label branding (your logo, your colours) is not built yet; today it is your name on a clean, neutral page.

Hand over the PDF, then keep the momentum in the same conversation: agree which findings you are fixing and which the client owns, and put a date on the re-test.

Fix in severity order — critical and serious first, because those are the ones that block people. When the mechanical fixes are in, re-scan the page: the scan is free and shows what is left, which is the cheapest proof of progress you will produce. Then finish the manual checklist and record the result, including the items you could not complete.

Keep the dated PDF as the record. If you maintain the site, put Pa11y or axe in CI so these problems do not come back silently, and re-run the audit when the design or template changes.