Accessibility Debt: How It Accumulates and How to Pay It Down

Programmers have a useful term for the accumulated cost of shortcuts: technical debt. You borrow time now, by doing something the quick way, and repay it later with interest, in the form of a codebase that gets harder to change. The metaphor works because the individual borrowings are each defensible. Nobody sets out to build an unmaintainable system. It happens one reasonable decision at a time.

Accessibility debt works the same way, and I think the metaphor is worth taking seriously, because it explains things that “companies don’t care about accessibility” doesn’t. Most teams I encounter through GazeSite aren’t hostile to accessible design. They’re carrying debt they took on in increments too small to notice.

Watch how it accumulates. A developer ships an image without alt text because the deadline is today and the image is decorative anyway, probably. A designer picks a fashionable light gray for secondary text because the mockup looks elegant, and nobody measures the contrast. A modal dialog gets built without keyboard handling because everyone on the team uses a mouse. A new form is copied from the old form, inheriting its unlabeled inputs. Each choice costs its user minutes at most and often nothing at all, because the person making it can see, uses a mouse, and knows what the form fields mean. Then a component ships into a design system and the shortcut is no longer one decision. It’s fifty instances across the product, with more created every sprint. That’s the compounding. Broken patterns don’t sit still; they get copied, because copying existing code is how software gets built.

The interest payments are real but land where the team can’t see them. A shopper who can’t operate your menu by keyboard doesn’t complete a purchase, and doesn’t tell you why. A screen reader user hits an unlabeled button wall in your checkout and buys from someone whose checkout works. The population affected is not small; disability in some form touches a substantial share of any customer base, more as that base ages, and the same barriers also degrade the experience for people on old devices, small screens, and bad connections. But none of it itemizes on a dashboard. Accessibility debt is unusual among business costs in that the invoice never arrives as an invoice. It arrives as slightly lower conversion, forever, and occasionally, in some jurisdictions, as a legal complaint, at which point the debt gets called all at once on someone else’s schedule.

That’s also when many companies first confront it, and it’s the most expensive possible moment. Retrofitting accessibility across a mature product means auditing hundreds of pages, rebuilding core components while the product keeps moving, and untangling patterns that other patterns were built on. The same fixes that would have cost minutes at design time cost weeks at retrofit time. This ratio, cheap at the source and expensive downstream, is the entire economic argument, and it’s why treating accessibility as a compliance project to be scheduled someday is the most costly way to do it.

So how do you pay it down, if you’re standing on top of an existing pile? Not all at once, and not alphabetically. Debt payoff is a prioritization problem, and two factors dominate. The first is traffic and money: a broken pattern on your checkout matters more than the same pattern on a conference recap from two years ago. The second is severity: issues that make a task impossible, an unreachable button, a form that can’t be submitted by keyboard, a control with no accessible name, outrank issues that make it merely unpleasant. Start where blockers intersect with revenue. A handful of fixes on the pages where money changes hands typically retires more effective debt than a hundred fixes in the archive.

The second move matters more than the first: fix the components, not the pages. If your button, your form field, your modal, and your navigation come from a shared library, then repairing those repairs every current page and, more importantly, every future one. This is the happy side of the compounding. The mechanism that multiplied the debt, copying, will multiply the payment the same way.

The third move is the one teams skip, and it’s the only one that ends the story rather than pausing it: stop borrowing. Paying down debt while shipping new debt is running up the down escalator. Prevention is mostly a matter of defaults and checkpoints, an accessible component library so the easy path is the good path, contrast checked at design review while the color is still a decision rather than a brand, keyboard operation included in the definition of done, automated checks in the pipeline so regressions get caught at commit time instead of by a customer. None of this is heroic. It’s the same boring machinery teams already use to keep bugs out, pointed at a class of bug they’d previously agreed not to see. Continuous monitoring helps for the same reason tests help: debt you can see is debt you can schedule. Debt you can’t see just grows. That’s a large part of why I built a scanner; the difference between an invisible pile and a ranked list is the difference between anxiety and a plan.

The mistake in all of this would be concluding that accessibility debt is shameful. Every real product carries some, the same way every real codebase carries technical debt, because products are built by people making tradeoffs under deadlines. The failure mode isn’t having debt. It’s not knowing how much you have, letting it compound silently, and finding out the balance from a complaint instead of an audit. Measured, prioritized, and paid down at the source, it’s just work, and unusually good work at that, because the return isn’t only risk removed. It’s customers who could not buy from you yesterday and can today.