Accessibility Debt: How to Quantify It for Leadership

Accessibility work loses budget fights because it is framed as risk avoidance. Leadership hears about lawsuits and compliance, nods seriously, and funds the minimum. The teams that win sustained investment do something different: they quantify accessibility debt the way engineering quantifies technical debt, as a number with a growth rate and a cost of delay. Once the debt has a number, it can compete with feature work on equal terms.

Accessibility debt is the gap between your site's current state and WCAG 2.2 AA, expressed in remediation effort. Every known violation is a liability with a price tag: the hours to fix it, the pages it affects, and the probability that it generates a complaint, a demand letter, or a lost customer. Added up, that is a debt balance. Like all debt, it compounds, because every release built on an inaccessible foundation adds new violations.

Building the debt inventory

Start with a full-site scan and categorize every finding by remediation effort: quick wins under an hour, medium fixes taking a day, and structural issues requiring redesign. Assign each a cost using your team's blended hourly rate. A missing form label is a thirty-minute fix. A keyboard trap in the checkout is a multi-day project. The inventory turns an abstract violation count into a dollar figure, which is the language budget conversations run on.

Weight the inventory by exposure. A violation on the checkout page costs more than the same violation on an archived blog post, because it touches revenue and because plaintiffs' firms test checkout flows first. Multiply remediation cost by a traffic-and-revenue weight per page template. The result is a prioritized debt ledger: not just what is broken, but what is expensive to leave broken.

The cost-of-delay argument

Debt framing works because it makes delay expensive. Two numbers carry the argument. First, the accumulation rate: how much new debt each sprint adds, measured by scanning before and after releases. If every release adds forty hours of new violations, the debt grows even while you fix old issues, and the team can see the treadmill. Second, the incident cost: the fully loaded cost of the last demand letter or complaint, including legal review, rush remediation, and leadership time. One real incident number beats a hundred hypothetical warnings.

Present it as a chart, not a memo. Debt balance over time, with the accumulation rate as the slope. Leadership understands slopes. A line going up means the problem is getting more expensive. A line going down means the investment is working. Accessibility reporting that shows only violation counts invites the question so what. Debt reporting answers it before it is asked.

Tying debt paydown to releases

The operational payoff of the debt ledger is a policy: no release increases the debt balance. New features ship with their accessibility verified, which means the accumulation rate drops toward zero and all remediation effort goes toward paying down principal. Teams that adopt this rule find that accessibility stops being a separate project and becomes part of done, which is the only sustainable equilibrium.

For headless teams this matters more, because the frontend ships independently of the backend and accessibility regressions arrive silently with every deploy. Continuous scanning in the pipeline, with the debt ledger updated automatically, gives the team a number that is always current. When the ledger is part of the release dashboard, accessibility debt gets the same attention as test coverage and error rates. That is the goal: not a special initiative, but a normal metric.