Start at the top of the document, with the small gray block nobody reads. It says which pages were opened, on what day, in which browser, with which assistive technology, and against which version of the standard. Every finding underneath it is a statement about those conditions and about nothing else. Skip the header and you have no way to tell whether a clean result means the site is fine or means nobody looked. That is the single most expensive mistake made with these documents, and it costs a sprint rather than a minute.
This page annotates a real one. We publish a specimen at our sample report. It is the only report artifact on this site, which makes it the one we can walk through honestly without inventing a deliverable that does not exist. Open it in a second tab and read the two together. Everything below points at a line you can actually see, and where our own specimen leaves a question open, this page says so rather than smoothing it over.
The Header Sets What Every Finding Underneath It Can Mean
A report header is not administrative furniture. It is the set of conditions the testing ran under, and each line closes one question while leaving a matching one open. The table below takes the header on our sample report line by line. If the report in front of you is missing one of these lines, that is not a formatting difference. It is a question about the evidence that nobody can now answer.
| The line | What it settles | What it leaves open |
|---|---|---|
| samplestore.example and 10 pages | Which product was looked at, and how much of it. Ten pages is the sample, and the sample is the whole of what the evidence covers. | Page eleven. A barrier absent from the report is absent from ten pages, which is not the same as absent from the site. |
| Evaluated August 26, 2026 | The day the evidence was taken. Everything in the document is a statement about the site as it stood that morning. | Whether it still holds. The date is there so you can work that out yourself, and WCAG sets no expiry on a report. |
| Chrome and NVDA on Windows | The browser and screen reader the manual work ran through. Results are true against that pairing. | Every other pairing. A finding here is not automatically a finding in VoiceOver, and a pass here is not a pass there. |
| HTML, CSS and JavaScript relied upon | The technologies the pages need to work. This is one of the five things WCAG requires a conformance claim to carry, and most reports leave it out. | Anything added later. A PDF, an embedded map or a video player that arrives next month sits outside this line. |
| Rapid Audit and WCAG 2.2 A/AA | The target, so the 55 rules at Level A and AA under version 2.2, and which package was bought. | What that package includes. Tiers differ, and the rule-by-rule table is the row to check on the pricing page before you go looking for it in your own report. |
| 23 findings, 6 critical, 31 of 55 rules passing | The size of the job. It tells a manager roughly what is coming. | Your conformance position. That number is counted across ten pages, and the next section is about why that matters more than it sounds. |
One line in our specimen's header is worth a moment on its own, because almost nobody publishes it. The technologies relied upon are the things your pages need in place to work as tested, and WCAG names that list as a required part of any conformance claim. A report that never says whether the evaluation assumed JavaScript was running has left out the thing that decides what the results describe. The same goes for the browser and screen reader pairing. Both lines cost the auditor one sentence, and without them a second auditor cannot repeat the work and check it.
A Summary Line Counts Work, It Does Not Grade the Site
"31 of 55 rules passing" is the line every executive summary reaches for, and it is a summary of an evaluation rather than a conformance result. The reason is in the standard's own wording. Conformance is defined only for web pages, and that sentence is doing real work, because it means a rule passes or fails on one page at a time. A figure spread across ten pages is an average of ten separate answers, and averaging hides the one page where the checkout failed.
The same section of the standard then widens what a claim may reach, and this is the half most sites drop. A conformance claim may be made to cover one page, a series of pages, or multiple related pages. So nobody is forbidden from claiming a whole site. What limits the claim is not a rule about page counts, it is what was actually evaluated, and W3C's evaluation methodology says the consequence plainly. A claim cannot rest on a sample of the pages alone, because the pages nobody opened may hold failures nobody found.
Which gives you a clean test to apply to any report you are handed. Ask what it was a sample of, then ask what the report claims. If the two match, the document is doing its job. If the summary reads like a verdict on everything you own and the header says ten pages, the gap between those two is the part somebody will have to defend later. Our own specimen states the limit in its own closing note rather than leaving you to notice it, and what conformance actually requires sets out the five things a real claim has to carry.
Pass, Fail, Not Applicable and Not Tested Are Four Different Answers
Report vocabularies are the author's, not the standard's, so the first thing to find is where the report defines its own words. Most use some version of the four below, and the fourth is the one that goes missing. When it does, its absence reads as a pass to every reader who was not in the room.
| The word | What it means | What it is not |
|---|---|---|
| Pass | The rule was applied to this page and the page met it, on the day and in the pairing the header names. | A statement about any page that was not opened, or any screen size that was not looked at. |
| Fail | The rule was applied and the page did not meet it. One failure of an applicable rule at A or AA blocks an AA result for that page, whatever severity the auditor attached. | A judgment about how bad it is. That is a separate field, and it is the auditor's. |
| Not applicable | The rule has no subject on this page. There is no video, so the captions rule has nothing to caption. This is a real answer that somebody arrived at by looking. | A gap. A finished report can honestly carry a lot of these, and it should say why for each one. |
| Not tested | Nobody looked. It is the honest word for a gap, and it belongs in the report rather than in a conversation afterwards. | A pass. This is the whole reason the word matters, and it is why a blank cell is worse than an ugly one. |
Two neighbours of that vocabulary catch people out. A scanner's incomplete or needs review result is not a fifth status. It is a question the tool is asking a person, and a report that files those under pass has turned a question into an answer. And the words in a vendor's accessibility conformance report are a different register again, so Supports, Partially Supports and Does Not Support do not map cleanly onto pass and fail. What a VPAT can and cannot tell you covers that document on its own terms, because reading it like an audit report is how buyers end up surprised.
Severity Is the Auditor's Judgment, and WCAG Publishes No Scale
Every finding in our specimen carries a colored chip reading Critical or Serious, and you should know exactly what those words are before you plan a quarter around them. They are ours. WCAG 2.2 uses the word severity zero times and defines no rating scheme of any kind, and W3C's evaluation methodology says so outright while explaining why aggregated scores mislead. So severity is a professional opinion about human impact, offered by the person who did the testing, and it is genuinely useful. It is not a measurement, and a report that presents it as one is telling you something about itself.
The proof of that is how little the vocabularies agree. Four scales sit within arm's reach of this page, three of them ours, and no two of them use the same words for the top band.
| Where you meet it | The words it uses |
|---|---|
| Our published report template | Blocker, Serious, Moderate, Minor. The audit template defines each band by what happens to a person and says in its own words that the bands are ours. |
| The findings in our sample report | Critical and Serious. Two chips, because the specimen shows three findings rather than a full report. |
| axe, the engine behind our free scan and most others | Critical, serious, moderate, minor, attached to the rule rather than to your situation. |
| US federal reporting guidance | Critical, High, Moderate or Medium, and Low, named as the levels commonly used in a test report. |
| WCAG 2.2 itself | Nothing. No bands, no score, no ranking, and no method for producing one. |
None of that makes severity worthless, and a report without it is worse than a report with it. It means you read the chip as advice and check two things behind it. Whether the report defines its bands anywhere, and whether the definitions turn on what happens to a person rather than on which level the rule sits at. A report that grades by level has quietly told your team to fix the footer before the checkout.
Severity, Level and Effort Answer Three Different Questions
These three fields are confused with each other constantly, usually in the meeting where the work gets scheduled, and the confusion always runs the same way. Somebody treats the WCAG level as a priority order. It is not one. It never was.
| The field | The question it answers | Who decides it |
|---|---|---|
| Severity | What happens to a person who hits this, and how soon somebody should fix it. | The auditor, using a scale they defined themselves. |
| WCAG level | Whether the rule belongs to a Level A, AA or AAA result. Level AA against AAA explains what that split is actually for. | The standard. It is fixed, and it is not a measure of importance. |
| Effort | How long the fix takes, what it depends on, and which team has to do it. | Your team, and nobody else can answer it honestly. |
Hold those apart and a strange-looking report starts making sense. A Level A failure can be minor in practice, because it sits on a page nobody visits. A Level AA failure can stop a keyboard-only customer paying you, because it sits on the button that takes the money. Both are true at once. What stays true underneath them is the conformance arithmetic. An applicable failure at A or AA blocks an AA result for that page however gently anybody banded it, and that is the sentence to keep for the meeting about whether something is worth fixing.
Read One Finding All the Way Through Before You Read Any Others
Findings look repetitive, so people skim them, and skimming is how a team ends up fixing the symptom. Take the third one in our specimen, the add-to-cart control built as a div, and walk its parts in this order. Every report worth paying for carries the same eight, whatever it calls them.
- The identifier. Ours reads WR-003. It exists so a ticket, an email and a retest can all point at the same thing six months from now, which they cannot do if the finding is only ever described in words.
- The rule and the level. This one reads 4.1.2 Name, Role, Value and 2.1.1 Keyboard, both Level A. Two criteria on one finding is not padding. The control has no name and no role, which is one rule, and no keyboard operation at all, which is a different rule. A report that filed this under 4.1.2 alone would have under-counted the barrier and shortened the fix.
- The plain-language title. "The add-to-cart button is a div, so screen readers cannot press it." A manager reads the title and nothing else. A title written as "4.1.2 violation" sends them to look something up instead.
- Where it is. The address, plus a selector or a description precise enough to put a finger on the element. "On the product page" is not a location, because that page has ninety controls on it.
- What was found. The observed behavior, written as what somebody saw or heard, with the markup that caused it. Ours quotes the element. This is the field a developer reproduces from, so a conclusion like "the button is inaccessible" is useless here. There is nothing in it to repeat.
- What it did to a person. Our specimen carries the tester's own words, that they found the product and the price and then spent four minutes looking for a way to buy it. That sentence is what turns a line item into a decision, and it is the field a purely automated report can never fill.
- The severity. Critical, on our scale, meaning nobody gets through this by any route.
- The fix. Specific enough to implement without another conversation, which usually means the corrected markup. Ours says make it a real
button, because role, name and keyboard support all arrive free, and one change closes both criteria at once. It also links the rule's own page, which is where the reasoning lives.
Read one finding that way and you will know within a minute whether the whole report is worth your team's time. Suppose field five is a conclusion rather than an observation, or field eight restates the problem instead of solving it. The rest of the document will have the same shape, and somebody on your team is going to have to go back and ask.
One Finding Is One Example, Not a Count of Broken Things
This is the misreading that costs the most, and it hides inside a number. "23 findings" sounds like 23 broken things, so a team works down the list, marks them off, and ships a release that still fails. The reason is a reporting convention almost nobody states out loud.
An evaluation report is expected to carry at least one worked example for every rule that was not met, and to flag which problems recur. Listing every single occurrence of every problem is something a buyer asks for and pays for, and it is not what a report does by default. So a finding is a specimen. The element it names is the one the tester photographed, and the other forty like it are covered by the scope note rather than by their own entries.
That makes one question worth asking before any work is scheduled. Ask the auditor whether the report counts problems or occurrences, and get the answer in writing. Both schemes are legitimate and they produce very different numbers from the same site, so a report that never says which one it used cannot be compared with the one you get next year.
Group the Findings by Cause Before You Assign Any of Them
Now the part that decides how much the remediation costs. Findings arrive in a list, and a list invites a team to work top to bottom, one ticket each. Almost no report is shaped that way underneath. Most findings trace back to a much smaller number of causes, usually a template, a shared component or a global stylesheet, and one change at the cause closes many entries at once.
Our own three sample findings show three different shapes of blast radius, which is why they are useful to line up next to each other.
| The finding | Where the cause lives | What one change reaches |
|---|---|---|
| Invisible keyboard focus | One rule in the global stylesheet, turning the outline off everywhere. | Every focusable element on all ten pages tested, and on every page that was never tested but loads the same stylesheet. |
| The add-to-cart control built as a div | One component, rendered on every product page. | Every product page at once, including the ones outside the sample. Fix the component and the count drops by more than the report shows. |
| Product images with no text alternative | Fourteen images on one page, and a template that lets an image ship without one. | Nothing, in one edit. Alt text is written per image by a person who knows what the product is. The template change is what stops the next fourteen arriving empty. |
That third row is the honest one. Grouping by cause is not a trick for making a long report short, because some findings genuinely are content and have to be fixed one at a time. What grouping does is separate the two kinds, so your developers get the template work and your editors get the content work, and neither queue is blocked waiting on the other. Sites built on a shared component library get the most out of this. A barrier in the library is a barrier everywhere the library is used, and a fix in the library is a fix everywhere too.
The Section Most Reports Bury Is the One to Read First
Somewhere near the end there should be a section saying what was not tested. Its absence tells you more than its contents ever will, because coverage a report implies but never had is a claim somebody in your company will end up defending. Four limits are worth checking for by name, and our specimen states three of them on the page.
- Screen sizes. The standard counts every layout a responsive page presents at a different width as a variation that has to conform on its own. Our testing runs on a desktop, so a barrier that only appears on a narrow screen is outside the evidence rather than absent from your site, and our sample report says exactly that.
- Complete processes. A page in a multi-step process only conforms if every page in that process does, and the standard's own worked example is a store checkout. So an evaluation that tested the product page and not the payment step has not answered for either of them.
- Anything behind a login. Accounts, roles and states have to be arranged in advance or they simply do not get opened, and what nobody opened cannot appear in the findings.
- The gap the machine leaves. Of WCAG 2.2's 86 criteria, 49 have no automated rule written against them at all, and 24 of the 55 at Level A and AA have none. A report assembled from a scanner has nothing to say about those, and silence is not a pass.
How to tell a report from an export
Our own free scan runs all 90 supported automated rules: 63 WCAG-mapped checks and 27 best-practice checks reported separately. The WCAG-mapped checks touch 20 of the 55 criteria at Level A and AA. Touching is not settling, because a rule that checks whether an accessible name exists cannot check whether it describes the control. So a document with a logo on it, a color-coded list of elements and no named tester, no browser, no assistive technology and no not-tested section is a scanner export. It is a genuinely useful thing to have. It is not an answer to whether you meet Level AA, and the difference between a scan and an audit is drawn by what a machine can settle rather than by what anyone felt like charging for.
Five Questions to Take Back to Whoever Wrote It
You are allowed to ask these, and a good auditor answers all five without pausing. If yours cannot, that is information about the report rather than about you.
- Which pages and which states were opened, and which were agreed out of scope before you started?
- Which browser and which assistive technology did the manual testing run through, and at what screen width?
- Does the report count distinct problems or every occurrence, and which scheme did you use here?
- Where are your severity bands defined, and are they judged by user impact or by WCAG level?
- Which findings share a root cause, so which single change closes the most of them?
Once you have those answers you have what you need for the next decision, which is what to fix in which order, and after that the one this document cannot make for you. Whether the next round of testing should re-check the findings you already have or start again with fresh scope. Retest or new audit works that through as a decision you can actually follow, and the answer turns on what changed rather than on how long it has been.