Read the report before you buy it.

The other 20 findings, and everything else in a real report

A real Rapid Audit report carries the full set rather than a taste of it, and every item below arrives in the same shape as the three findings above.

• Every finding in the same format, so a rule, a severity, a screenshot, an element, and a fix
• All 55 WCAG 2.2 A/AA rules reviewed by a person, and every failure written up as a finding
• Screenshots captured from your own pages, dated to the day of the evaluation
• The browser and screen reader the evaluation was carried out with, and the technologies it relies on
• The blind tester's session notes on your key journeys
• Findings ordered by user impact, worst blockers first
• Each fix linked to its step-by-step guide, from the free library of 432
• Half-price re-audit within 3 months, when you are ready to verify

Reading it. How to read an accessibility audit report annotates this page line by line. What the header settles and what it leaves open, what the statuses mean, whose severity those chips carry, and how to group findings by cause before anybody starts assigning them. Once your team has worked the list, retest or new audit is the decision that comes next, and it turns on what changed rather than on how long it has been. If you are the person who has to work these findings rather than read them, what makes a finding developer-ready takes the same format apart field by field, and adds the acceptance test that lets a reviewer close a ticket honestly.

About this sample. The three findings above are illustrations built from the failures we meet most often, not from a client engagement, and they are ordered here to show three different kinds of problem rather than by severity. A real report is ordered by impact, worst blockers first. Your report documents your site only, and how each pass works is public too.

What the header does not say. “31 of 55 rules passing” is a summary across the ten pages tested, and WCAG defines conformance for a single web page rather than for a group of them, so read that line as a work summary rather than as a conformance claim. W3C's evaluation methodology is equally clear that a sample of a site cannot support a conformance claim for the whole site. What no tier buys you says the same thing before you pay rather than after, and gap analysis, audit or conformance evaluation sets out which depth of engagement produces which document.

And what the header cannot say. The evaluation runs on a desktop, so the report covers how those pages behave on a desktop. The standard counts each layout a responsive page presents at a different screen size as a variation that has to conform on its own, which means a failure that only appears on a narrow screen is outside the evidence above rather than absent from your site. Most findings hold at every width. That one caveat does not, and you should have it before you buy rather than after you read.

The rule-by-rule table, and what a filled one proves

An audit report's conformance table gives every rule a row of its own, and it is the part buyers ask about most and read least. So here are five of the 55 rows, written for the same imaginary shop as the findings above and invented in exactly the same way.

Four results, and only two of them are opinions about your site. A pass and a fail are findings, arrived at by looking. Not applicable means the rule found nothing to measure, which is why a page with no video cannot fail the captions rule and should not carry a red mark for it. Not tested means nobody looked, and that is the row worth your attention, because it is the one a careless report quietly rounds up into a pass.

Read the table with the header above it rather than on its own. Every result is scoped to the ten pages listed, on the date given, in the browser and screen reader named, and none of them says anything about the eleventh page or about next week's release. A table with all 55 rows filled in is a complete table, and completeness is a property of the document while conformance is a property of a web page. Filling in the first has never delivered the second, whatever the covering email says. What a conformance claim actually requires is the reference behind that distinction.

Before you go looking for this table in your own document. Whether the rule-by-rule table comes with the tier you bought is set out on the pricing page, in the row named for it, rather than settled here. Check that row before you order, because it is a cheaper conversation to have first.

What arrives, and in what file format

A web report you can open and link to, and a PDF of the same thing. That is what both paid tiers deliver, and it is the whole list until you add one of the separate documents underneath it.

The one worth knowing about before you plan a sprint is the developer ticket pack. It is the same findings transcribed once, properly, into a file your board imports, with reproduction steps and an acceptance test on every row. It finds nothing new, because it is transcription rather than testing, and that is the honest description of what you are paying for.

Then the formats that are not on this page, said out loud, because assuming one costs a fortnight. Nothing we send plugs into your tracker and keeps itself up to date, so the ticket pack is a file you import once rather than an integration you maintain. Any other shape, a version laid out to your own document template or a fill-in for a customer's questionnaire, is a thing to agree when we confirm scope rather than a thing to assume. If the questionnaire is the reason you are asking, a VPAT or ACR is a different document with different rules, and what those two words mean explains why an audit report is not one.