Skip to content
wcagc
←Back to blog
evidenceWCAGEN 301 549honesty

How to read an accessibility scan report

What the numbers in an accessibility scan report mean, why a score is not conformance, and which findings still need a person to confirm.

P

Pavel Charkasau

An accessibility scan report is a list of machine-detected failures on the pages you pointed a tool at. Read it in this order: the scope (which URLs, which date, which tool version), the failures the tool decided confidently, the items it flagged for review, and then the large area it never looked at. The number at the top is the least useful part of the file. A scan tells you what a rule set could decide. WCAG conformance is a different question, answered per page and in full, and "one of the following levels of conformance is met in full" is how the specification puts it (W3C). The W3C's own guidance on tooling is blunt about the gap: "Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so" (W3C WAI). So the useful reading of an accessibility scan report isn't "how bad is my score". It's three questions: what did this tool decide, what did it refuse to decide, and what was never in its remit at all.

What is actually in an accessibility scan report?

Four parts, though most report screens put two of them in front of you and bury the rest.

  • Scope. The URL list, the timestamp, the tool and its version, and the standard and level tested. If a report doesn't state these, you cannot compare it to the next one.
  • Violations. Each one should carry a rule identifier (color-contrast, label, link-name), the success criterion it maps to, a CSS selector, and the failing HTML snippet. A finding without a selector is a rumour.
  • Items needing review. In axe-core these land in a separate incomplete array, which the documentation describes as results that "could neither be determined to definitively pass or definitively fail. They are separated out in order that a user interface can display these to the user for manual review" (Deque).
  • What was never tested. Everything outside the rule set. No report has a section for this, which is exactly why it gets forgotten.

Start with the scope. I have watched teams argue for half an hour about a violation count while nobody in the room could say how many pages were scanned or on what date. If the answer is "the homepage, some time in August", the rest of the discussion is guesswork.

What do the severity labels mean?

They rank likely user impact. They say nothing about your legal position.

axe-core attaches an impact value to each failed rule, which "can be one of 'minor', 'moderate', 'serious', or 'critical'" (Deque). That scale is the tool's own. WCAG has no severity axis. It has conformance levels A, AA and AAA, and inside a level each success criterion is either satisfied or it is not. A rule your scanner marks "moderate" can be the thing that breaks a Level A criterion, and a "critical" contrast failure on a decorative footer link may take you ten seconds to fix.

Use severity to order the repair queue. Do not use it to estimate how close you are to conforming, because the two scales measure different things.

Why isn't an accessibility score the same as conformance?

Because WCAG never defines a score, and the shape of its conformance rules makes averaging meaningless.

Three requirements from the specification do the work here (W3C):

RequirementWhat it says
5.2.1 Conformance Level"One of the following levels of conformance is met in full."
5.2.2 Full pages"Conformance (and conformance level) is for full web page(s) only, and cannot be achieved if part of a web page is excluded."
5.2.3 Complete processesWhen a page is one of a series presenting a process, "all web pages in the process conform at the specified level or better."

The specification's own example for 5.2.3 is a store: "All pages in the series from start to finish (checkout) conform in order for any page that is part of the process to conform." Read that next to a dashboard showing 96% across 40 pages. If the payment step fails a Level A criterion, the process does not conform, and the 96% describes nothing a reviewer can use. Averages hide exactly the failure that decides the outcome.

This is the one place I will state a product opinion outright: we do not show an aggregate accessibility score anywhere in our product, and that was a deliberate call. Our conformance engine resolves each EN 301 549 clause into one of four buckets, and the asymmetry is the point. A detected failure moves a clause to not met on its own. Only a recorded human pass can move a clause to met, because clean automated output is not a satisfied requirement. Clauses with no signal stay not assessed instead of quietly counting as wins. A single percentage would have destroyed all of that information, and it would have sold better.

What does "needs review" mean in an accessibility scan report?

It means the tool found something it could not decide, and it is handing you the decision.

The W3C's Accessibility Conformance Testing format gives this outcome a name. A rule evaluates to one of five results: inapplicable, passed, failed, cantTell ("whether the rule is applicable, or whether all expectations were met could not be fully determined by the tester") and untested (W3C). Most report interfaces collapse cantTell into a muted "needs review" tab that nobody opens.

