A report that opens with the work, not a score
Every scan produces a ranked list of code changes, ordered by how many issues each one clears, with running totals so you can see where the work stops paying before anyone opens an editor.
Scan a public URL free · no credit card required
color-contrastlink-nameimage-altIllustrative
- Ranked by reach
- issues cleared first, not severity
- Running totals
- a count and a share on every row
- Dominant selector
- one file or forty, before you estimate
- Stable order
- the same scan, the same order, every run
How the plan is ordered
Four criteria, applied in order. The first three are about impact; the fourth exists only so the list is stable. Each one is reached only when everything above it ties — which is why these four are numbered when almost nothing else here is.
- 1
How many issues the fix clears
The primary sort. Every issue produced by the same rule is one entry, because they are almost always one change. The fix at the top of your plan is the one that removes the most barriers per unit of work.
- 2
Severity, as the tie-break
When two fixes clear the same number of issues, the more severe one goes first: critical, then serious, then moderate, then minor. Severity is never ignored — it is demoted from a sort key to a decider.
- 3
How many pages it touches
Still tied? The fault spread across more pages wins. A problem on every page of the site is more likely to be in a shared layout, and more likely to be reached by a real user on a real journey.
- 4
The rule id, so the order never moves
A final alphabetical tie-break on a stable key. Two runs of the same scan cannot present the same fixes in a different order, which matters as soon as more than one person is working from the list.
What each row in the plan carries
Enough to decide whether to do it, how long it will take, and what standard it satisfies.
How much it clears
The issue count for that fix, plus the running total of everything above it — as a count and as a share of the total. Read down the column and the plan becomes a budget: the point where the next fix clears two instead of forty is visible.
Where it concentrates
The selector the fault appears on most, and how many of the issues that one selector accounts for. When one selector dominates, the fault is a shared component and the fix is one file; when it is spread, the work is broader.
What it satisfies
The rule, its help text, its severity, and the WCAG success criterion it maps to. Enough to know what is wrong and what the standard requires.
One number tells you whether the fix is one file or forty
Alongside each fix, the plan names the selector the fault appears on most and how many of the issues it accounts for. Two fixes with the same issue count can be very different jobs.
e.g. 46 issues, 41 on one selector
The fault is coming from a component, and the fix is one file that happens to be rendered 41 times.
e.g. 46 issues, 46 different selectors
The same fault has been written by hand in 46 places, and that is a different afternoon.
Neither of those is visible from an issue list. Both are visible from one column, before anyone opens an editor.
Working a fix plan, end to end
- Step 1
Read down until the numbers flatten
The cumulative share usually climbs steeply for the first handful of rows and then crawls. Where it flattens is a natural scope line for the first pass — everything above it is cheap.
- Step 2
Check the dominant selector before estimating
A high selector concentration means a component fix; a low one means the work is spread. Two rows with identical issue counts can differ by an order of magnitude in effort, and this is where you find that out.
- Step 3
Fix, then re-run the same scan
Re-running the scan you already have — rather than creating a new one — is what gives you a comparison against the previous run: what you fixed, what you introduced, and what did not move.
- Step 4
Expect the plan to reorder, and read it again
Clearing the top fix changes which fix now has the most reach. The second pass is a new plan, not the remainder of the old one.
Frequently asked questions
Because reach is what decides the work, and a single code change usually clears every instance of a fault. One moderate problem repeated across forty elements and one serious problem on a single element are the same amount of typing — but the first removes forty barriers and the second removes one. Severity still matters: it is the tie-break when two fixes clear the same number of issues, ordered critical, serious, moderate, minor. This is not a severity queue — severity is shown on every row, so a critical fault that genuinely affects one element is still visible and you are free to do it first. The ranking is a recommendation, not a queue you are locked into.
Read the guide: Triaging accessibility issues by severity →Each row carries the cumulative number of issues cleared by that fix and everything above it, as a count and as a share of the total. That is what lets a report say something like 'three fixes clear 47 of your 61 problems' — and, just as usefully, show you the point where the next fix clears two. It turns a shapeless backlog into a scope you can argue for, with a visible point where the work stops paying and becomes a long tail.
The plan names the most common selector for each fault and how many times that selector accounts for the issue. When one selector dominates, the fault is coming from a shared component and the fix is one file. When the selector count is low relative to the issue count, the same fault is scattered across different markup and the fix is broader.
Yes. After issue count, severity and page count, the final tie-break is the rule id, so two runs of the same scan can never present the same fixes in a different order. A plan that reshuffled between runs would be impossible to work through as a team.
No. Each row carries the rule's description and help text, its severity and the WCAG criterion it maps to — enough to know what is wrong and what the standard requires. It is not a patch: nothing here writes code for you or guesses at your framework. And it is not a substitute for a person — keyboard journeys, focus order through a real flow and screen-reader output are judgements no ranked list replaces.
No. Clearing every row means an automated engine has no more findings, and that is not a conformance statement. An automated engine reaches under half of WCAG at all — the criteria it cannot judge are reported as not checked rather than passed, and were never in the plan because they were never measured. Pair it with manual testing.
Related
- Progress Over TimeWhat each run fixed, introduced, and left unchanged
- Scheduled ScansDaily, weekly or monthly runs in your own timezone
- WCAG 2.2 CoverageWhat automated rules reach, and what is marked not checked
- All of AccessibilityAutomated WCAG scanning, workflow audits, and reports
- PricingPer-seat test management and per-thread device testing, priced on the page
See what three changes would clear on your site
Scan a public URL and read the plan it produces. No credit card, no sales call.