A provider that actually reviews scan output will explain which flagged items are real issues, which are noise, and what a human evaluator would catch that the scan missed. A provider that does not review their own output will hand you a PDF that looks like it came straight from a tool, with no annotations, no severity context, and no acknowledgment that scans only flag approximately 25% of issues. The difference shows up in the report itself, in how the provider talks about scope, and in whether they can answer specific questions about a finding without going back to the tool.
This matters because scan output without review is close to worthless for serious decision-making. False positives waste developer time. Missed issues create legal and user experience risk. If you are paying for a service, you are paying for the human judgment layered on top of the tool, not the tool’s raw export.
| Signal | What It Looks Like |
|---|---|
| False positive filtering | The report removes or annotates findings that the tool flagged but a person verified as non-issues. |
| Severity context | Each finding has an impact rating tied to real user effect, not the tool’s default label. |
| Scan limitation disclosure | The provider states upfront that scans only flag approximately 25% of issues. |
| Specific remediation guidance | Fix recommendations are written for your code, not pasted from tool documentation. |
| Verbal recall | The provider can discuss specific findings without pulling up the tool dashboard. |
What unreviewed scan output looks like
Unreviewed output has a recognizable shape. It tends to be long. Every flagged item from the tool is listed, including duplicates, including items that are not actually issues, including items that apply to a single template repeated across hundreds of pages. The total issue count is inflated because nothing was filtered.
The language is generic. Each finding reads like it was copy-pasted from the tool’s reference library. There is no mention of how the issue presents on your specific site or how a screen reader user would encounter it.
Severity ratings, if they exist, mirror the tool’s defaults. Everything is critical, or nothing is. There is no prioritization tied to user impact or business risk.
How can you tell during a sales conversation?
Ask the provider to walk you through a sample report. Not a brochure. A real report from a real client, redacted if needed. Then ask specific questions about specific findings. “Why is this rated medium severity? What would happen if a user with low vision hit this page?”
A provider who reviews their output can answer without hesitation. They wrote the rating. They know the reasoning. A provider who forwards tool output will hedge, paraphrase the tool’s description, or change the subject.
Another useful question: “What did your scan flag that you decided was not actually an issue?” If the answer is none, or the provider looks confused by the question, the review layer probably does not exist.
The scope question
Scans cover a narrow slice of WCAG criteria. A reviewing provider will tell you what their scan covers and, more importantly, what it does not cover. Keyboard traps, focus management, meaningful alt text, form error recovery, screen reader announcements, contrast on text inside images, and many other criteria require a human evaluator.
If a provider implies their scan covers all of WCAG 2.1 AA, that is a tell. It does not. No scan does. A provider who has actually reviewed scan output knows this from experience and will say so.
What real review adds to a scan
Review turns raw output into something a developer can act on. The reviewer verifies each finding against the live page, removes false positives, consolidates duplicates, writes context for the development team, and flags items the scan missed entirely.
For most digital assets, the reviewed version of a scan is shorter than the raw export but more useful. Fewer items, each one real, each one explained. This is the work that separates a service from a tool subscription.
Where scans fit in the broader picture
Scans are useful for monitoring and for surfacing the issues they can detect. They are not a substitute for a manual accessibility evaluation, which is the only way to determine WCAG conformance. A provider who positions scan output as a conformance assessment is misleading you, intentionally or not.
The honest framing: scans catch a portion of issues quickly and at low cost, and a manual evaluation identifies the rest. A provider that reviews scan output will explain this distinction without prompting.
Red flags in the report itself
Open any sample report and look for these specific signs of an unreviewed export. The provider’s logo on the cover but the tool’s branding inside. Identical finding descriptions repeated across many entries. No executive summary or one that reads like marketing copy. Page counts and issue counts that do not match the site’s actual structure. Remediation advice that references generic HTML rather than your codebase. No mention of which WCAG success criteria were not evaluated.
One or two of these can happen in a rushed report. All of them together mean the report was generated, not written.
FAQ
How do I confirm a provider reviews scan output before signing a contract?
Request a redacted sample report and a 20 minute call to discuss it. Ask the provider to explain three specific findings, including the severity reasoning and the recommended fix. A provider who reviews their output will speak fluently about the findings. A provider who forwards tool output will struggle. This single conversation tells you more than any sales deck.
Is a reviewed scan report enough for WCAG conformance?
No. A scan report, even a thoroughly reviewed one, covers only the criteria a scan can detect, which is approximately 25% of WCAG issues. A manual accessibility evaluation conducted by a trained evaluator is needed to assess conformance against the full standard. Reviewed scans are valuable for monitoring between evaluations and for catching regressions, but they do not stand in for the evaluation itself.
What should a reviewed scan report cost compared to a raw export?
Raw scan output is often free or bundled with a tool subscription. Reviewed scan reports cost more because they include human evaluation hours. Pricing varies by site size and provider, but expect a meaningful difference. If a provider is charging evaluation-level prices for what looks like raw tool output, that is worth questioning directly.
Can I review scan output myself instead of paying a provider?
You can, if you have the training to recognize false positives, judge severity, and write remediation guidance your developers can use. Most teams do not have that training in-house, which is why providers exist. The value of paying a provider is the review work, not the scan itself.
If a provider cannot show you their review work, they probably are not doing it. The report is the proof.
Contact us to find accessibility professionals who review their own work: Contact AccessibilityBase.