What a WCAG audit report actually contains

You asked three firms to quote an accessibility audit. One came back at a few hundred dollars, one at several thousand, one at five figures, and all three used the same words. Nothing in any of the proposals tells you what you'd actually receive.

The deliverable is not mysterious. Six things go in a WCAG audit report, and knowing them lets you read a quote the way you'd read a bid for a roof.

1. Scope — what was tested, and what wasn't

The first section should name a conformance target precisely: "WCAG 2.1, Level AA." Not "ADA compliant," which is not a testable standard and can't be measured against anything.

Then it names the sample. Nobody tests four thousand pages. A real audit selects a representative set — homepage, a department landing page, a news item, the agenda list, the calendar, search results, a page with a table, the 404 — chosen to cover every template the site uses, because that's where defects live. That's the standard approach, set out in WCAG-EM, the W3C's Website Accessibility Conformance Evaluation Methodology: define the scope, explore the site, select a representative sample, evaluate it, report the findings.

Scope also has to cover complete processes. If paying a utility bill takes five screens, all five are in scope, confirmation included. A process that fails on screen four fails as a process.

2. Method and tools — the section most people skip

This is where the price difference lives.

Every audit runs an automated scanner, and the scanners are broadly similar. What separates reports is what happened next: which pages a human tested, with which assistive technology, on which browsers, at which versions. "NVDA with Firefox and VoiceOver with Safari, on the eleven sample pages," with versions named, is a real answer. If the method section lists only a scanner, you bought a scan — worth having, but priced like the tool it is.

3. Findings — what a single one must contain

A finding is not a sentence. Each one should carry six things:

• The success criterion by number, name and level — "1.4.3 Contrast (Minimum), Level AA."
• Where — a URL plus a CSS selector or an annotated screenshot with the element marked.
• What was observed — "body text #8a8a8a on #ffffff, ratio 3.45:1."
• Why that fails — the threshold it missed.
• How to fix it, specific enough to hand to a developer without a follow-up call.
• Severity or priority, so you can sequence the work.

"Improve color contrast across the site" is not a finding. It's a heading.

4. The Accessibility Conformance Report

Ask whether the deliverable includes an ACR. A VPAT — Voluntary Product Accessibility Template, published by ITI — is the blank form; filled in for a specific product it becomes an Accessibility Conformance Report. It walks every applicable criterion and assigns one of four verdicts: Supports, Partially Supports, Does Not Support, or Not Applicable, each with remarks.

This is the artifact procurement understands, and it's the document to demand from your CMS vendor before you renew — not just from your auditor. A vendor selling to hundreds of municipalities who cannot produce one is telling you something.

5. Remediation plan and 6. Retest

The plan groups findings into work items in an order. The retest is what quotes routinely omit: a follow-up evaluation after the fixes land, confirming the findings actually closed. A report without one is half a deliverable — nobody has verified the fix worked.

The number in the report that matters least

Here's what I'd want a clerk to know before reading the first page. The finding count is close to meaningless. A report that opens with "4,182 errors" has usually found one bad template repeated across four hundred pages, plus one missing form label in a header that appears everywhere. The count measures how many pages you have, not how broken you are.

So ask for the findings grouped by component and template, not by page URL. That single request changes the character of the project. A per-page list is a to-do list nobody can finish, and it gets used as the reason not to start — four thousand rows in a spreadsheet reads as impossible. The same defects grouped by where they live in the code are usually a dozen fixes across three templates, half of them one-line stylesheet changes.

The second question is the one that prices the quote for you: which pages did a person test by hand, with which screen reader, and can I see that list? Everything before that answer is tooling anyone can run.

One caveat while you're comparing vendors: nobody certifies a website. DOJ issues no compliance certificate and no firm can give you one. Under WCAG's own rules a conformance claim is made by the entity about its own content — an audit is the evidence behind that claim and the record of the work you did.

What to ask for in the quote

1. The conformance target, in WCAG version and level.
2. The page sample, listed, plus the complete processes included.
3. The manual testing plan — pages, assistive technology, versions.
4. Findings carrying criterion, location, evidence, fix and severity, grouped by component.
5. An ACR, and a retest after remediation.

If you want to see what that looks like for your site before you commit a budget to it, a scan is where we start.