An audit report is written for the people who will fix things. An ACR is written for a buyer deciding whether to purchase. An accessibility statement is written for the person on your site right now who cannot finish what they came to do. Same evidence underneath, three different readers, and a document written for one of them will not do the job of the others.
The short version
The audit report has the most detail and the least standing. The ACR has the standing and no field for scope. The statement is the only one a law tends to name, and it is the only one your actual users ever read.
What Each Document Is Actually For
Read the table by the second column. The audience is what decides everything else about a document, including the parts people find missing from it later.
| Document | Written for | What it reports | Who writes it |
|---|---|---|---|
| Audit report | Your engineering and content teams | Findings, one by one, with the steps to reproduce each and the criterion it sits under | Whoever ran the evaluation, internal or external |
| ACR, from a VPAT | A buyer comparing products | One answer per criterion, plus remarks, across the whole product | The product owner, usually. There is no certification and nobody reviews it |
| Accessibility statement | The person using your site | What standard you aim at, what is known to be broken, and how to reach a human | You, and it is published rather than sent |
The Audit Report Has the Detail and No Standing
Federal guidance on test reports draws this line itself. An ACR gives an overview of a product's conformance; a test report is the longer, developer-facing document that helps a product team improve it. So the report is where the reproduction steps, the screenshots and the code snippets live, and it is the only one of the three that tells a developer what to change.
What the report also carries is everything the ACR has no field for. The tester's name and organization. The date of evaluation as a separate thing from the date of publication. The operating system and browser. And the test scope, meaning what was tested, how many pages, and what was left out. Every one of those is a question a buyer ends up asking about an ACR, and the report is where the answer already exists.
Severity is worth a warning here. Reports commonly rank findings Critical, High, Medium and Low. That is a reporting convention, useful for planning, and it is not a WCAG concept. No criterion is more met or less met than another.
The ACR Has Standing and No Field for Scope
A VPAT is the blank template and an ACR is that template filled in. Its required header fields cover the product name, a version identifier if one is available, a report date, a product description, contact details, the evaluation methods used, the standards covered, the definitions of the terms, and the criteria tables.
Read that list for what is not on it. No page, screen or flow is named anywhere. So the document that a buyer treats as proof of a product cannot tell them which part of the product was looked at. That gap is why an ACR is not a WCAG conformance claim, and why it does not become one by being long.
The template says this about itself
Its stated purpose is to help customers and buyers make preliminary assessments. Preliminary is the template's own word, and it is a fair description of what one report can do on its own.
The Statement Is the One a Law Names
W3C names three things a statement has to carry: a commitment to accessibility for disabled people, the standard you applied, and a way to contact you when somebody hits a problem. Five more are recommended, and the first of those is known limitations, so that a reader finds out from you rather than by failing.
Where a law names a statement, the law's own list wins. The European model statement fixes the mandatory sections, including a compliance status chosen from exactly three options and a non-accessible content section broken into named categories, and individual countries have added to it. So the accessibility statement is the one document of the three where the format may not be yours to choose.
Why None of Them Converts Into Another
You can write all three from one evaluation, and you should. What you cannot do is reformat one into another, because each drops something the next one needs. An ACR has no scope field, so you cannot lift a scope out of it. A statement names known limitations in prose, so you cannot turn it into criterion rows. And an audit report answers for the sample somebody chose, which is narrower than the product the ACR speaks about.
That last one is the trap. A sampled evaluation cannot support a conformance claim for a whole site, because it is always possible an unexamined page carries an error. No sample size defeats that argument. So the honest move is to carry the sample forward into every document, rather than to let it quietly widen as the evidence gets retyped. Our page on turning one audit into both documents walks the mapping through.
Which One You Actually Need
- A buyer asked for something. They mean the ACR, whatever word they used. Ask which edition and which standard, because the answer changes which criteria the document even contains.
- A law applies to you. That is the statement, and the law's format governs.
- You want the site fixed. That is the audit report, and it is the only one of the three that will tell anybody what to do on Monday.
- All three are on the same request. Then you need one evaluation and three write-ups, which is normal, and it is cheaper than three evaluations.
If the request came from a university, a fourth document is probably in the pile too. Our page on what a campus procurement office is asking for covers that one.