Accessibility Regression Rate: Counting the Issues Your Releases Create

2026-10-27

Most accessibility dashboards celebrate issues closed. Almost none track issues opened by the team's own releases, which is why so many programs run hard for a year and end up roughly where they started, minus the easy fixes.

Regression rate is the metric that exposes this. It reframes accessibility from a cleanup project into a quality property of the release process, where it has to live if it is going to survive.

Separating new issues from legacy debt

Every finding needs an origin label: pre existing on an untouched page, introduced by a change, or revealed by better testing of something old. The third category matters, because a new audit method can make regression look worse while the site is actually unchanged.

The cleanest method is a frozen baseline. Audit a fixed sample of templates and journeys, store the results, and diff every later audit against it. Issues appearing in previously clean components are regressions by definition, with no arguments about archaeology.

Normalising the rate so it means something

Raw counts mislead across releases of different sizes. Report regressions per release and per significant component change, and show the trend line rather than any single number. A big redesign will spike the rate; the question is whether it returns to near zero and stays there.

Severity weighting keeps the metric honest. A release that introduces one checkout blocking regression is worse than one that introduces five cosmetic contrast nits, and the dashboard should say so plainly.

Why regressions happen

The causes are mundane: a third party widget update, a redesigned component built without the old accessibility requirements, a marketing page cloned from an unremediated template, an A/B test variant that skipped review.

Notice that none of these are knowledge problems. They are process gaps where accessibility checks live outside the path changes travel. Regression data, plotted by cause, shows exactly which gap to close next, which is the metric's real job.

Driving the rate toward zero

The effective levers are few and known: accessibility acceptance criteria inside component tickets, automated checks in the build for the mechanical rules, a keyboard and focus pass for interactive changes, and a rule that test variants inherit the accessibility review of their parent page.

Celebrate zero regression releases publicly. Teams repeat what gets noticed, and a streak is a surprisingly powerful motivator for keeping the checks in place when deadlines argue otherwise.

Frequently asked questions

How is regression rate different from total open issues?

Open issues measure the size of the debt. Regression rate measures whether you are still borrowing. Both matter, but only the rate tells you whether the fix program can ever finish.

What is a good accessibility regression rate?

Zero new critical or serious issues per release is the credible target for mature teams. Early programs should expect a visible rate and judge themselves on the downward trend and the speed of fixing what slips through.

Who should own the regression metric?

Product or engineering leadership, not the accessibility specialist alone. Regressions are created by the release process, so the owner must be whoever can change that process. The specialist measures and explains; leadership removes causes.

Can automated testing catch regressions by itself?

It catches the mechanical share, often a third or so of issue types, and it catches them cheaply at build time. Interactive and judgement based regressions still need manual passes, so automation is a floor, not the measurement.