Summary & Score

The Summary tab answers one question first: what should you fix, and in what order. The environment the scan ran on — the real Device Farm browser and OS, e.g. 151.0.7922.34 (Device Farm · Windows 11) — is shown in the report header along with the WCAG version the scan was measured against.

Run header

The band at the top of the report carries:

• The site and run number.
• What changed since the previous run — how many issues were fixed and how many are new, compared against the run before this one. A first run says so rather than showing zeroes. Two issues are treated as the same issue when their rule, page and element selector all match, which is the same comparison the History tab uses.
• The browser and platform the scan actually ran on.
• The WCAG version and level, read from the scan's own settings.
• The accessibility score, as a supporting figure rather than the headline.
• + N items to check by hand, when the checker found things it could not decide. See Confirmed problems and items to check by hand.

Fix plan

The main section of the report. Rules are ranked by how many issues each one clears, not by severity, and the heading states how few fixes cover most of the problem — for example, "3 fixes clear 47 of your 61 problems."

Reach is the ranking, because reach is what decides the work. One moderate fault repeated on forty elements is a single code change that clears forty issues; one serious fault on one element is a single code change that clears one. Where two fixes clear the same number, the more severe one ranks higher, then the one touching more pages, then rule id — so the ordering is stable between runs of the same scan.

Each row shows:

• The fault in plain words.
• How far it reaches: element count, page count, and the component responsible for most of it ("mostly button.cta, 28 of 40"). Selectors are shortened to their last element, so one bad reusable component reads as one row rather than forty.
• Severity, written as a word as well as coloured.
• The WCAG criterion the fix satisfies.
• Expand a row for axe-core's guidance on how to fix it.

Only confirmed problems appear here. Items to check by hand are left out, because nobody can be told to fix something the checker was not sure about.

Reports saved from the Chrome Toolkit get a fix plan too, the same as Website Scanner reports.

Confirmed problems and items to check by hand

Every report splits what the checker found into two groups:

• Confirmed problems — the checker is sure these are broken. These are the problems the report counts, and the fix plan is built from them.
• To check by hand — the checker could not decide. A person needs to look. These are not counted as problems.

Some examples of items to check by hand:

• Text on top of an image or overlay, so the background colour can't be measured.
• A label on an element that screen readers often ignore.
• A menu that only exists once it is opened.

You find them in a folded section, To check by hand (N), at the bottom of the All Issues tab. The top of the report also shows + N items to check by hand. Other accessibility tools list items like these for manual checking too.

Where you stand

This section shows every criterion in your WCAG level, for example all 50 in WCAG 2.1 AA. Each one lands in one of four boxes, so the four numbers always add up to the total:

Click See list under a number to see which criteria are in that box. Each one links to its official W3C page. Click the ⓘ next to Can't be tested by tools for a short explanation. The Failing list is open when the report loads.

Automated tools can check only about half of WCAG. The checker we use has rules for 29 criteria in total, so for WCAG 2.1 AA, 27 criteria are always in Can't be tested by tools.

What we checked

Pages scanned with their individual scores and issue counts, the browser used, and the number of issues your team has hidden. Hiding an issue removes it from the score, so this count is how you explain a score that looks better than the issue list suggests. See Hiding an issue.

Accessibility score (0–100)

A composite across all scanned URLs, higher is better. It is a weighted rule ratio, not an issue count:

score = weighted passed rules / (weighted passed rules + weighted failed rules) × 100

Passing a rule earns 10 / 7 / 3 / 1 points (critical / serious / moderate / minor); failing one costs 20 / 14 / 6 / 2 — failures weigh double.

Because the unit is the rule, a rule that fails on 500 elements costs exactly what it costs when it fails once. Use the fix plan to judge volume. A scan where no rules ran at all scores 100.

The score is recalculated every time the report is opened and written back to the scan. That is why hiding an issue changes the number without a re-scan. It also means the score on the scan list can lag the report by one visit.

Rough reading of the number:

• 90–100 — conformant or near-conformant with your chosen WCAG target.
• 70–89 — a few serious or moderate issues. Usually fixable in a single pass.
• 50–69 — significant gaps across several rules.
• Below 50 — systemic gaps; prioritize critical and serious findings first.

The score is a guide, not a compliance verdict, and it says nothing at all about the criteria no tool can check. Conformance claims should reference the WCAG conformance matrix, not the score.

Breakdowns

Collapsed by default, below the sections above:

• Problems by severity — a donut with a legend giving the count per severity.

  Severity	What it means
  Critical	Blocks users with disabilities from core functionality
  Serious	Major barrier; most users affected can work around it with effort
  Moderate	Usability issue; shouldn't block
  Minor	Polish item; rarely user-blocking

• Rules by severity — passed, failed and effect on score per severity level. The effect column is the negative weighted failure count for that severity, not a percentage.

• Issues by category — all thirteen rule categories (Color, Text Alternative, Keyboard, Aria, Forms, Time & Media, Structure, Semantics, Tables, Name, Role, Value, Sensory & Visual Cues, Language, Parsing), each with a proportional bar, sorted highest first. Categories with no issues are still listed, at 0.

• Components with the most problems — DOM selectors that appear repeatedly across issues, shortened and summed so one bad component is one row. The full CSS path and HTML snippet are on the issue detail panel. Shows at most the top 100 selectors.

To filter by severity, switch to the All Issues tab and use the All Severity dropdown. Full definitions: Severity levels.

What's not in the summary

• Per-element details — those live in the issue detail panel. See Issue details.
• Run history — score-over-time and version comparison are on the report's History tab. The header's since-last-run line is a summary of the most recent comparison only.

Related

• Issue details
• WCAG conformance matrix
• Severity levels