Open it. A cantTell on a video element is asking whether the captions are accurate, and a person answers that in two minutes. Left alone, it stays unanswered for a year and your file has a hole in it precisely where a reviewer will look.

What can a scan report never tell you?

That you conform. Not because scanners are bad, but because passing a test is not the same claim as satisfying a criterion.

The W3C says it plainly: "when content passes Test Rules, it means that no corresponding failures were detected — it does not necessarily mean that the content satisfies all aspects of the corresponding success criteria", and "checking that content satisfies all aspects of WCAG 2 success criteria typically requires further verification by human testers" (W3C WAI). Failures are decidable by machine. Satisfaction usually isn't.

The size of the gap is measurable. Deque's 2021 analysis of more than 2,000 audits covering over 13,000 pages and nearly 300,000 issues found that automated testing completely covered about 57% of issues by volume (Deque). Counted by success criteria instead of issue volume the share drops, which is where the honest 30 to 57% range comes from. The WebAIM Million supports the same picture from the other direction: in February 2026 it found detected WCAG 2 failures on 95.9% of home pages, at an average of 56.1 errors per page, and six error types accounted for 96% of everything detected (WebAIM). Those six are the machine-friendly ones. Low contrast, missing alt text, unlabelled inputs and empty links dominate the counts because they are the failures a rule can prove.

Here is what stays outside the report on a typical page. Whether the alt text on your product photo describes the thing a buyer needs to know. Whether the focus order through your filter panel matches what a sighted user sees. Whether the inline error on a declined card is announced to a screen reader at the moment it appears, or silently rendered fifty pixels below the button. Our scanner will not answer any of those. You need a person, a keyboard and a screen reader, and that hour is not optional if you intend to make a conformance claim.

How do you turn the report into something a reviewer will accept?

Stop treating the output as the deliverable and start mapping it onto clauses.

EN 301 549 shows the target format. Annex C is normative and "sets out the means necessary to determine conformance with the individual requirements set out in the body of the present document" (Accessibility Standards Canada, reproducing EN 301 549). Every procedure states its pre-conditions, the steps, and a result that resolves to pass, fail or not applicable. Three outcomes per requirement, each with a stated basis. An auditor can follow that. A violation count with no date on it, they cannot.

So the working version of your report has four columns per requirement: the automated result, the review items still open, the human verdict with a name and a date, and what you did next. That file is what an accessibility statement rests on, since a statement documents the effort you made and the limitations you know about, not a guarantee. It is also what a European Accessibility Act reviewer is asking for when they ask how you reached a verdict. If you want a manual checklist to sit beside the scan output, our WCAG checklist covers the criteria a scanner leaves undecided.

FAQ

Is a high accessibility score good enough for compliance?

No, because WCAG has no score. Conformance is claimed per page at a level that is "met in full", and every page in a process has to reach the same level (W3C). A 98% dashboard with a failing checkout step describes a process that does not conform.

What does "needs review" mean in an accessibility scan report?

It means the rule returned cantTell: the tool could not fully determine whether the rule applied or whether its expectations were met (W3C). Those items are questions addressed to you, and they stay open until a person answers them.

How many pages should a scan cover?

Enough to include every step of your revenue and support processes, not just the templates. WCAG conformance covers complete processes from start to checkout (W3C), so a scan that stops at the pages available to logged-out visitors leaves the riskiest screens untested.

Can a scan report be used as compliance evidence?

Part of it can. The raw findings with selectors, the scope, the date and the tool version are all evidence. The score is not, and neither is a clean automated run on its own, since detecting no failures is not the same as satisfying a criterion (W3C WAI).

Why do two scanners give different numbers for the same page?

Different rule sets, different versions, and different choices about what to report as needing review rather than as a failure. This is why the tool name and version belong in the scope block, and why comparing last quarter's count against this quarter's only works when both ran the same rules.

Run a scan you can actually read

Paste a URL into our free scan and you get the findings with the rule, the mapped success criterion and the exact selector for each one, the review items kept separate rather than hidden, and no score pretending to be a verdict. Automated checks find issues; a conformance claim still needs human review behind it.

Pavel Charkasau, founder, wcagc.com Last updated: 19 September 2026

Sources