What a Usable Audit Report Contains

Most audit reports fail their reader, not their standard. Here is the structure that gets findings fixed instead of filed.

Checks: 19
Time: The template is a structure, not a task
Last reviewed: August 28, 2026

For the team running an audit in-house, or checking whether the report they were sold is any good.

We have read a lot of other people's audit reports, usually because an owner brings one to us and asks what to do with it. The common failure is almost never bad testing. It is a report nobody can act on. That is a more expensive problem, because the testing has already been paid for.

Three things are below. The seven sections a usable report contains, the eight fields one finding needs, and the four severity bands that make a priority order mean something. If a report you have been handed is missing three or more of the seven, that is your answer about what it is worth.

One warning before the list, because it changes what you can claim afterwards. A report based on a sample of your pages tells you what was found on those pages, and it is not a conformance claim for the site. Anyone selling you one as though it were is selling you the wrong thing.

The seven sections a report needs

In this order, because each one answers the question the reader is already holding when they arrive at it. The first two exist for a reader who gets no further. They should still know what they bought.

1. Scope and method
Which addresses were tested, on which dates, against which standard at which level, in which browsers and with which assistive technology, and by whom. Two things get left out of this section most often and both matter. Which technologies the site relies on to work, and what assistive technology and browser combinations the claim assumes. Without all of it, nothing else in the report can be reproduced or checked.
2. Summary for the person paying
One page, no jargon, written for somebody who will not read section four. Where you stand overall, the three things that matter most, and what it takes to clear them. If the person who signed the order cannot follow this page, the report has already failed. Nobody will reach the findings.
3. Conformance table, rule by rule
Every applicable success criterion with a pass, a fail, or a not applicable beside it, rather than a top-ten list of what the tester happened to notice. A client asking whether they meet AA under WCAG 2.2 needs all 55 answered. That number is version-specific, so a report written to 2.1 answers a different set and is not therefore incomplete.
4. Findings in detail
One entry for each distinct problem, written to the eight-field format in the next section. Distinct is the word doing the work. The same missing label on forty product pages is usually one finding with a scope note, because one template change fixes all forty. Occurrence-level listing is a legitimate choice too, and some buyers ask for it. What matters is that the report says which scheme it used and counts consistently.
5. Priority order
Ranked by what happens to a person first and by what it costs to fix second. Blockers before annoyances, whatever level the rules sit at. Without this section a development team works down the report in the order it was written, which is the order the tester happened to walk the site in.
6. What was not tested
The honest section, and the one whose absence tells you the most. Pages skipped, flows that could not be reached without an account, anything agreed out of scope. A report implying coverage it never had is worse than one admitting the gap, because it leaves you defending a claim nobody made deliberately.
7. Retest plan
How the fixes get verified, by whom, and when. An audit with no retest is a photograph. Its value decays from the day it lands. Name who checks the work and what evidence closes each finding, or the report ends with a list nobody ever marks as done.

The eight fields one finding needs

Every finding needs all eight of these. Miss one and a developer has to come back and ask. That is where the days go on a remediation project, and where a report starts getting ignored.

A plain-language title
"Checkout submit button has no accessible name" tells a reader what happened. "4.1.2 violation" tells them to go and look something up. The title is what appears in a ticket queue. Often it is the only part a manager reads.
Where it is
The address, plus a CSS selector or a description precise enough that somebody can put their finger on the element. "On the product page" is not a location. That page has ninety controls on it.
What happens
The observed behavior, written as what you saw or heard rather than as a verdict, with the steps and the state it took to get there. "The button is announced as button, with no name" is something a developer can reproduce at their own desk, as long as you also say which browser, which assistive technology, and what had to be open. "The button is inaccessible" is a conclusion, and there is nothing in it for them to reproduce or disagree with.
Who it affects and how badly
Name the group and name the consequence. "Screen reader users cannot tell what this button does, which stops them completing checkout" is what turns a compliance line item into a business decision, and it is what stops a real blocker being triaged as cosmetic.
The rule it breaks
The success criterion number, its name and its level, where the finding is a breach of one. Some findings are recommendations rather than breaches, and saying so is more useful than inventing a criterion for them. This field is what a lawyer asks for first if the report is ever read outside the company. It settles which conformance conclusion the finding feeds, not how severe it is.
Evidence
A screenshot for anything visual, and for a screen reader finding, the exact words that were announced. Evidence is what makes a finding survive a disagreement, and it is the first thing missing from a report generated out of a scanner with a logo on it.
The fix
Specific enough that somebody can implement it without a second conversation, which usually means the actual markup. "Add an accessible name" is a restatement of the finding. The corrected element, pasted in, is a fix.
Severity
One of the four bands in the next section, judged by what happens to a person rather than by which level the rule sits at. Put it on every finding, because a report where everything is important is a report where nothing gets prioritized.

The four severity bands

Severity describes what happens to a person. The level describes what happens to your conformance claim. Both matter and they answer different questions, so a report that ranks only by level sends your team to the footer first. These four bands are ours rather than the standard's. Use them to order the work, and keep in mind that an applicable A or AA failure still blocks an AA claim however you banded it.

Blocker
Somebody cannot complete a core task at all, by any route. A keyboard trap in a dialog, a checkout button with no name, a form that cannot be submitted without a mouse. These get fixed this week. No argument, because every day one stays open is a day some of your customers cannot buy.
Serious
The core task is possible and it is very hard. A focus order that jumps around a form, errors that appear on screen and are never announced, a menu that works only after somebody guesses which key opens it. People finish, and a proportion of them give up first.
Moderate
Content outside the core journey is affected, or a workaround exists that a determined person will find. A supporting image with no alt text, a heading that describes nothing. Real. Worth fixing. Not worth stopping a release for.
Minor
Noticeable to somebody testing and not blocking anybody. A skipped heading level in a sidebar, a link whose text could be clearer in a list. Both are worth fixing and neither is automatically a breach of a criterion, so file them as recommendations where that is what they are. They belong in the report, at the bottom of it, because leaving them out makes the report look edited.

One honest limit

A template gives you the shape of a report and none of the testing behind it. The hard part was never the document, it is having tested every rule honestly enough that the table is true, and a template cannot tell you whether somebody did. To see this structure filled in, read our sample report, whose three findings are illustrations built from the failures we meet most often rather than one client's engagement. Then read how to read an audit report, which annotates that page line by line and says what each part of it cannot tell you.

Keep going

Other checklists

Ticked every box and want it verified?

The full audit tests all 55 WCAG 2.2 A and AA rules with a pass or fail on each, adds an expert review, and puts a real blind screen-reader user on your key journeys. $499, report in 5 business days.

Order your audit