Why your first accessibility scan should set a baseline, not a grade

Run the first accessibility scan on almost any established store and the results look grim: hundreds of findings, a low score, a long list. The temptation is to argue with the scan, hide the score, or demand it be rerun until it looks better. All three waste the most valuable thing that first scan produces, which is a starting line.

A baseline is a measuring stick, not a verdict

A grade invites defensiveness. Nobody wants to forward a failing grade to their boss, so the grade gets debated, contextualized, and quietly buried. A baseline invites the opposite: it is simply where we started, documented on a date, with a method attached. There is no shame in a baseline because everyone understands that starting points are arbitrary. What matters is the direction of the line from that point forward.

This psychological difference is the whole game. Teams that start with a baseline talk about the trend: we are down 40 percent in critical findings since March. Teams that start with a grade talk about the grade: is 72 good? Should we be worried about 68? The first conversation drives work. The second drives meetings. Set the baseline deliberately, announce it as a baseline, and put the trend line where stakeholders can see it.

What a good baseline captures

A useful baseline is more than a single score. Record the finding counts by severity, the templates with the worst concentrations, and the top five repeating patterns. Repeating patterns matter most because they are the cheapest to fix: one template change can clear hundreds of findings at once. The baseline should also note what the scan covered and what it did not: which pages, whether authenticated flows were included, whether the checkout was tested. A baseline without a scope note becomes a misleading comparison the moment the scope changes.

Screenshot the worst pages too, or at least archive the reports. Six months later, when someone asks whether the program is working, the before-and-after is worth more than any chart. Accessibility progress is abstract until you can show the same page, then and now. The baseline is the then.

Resist the urge to clean up before the baseline

The most common baseline mistake is the pre-clean: fixing the easy issues before the first official scan so the starting number looks respectable. This feels prudent and is strategically backwards. Every issue fixed before the baseline is progress that can never be credited to the program. Worse, it teaches the organization that the number matters more than the work. Run the scan on the site as it is, ugly numbers and all, and let the trend line tell the story of the cleanup.

The one legitimate exception is broken scanning: if the crawler cannot reach the checkout or the scan configuration is wrong, fix the configuration, not the site, then baseline. The baseline should reflect the real site through a working scanner. Anything else is measuring the wrong thing precisely.

Turn the baseline into a cadence

A baseline with no follow-up scans is just a depressing PDF. The baseline earns its keep when the second, third, and twentieth scans land on a schedule and the trend gets reviewed by someone with authority to assign work. Monthly is the right cadence for most stores: frequent enough to catch regressions early, sparse enough that each report shows real movement. Tie the review to an existing ritual, a monthly engineering review or a quarterly business review, so it survives personnel changes.

Set the first target as a trend, not a threshold. Instead of reach 95 by Q2, try cut critical findings in half by Q2, then clear the top three repeating patterns by Q3. Trend targets keep the team honest when the site grows: adding two hundred new products will move the raw counts, but the pattern-based targets still show whether the underlying hygiene is improving. The baseline is day zero of that story. Make it an honest one, and the story writes itself.