Accessibility Regression Budgets: How Many New Issues Per Release Is Acceptable?

Zero new violations sounds noble and fails in practice. A regression budget gives teams a number they can actually hold.

Telling a product team 'introduce zero new accessibility violations' sounds principled and works exactly never. Templates change, third-party scripts inject markup, and content editors paste inaccessible embeds. A regression budget accepts reality: it sets a number the team can hold, makes violations visible, and turns accessibility from a veto into a managed metric. Here is how to set one that works.

Count what matters, not everything

A budget needs a unit. Raw violation counts are a bad unit because one broken template can emit hundreds of identical errors. Count distinct rule-plus-template pairs instead. That number moves only when something actually changed, which is what you want to budget.

Exclude third-party iframes from the budget but track them separately. You cannot hold your team accountable for a vendor's markup, but you should know it is there. Two numbers: first-party regression budget, third-party watch list.

Pick a number the team can defend

Start by measuring the current baseline over two weeks of normal releases. If the team introduces an average of three new distinct issues per release, setting the budget at zero guarantees failure and teaches everyone to ignore the budget. Set it at two, then ratchet down quarterly.

The budget applies per release, not per sprint, because releases are when code ships. Tie the check to the deploy pipeline so a release that exceeds the budget fails the same way a broken build does. Soft warnings get ignored. Gates get respected.

Decide what happens when the budget breaks

A budget without a consequence is a suggestion. The standard options: block the deploy until the count is back under budget, or allow the deploy but require a fix ticket in the next sprint with an owner. Blocking is stronger and appropriate for task-blocking rules like keyboard traps. The ticket route works for lower-severity issues.

Never allow the budget to be raised silently to unblock a release. If the number needs to change, it changes in a review with a reason. Otherwise the budget becomes whatever the last urgent release needed it to be.

Report the trend, not just the number

A dashboard showing the regression count per release over time is worth more than any single number. Teams respond to trends. When the line slopes down quarter over quarter, accessibility is improving and everyone can see it.

Share the trend beyond engineering. Product managers who see accessibility as a line moving in the right direction will protect the budget. Ones who only hear about it when a deploy is blocked will try to kill it.

Who owns the budget

A budget needs an owner, and the right owner is usually the frontend lead or the engineer closest to the templates. The owner does not fix every violation personally. They watch the number, call out regressions in release reviews, and keep the ratchet moving down quarter over quarter.

Make the budget visible in release notes: two numbers, this release and last. When the whole team sees the count, it becomes a team metric rather than one person's crusade. Celebrate the quarters where it drops. Positive reinforcement keeps a constraint alive longer than enforcement alone.

Frequently asked questions

Isn't any regression budget just permission to ship inaccessible code?

A budget of two per release with a downward ratchet ships far less inaccessible code than a budget of zero that everyone ignores. The goal is fewer barriers over time, and budgets achieve that where absolutism fails.

How do we count violations consistently across tools?

Pick one scanner as the source of truth for the budget and stick with it. Different tools count differently. Consistency matters more than completeness for a trend metric.

What about content editors introducing issues?

Track template violations separately from content violations. Templates are engineering's budget. Content issues go to the content team with training, not to the deploy gate.