What Should Be in an Accessibility Audit Report? A Buyer’s Checklist
Quick answer: A rigorous accessibility audit report should state a specific WCAG version and conformance level it was tested against, cover more than isolated pages — including a complete process like your actual checkout flow, not just a product page in isolation — combine automated scanning with manual testing (the W3C’s own evaluation methodology is explicit that “most accessibility checks are not fully automatable”), document specific findings you can act on rather than a bare pass/fail score, and stop short of claiming a certification that doesn’t exist. If a report you were sold — by anyone, not just Quietramp — is missing more than one of these, that’s worth asking about before you trust its conclusions.
This article is general accessibility information, not legal advice. Meeting WCAG 2.1 or 2.2 AA is a technical-practice standard, not a legal determination — consult qualified counsel for legal risk questions.
Where this checklist comes from
There’s a real, citable W3C document for how a WCAG evaluation is supposed to be conducted, not just what it’s supposed to test for: the WCAG Evaluation Methodology (WCAG-EM) 2.0. Its own Abstract describes the scope directly: it “provides technology-agnostic guidance to define the evaluation scope, explore the target product, select a representative sample set from products, evaluate the selected sample set, and report the evaluation findings.” It’s a W3C Group Note, not a legal or certification standard — nobody “passes” WCAG-EM the way a page passes a single success criterion — but it’s the closest thing to an agreed-upon definition of what a non-superficial evaluation looks like, and it’s a useful yardstick for judging a report you didn’t write yourself.
1. It should name a specific WCAG version and conformance level
WCAG-EM’s own Step 1.2 requires evaluators to “select a target WCAG 2 conformance level (A, AA, or AAA) for the evaluation,” and adds a direct recommendation: “WCAG 2 Level AA is the generally accepted and recommended target.” A report that never states which version (2.1, 2.2) or level (A, AA, AAA) it tested against is making a vague claim that can’t actually be checked against anything. “Your site has accessibility issues” isn’t a finding — “this page fails SC 1.1.1 Level A because this product image has no alt text” is.
2. It should test a real process, not just a stack of disconnected pages
This is the part most templated or automated-only reports skip, and it’s the part WCAG-EM treats as a requirement, not a nice-to-have. Step 3.3, “Include complete processes,” states that “the selected sample set has to include all pages or views that belong to a series presenting a complete process” — and its own worked example is, almost word for word, a checkout flow: “for a web shop application, the user would proceed to checkout, confirm the default payment option, provide all required payment details correctly, and complete” the process. That’s not an e-commerce-specific adaptation of the methodology — it’s the methodology’s own chosen illustration of what “complete process” means.
The reason this matters in practice: a product page can pass every automated check in isolation while the path through cart, shipping-method selection, and payment still contains a keyboard trap, a missing error announcement, or a focus-order break that only shows up when a real person tries to walk the whole flow start to finish. A report that only lists per-page findings — home page, one product page, contact page — without ever completing a checkout as part of the review has skipped the one journey most likely to lose you a sale if it’s broken. If you’re evaluating a report, ask directly: did the reviewer actually place an order (or get to the final confirmation step) as part of testing it?
3. It should combine automated scanning with manual testing
WCAG-EM’s Evaluation tools section is direct about this, and it’s worth quoting exactly because it’s easy to either overstate or understate what a scanner does: “While most accessibility checks are not fully automatable, evaluation tools can significantly assist evaluators during the evaluation process and contribute to more effective evaluation.” Neither half of that sentence is optional. A scan-only report will structurally miss most of what actually breaks a flow for a real user — our piece on what automated scanners miss covers that gap in detail. But a report with no automated component at all is usually slower and less consistent than it needs to be; the tools are there to help a reviewer cover more ground, not to be skipped out of purism.
The related idea worth checking for: WCAG-EM’s “Required expertise” section assumes an evaluator (or a team with “combined expertise”) understands “accessibility barriers that people with disabilities experience” and “assistive technologies and adaptive approaches that people with disabilities use” — in plain terms, someone who has actually used a screen reader and a keyboard-only workflow to test with, not someone reading a rule-engine’s output cold.
4. It should document specific, actionable findings
Step 5.1 of the methodology requires evaluators to “document each outcome of the steps” for “transparency, replicability of the evaluation results and justifications for any statements made based on this evaluation.” Applied to a report you can actually use: a finding should say which element or component failed, which success criterion it failed, and (for a report meant to be acted on rather than just filed) what the fix looks like. A single aggregate score or a percentage without the underlying findings attached doesn’t give a developer anywhere to start, and it doesn’t give you a way to check the reviewer’s work.
5. It should not claim a certification that doesn’t exist
WCAG-EM produces an evaluation against a stated scope and conformance target on a given date — it does not produce a permanent, transferable credential, and there’s no official “WCAG certified” or “ADA certified” status a site can earn from any body, W3C included. A report (or a sales pitch) that uses language like “certified compliant” or “guaranteed ADA compliant” is overstating what any evaluation — done by anyone, using any methodology — can actually claim. A properly scoped report says what was tested, against what target, and when; it doesn’t promise legal immunity, because accessibility conformance and legal compliance are different questions, and only one of them is something a technical evaluation can speak to.
A quick way to sanity-check a report you already have
If you’ve already paid for an audit — from Quietramp or anyone else — and want to check whether it holds up, look for these five things directly in the document: a named WCAG version/level, evidence that a real multi-step process (not just isolated pages) was walked through, a mix of scan output and manual observations rather than one or the other alone, findings specific enough that a developer could act on them without guessing, and language that stops at “here’s what we found,” not “here’s your certificate.”
FAQ
Does a WCAG-EM-style evaluation replace the need for a legal opinion? No. WCAG-EM itself only produces a technical conformance evaluation against a stated target — it says nothing about legal risk under the ADA or any other law. Those are separate questions with separate experts.
Is WCAG-EM itself a requirement I have to follow? No — it’s a W3C Group Note (informative guidance), not a normative standard, and no law requires a specific evaluation methodology. It’s referenced here because it’s a real, public description of what a rigorous evaluation looks like, useful as a comparison point, not because sites are required to use it.
Get a report built this way, not a rescored scan
Quietramp’s audits are built around the same shape this checklist describes: a stated WCAG 2.1 AA target, a full walk-through of real flows (including checkout, not just the homepage), automated scanning paired with a manual keyboard-and-screen-reader review, and specific, developer-actionable findings — delivered as a prioritized PDF, not a percentage score. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This is educational content about technical accessibility practice, not legal advice. Meeting WCAG 2.1 or 2.2 AA does not constitute a legal compliance determination under the ADA or any other law, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.