What does a good accessibility audit report include?
A good accessibility audit report says which pages and journeys were tested and when, gives a result for every criterion in the standard it was tested against (not only the ones that failed), shows the evidence behind each result, is honest about what could not be decided by the tests, and carries the name of the person who reviewed it. Everything else, including the score, is decoration on top of those five things.
Sooner or later someone will hand you an accessibility audit report, or ask you for one. Most of them look the same from a distance: a summary, a number, a long list. The ones worth keeping have five things in them, and the number is not one of them.
1. The scope, written down
Start at the back. Before the findings, before the number, a report has to say what it covered: which version of the product, which pages, which tasks (sign-up, search, checkout, a contact form), on what date, against which standard and level. WCAG conformance is claimed page by page, so a report that does not say which pages it looked at is claiming all of them, which is almost never true.
A short scope section does a second job. It tells the reader what the report cannot speak to. If the audit covered twelve public pages and the buyer’s real question is about the signed-in dashboard, both sides find that out on page one rather than six months later. WCAG 2.2 AA in plain words explains why a claim is tied to named pages.
2. A result for every criterion, not a list of failures
A list of problems is useful. It is not an audit. An audit gives every criterion in the standard an answer, including the ones that passed and the ones that did not apply, because a buyer reading an Accessibility Conformance Report has to fill in every row, and “it was not in the list of failures” is not the same as “it was tested and it passed”.
The honest set of answers is four, not two. A criterion can have passed, failed, not applied (a captions rule on a page with no video), or be undecided because the tests gathered the evidence but could not settle it. That fourth answer matters more than it looks, and why ‘can’t tell’ is an honest answer sets out the reasons. A report that only has pass and fail in it has either guessed on the hard ones or left them out.
3. Evidence you can check
Every finding should let a reader see what the auditor saw. For a failure that means where it is (the page, the element, ideally a picture of it with the element marked), what was measured or observed, and which criterion it breaks. For a pass it means what was looked at and how. A row that reads “1.4.3 Contrast: fail” tells a developer nothing they can act on. A row that shows the grey hint text on the sign-up form, the two colours, the ratio measured and the ratio required, tells them exactly what to change and lets them prove it is fixed.
Evidence also protects the author. A report is read twice: once by the person deciding whether to trust it, and again later by someone who has found a problem and wants to know what the report said about it. Only the version with evidence survives the second reading.
4. What the tests could not decide, in its own section
Some WCAG criteria are measurements, and software measures well. Others are judgements: does this text describe this image, does “learn more” say where it goes, does the error message explain how to fix the mistake. No automated test turns a judgement into a measurement, and a good report does not pretend otherwise.
So the report should say which results came from automated tests, which came from a person looking at the evidence, and which are still open. Open items are a to-do list, not a hole. They tell the product team where a person’s time is needed, and they tell the buyer that the rest of the report was not padded with guesses.
5. Grouped by fix, not only by rule
The same missing label on a shared header appears on every page the header does. A report that lists it forty times reads as forty problems when there is one fix. A good report groups findings that share a cause and says so: one problem, one fix, forty places it applies. The developer gets a shorter list; the buyer gets an honest picture of how much work is left.
The reverse is also worth stating. Where a problem really is different on every page, the report should not flatten it into one line to look tidy.
6. A person’s name on it
An accessibility audit report is a set of claims, and claims have authors. The report should carry the name of the person who reviewed the results and stands behind them, not only a company logo in the footer. If it is going to become a VPAT or ACR, that is the person who will sign. What a VPAT is, and what it isn’t explains why the signature is the whole point.
This is also the simplest test of whether a report was reviewed at all. Software can produce a document. Only a person can be asked, row by row, how they know.
7. Questions people ask
What should an accessibility audit report contain?
Five things: the scope (which pages, which version, which standard and level, what date), a result for every criterion rather than only the failures, the evidence behind each result, a clear account of what the tests could not decide, and the name of the person who reviewed it. A score is optional; the five are not.
Is an accessibility score a good measure of an audit?
No. WCAG has no score: a page either meets every criterion at the claimed level or it does not. A percentage hides which criteria failed, how many places each failure appears in, and whether the hard criteria were tested or guessed. Read the results and the scope, not the number.
How is an audit report different from a scan report?
A scan lists what automated tests found on the pages they were pointed at. An audit report gives every criterion in the standard an answer, including the ones a machine cannot settle, and says which answers came from a person. A scan with no failures is not a pass.
Who should sign an accessibility audit report?
The person who reviewed the results and agrees with them. If the report will become a VPAT or ACR, that is the vendor’s own named signer, because the conformance report is the vendor’s statement about its product. A company name alone is not a signature.
8. Where Dreven fits
Dreven produces a report in this shape. It finds your site’s pages, checks them against the standard you choose, keeps the evidence behind every result, and gives each result one of four states: passed, failed, not applicable or can’t tell. Problems that come from one shared component are grouped, so one decision covers every page it appears on. What the tests cannot settle goes to you, with the evidence beside it, and the report is a draft until you have decided and signed. See what a website accessibility audit covers.