How to Read an Accessibility Scan Report

To read a scan report, start with the summary counts, then move into the issue list where each entry shows the WCAG success criterion, severity, page location, the…

To read a scan report, start with the summary counts, then move into the issue list where each entry shows the WCAG success criterion, severity, page location, the element involved, and a short description. The summary tells you the scope of what was checked. The issue list tells you what the scanner detected on those pages.

Reading a scan report well means understanding what each field represents and what the report does not cover, since scans only flag approximately 25% of accessibility issues.

Scan Report Reading at a Glance
Field What It Tells You
Summary counts Total issues detected, pages scanned, and severity breakdown.
WCAG reference The success criterion the issue maps to, such as 1.1.1 or 2.4.4.
Severity The scanner’s confidence and estimated user impact for the issue.
Element and location The HTML element, selector, and page URL where the issue was detected.
Coverage limit Scans detect about 25% of accessibility issues. The rest requires manual evaluation.

Start With the Summary

The top of a scan report shows aggregate numbers: how many pages were scanned, how many issues were detected, and how those issues break down by severity or WCAG criterion. Use this section to set expectations before opening individual entries.

If the summary shows a low issue count, that does not mean the site is accessible. It means the scanner did not detect many issues within the 25% of WCAG criteria it can evaluate programmatically. The other 75% sits outside the scan entirely.

Read Each Issue Entry

Every flagged issue typically includes a WCAG success criterion reference, a severity rating, the element involved, the page URL, and a short description of what the scanner detected. Some reports also include suggested remediation guidance.

The WCAG reference points you to the specific success criterion under 2.1 AA or 2.2 AA. The severity rating reflects the scanner’s confidence and the estimated user impact. The element and location tell a developer where to look in the code.

Understand Severity Ratings

Severity in a scan report is not a universal standard. Each scanner uses its own model, often combining detection confidence with estimated user impact. A high severity entry usually means the scanner is confident the issue exists and that it materially affects users of assistive technology.

Lower severity entries often include items the scanner suspects but cannot confirm. These need human review. Treat severity as a starting point for prioritization, not a final answer.

Watch for False Positives and Needs Review Items

Scanners flag some items as needing review rather than as confirmed issues. These entries require a person to evaluate the context, since the scanner could not determine the answer on its own. Skipping these entries is a common mistake when reading a scan report.

False positives also appear. An element may be flagged that, in context, presents no actual accessibility issue. Verifying flagged items against the live page is part of reading the report accurately.

Map Issues Back to the Page

Each entry includes a page URL and an element selector. Open the page, locate the element, and confirm the issue exists as described. This step turns the report from a list of abstractions into actionable information for developers.

Grouping issues by page or by template helps identify systemic patterns. A single header component used across the site can produce the same issue on every page, and fixing the component resolves all of those entries at once.

Recognize What the Report Does Not Cover

A scan report only contains what the scanner can detect programmatically. It does not cover meaningful alt text quality, the logic of heading structure, keyboard focus order through complex widgets, screen reader announcement accuracy, or whether form errors are communicated clearly. These require manual evaluation.

Reading a scan report well means knowing where it ends. The report is one input into a broader conformance picture that includes audits, screen reader testing, and keyboard testing. For more on how scan output translates into deliverables, see the accessibility scan reports overview.

A scan report is most useful when read as a starting point. The numbers and entries tell you what the scanner saw. What happens next, including verification, prioritization, and remediation, depends on human judgment.