How to read an accessibility scan report
An automated accessibility report can look overwhelming when you first open it. Dozens of findings, WCAG criterion numbers, technical descriptions, and code examples -- it is not obvious where to start or what any of it means for your store. This guide explains the structure of a scan report, what each section tells you, and how to turn the findings into a concrete task list that your developer can act on.
What automated scanning covers
Before reading any specific findings, it helps to understand what automated scanning does and does not catch. Tools like axe-core (which powers most commercial accessibility scanners, including ours) test for the WCAG violations that can be detected programmatically: a missing label on a form field, an image with no alt text, a button with no accessible name, a color combination that fails the 4.5:1 contrast threshold.
Automated scanning consistently covers the barrier types that appear most often in ADA web enforcement activity. It does not cover everything -- things like whether the reading order makes logical sense when a screen reader follows it, or whether interactive patterns work correctly under real-world assistive technology, require manual testing. A well-run scan will tell you this honestly. Ours says "covers the majority of litigated barrier types" because that is accurate; reports that say "fully WCAG compliant" or "ADA compliant" after an automated scan are overclaiming.
Severity levels
Every finding in a scan report has a severity level. The levels mean specific things, not just "how bad is this generally."
| Level | What it means | Example |
|---|---|---|
| Critical | Violates a WCAG success criterion in a way that completely blocks a class of users from using the affected element. The element cannot be operated or its content cannot be perceived by affected users at all. | A button with no text and no aria-label. Screen reader users hear nothing and cannot identify or activate the button. |
| Serious | Violates a WCAG success criterion in a way that creates a significant barrier. The element may still be usable through workarounds, but the barrier is substantial enough to cause failure in realistic use. | A form field with no label. The field can still be reached by keyboard (Tab), but screen reader users cannot tell what the field is for. |
| Moderate | Violates a WCAG success criterion but the impact is limited to certain assistive technologies or configurations. Some users are blocked; many are not. | An image with a redundant alt text (alt="image of product" when the product name is already in adjacent text). Screen readers announce the redundant description, which is noisy but not blocking. |
| Minor | A best-practice deviation that is not a strict WCAG violation but affects usability for some users. Often good to fix but rarely the priority. | An HTML landmark region present in the accessibility tree but not labeled (a second <nav> without an aria-label to distinguish it from the first). |
Most enforcement attention focuses on critical and serious findings. Those are the right place to start.
WCAG criterion numbers
Every finding will reference a WCAG success criterion by number: things like 1.1.1, 4.1.2, 2.4.3. These numbers follow a consistent pattern: the first digit is the principle (1=Perceivable, 2=Operable, 3=Understandable, 4=Robust), the second is the guideline within that principle, and the third is the specific criterion.
You do not need to memorize the full WCAG spec. The finding's title and description in the report tell you what the specific issue is. The criterion number tells you which part of the WCAG framework it falls under if you want to look it up. A few numbers come up so often in e-commerce scans that it is worth knowing what they mean:
- 1.1.1 Non-text content: Images, icons, and other non-text elements must have a text alternative. This is the rule that generates "image has no alt text" findings.
- 1.4.3 Contrast (Minimum): Text must have at least 4.5:1 contrast against its background (3:1 for large text 18pt+ or 14pt bold). This generates color contrast findings.
- 2.4.3 Focus Order: If a page can be navigated sequentially, the focus order must preserve meaning and operability. This catches keyboard traps and focus management failures.
- 4.1.2 Name, Role, Value: Every user interface component must have an accessible name, role, and state. This is the rule behind unlabeled button, unlabeled form field, and ARIA role structure findings -- the most common barrier type we see on e-commerce sites.
Components vs. instances
A report will distinguish between unique components and total instances of a finding. This distinction matters for prioritizing work.
A single component failure can produce dozens of instances. If a product image template is missing alt text, and your store has 200 products, the scanner will report one component (the image template pattern) with 200 instances (one per product). Fixing the template once fixes all 200 instances -- a single fix with high leverage. Conversely, a finding with 3 instances might span 3 entirely different components on 3 different page types, each requiring a separate fix.
When you see a high instance count on a finding, look at whether the instances come from one repeated component. If they do, the fix is one template change, not 200 individual edits.
The code example section
Good accessibility reports include a code example for each finding type: usually a "before" showing what the scanner found and an "after" showing what the fix looks like. These examples are drawn from what the scanner saw on your actual pages -- they are not generic textbook examples.
The code example gives your developer something concrete to match against the live code. The workflow is: developer opens the report, reads the finding title and code example, searches the codebase for the broken pattern, applies the fix, redeploys, reruns the scan to confirm the finding is gone.
Not every finding will map to a simple one-line fix. ARIA role structure errors and focus management failures often require JavaScript changes to a component, not just an HTML attribute addition. The fix guidance in the report describes the correct behavior; the implementation details depend on how the component is built.
How to prioritize
Not every finding needs to be fixed at the same time. A practical prioritization order for e-commerce stores:
- Critical findings on the purchase path: product pages, cart, and checkout. These are the pages where an accessibility barrier directly blocks a sale. Fix these first regardless of what else the report shows.
- Serious findings on the purchase path: same pages, lower but still significant barriers.
- Critical and serious findings on high-traffic pages: your homepage, main category pages, and any page that appears in the top 20 by session count. Traffic volume multiplies the impact of a barrier.
- Component-level fixes with high instance counts: template-level fixes (image alt text, button labels) that resolve many instances at once. The effort-to-impact ratio is favorable.
- Remaining critical and serious findings across other pages: work through these systematically.
- Moderate findings: address these in the same sprint as the serious ones above when the developer is already touching the affected component.
- Minor findings: useful as a cleanup pass, not as a priority.
The goal of the first pass is not a clean-slate report. It is removing the barriers that block people from buying on your highest-traffic pages. That is where automated accessibility monitoring delivers the most immediate business value.
What to do with the report
The most effective way to use a scan report is to export or extract the critical and serious findings, group them by page template or component, and create a developer task for each grouping with the report's code example attached. Findings that trace to the same template go in one task; findings on one-off custom components each get their own task.
After fixes are deployed, rerun the scan on the same pages. A monitoring subscription automates this: the scan runs on a schedule, compares each scan to the previous one, and sends a diff report showing what was fixed, what is new, and whether any regressions appeared. That removes the manual tracking overhead and gives you a record of progress over time.
If you received a BarrierScan report and want to discuss specific findings, reply to the email you received it in and describe which finding you want to clarify. We can explain what the scanner detected and what the fix involves before you send it to your developer.