Accessibility Debt Is a Systems Problem

I’ve heard it described as a “nice to have”, a “phase two priority”, and my personal favourite: “we’ll add accessibility once the MVP is done.”

Every time, the same assumption underneath: that accessibility is something you do to a product after the real work is done. A layer you apply. A box you tick. Something that lives in the backlog and can wait until there’s capacity.

It can’t. You can retrofit a ramp, but you can’t retrofit a building designed without thought for the people who need it. The longer you treat accessibility as an afterthought, the more expensive that assumption gets.

The feature mindset

When accessibility is a feature, it competes with other features for sprint capacity. It gets deprioritised when things get busy, scoped down when timelines tighten, and closed when the most visible issues are fixed. It gets handed to one person on the team as their “thing”, knowledgeable, well-meaning, and completely unable to fix a systemic problem from one position.

The feature mindset also produces checkbox accessibility. Satisfying an audit, hitting a WCAG level for legal cover, not actually thinking about real people trying to use the real product.

WCAG compliance is a floor, not a ceiling. Passing an audit means you’ve met the legal minimum. It doesn’t mean you’ve built something good.

The reframe that changed how I think about this: accessibility isn’t a feature. It’s debt.

Deferred cost. Not avoided cost.

Debt isn’t a metaphor for things that went wrong. It’s a precise description of deferred cost. When you take on technical debt, knowingly or not, you’re not avoiding a cost, you’re moving it. The work still needs doing. The interest accrues whether you’re paying attention or not.

You know the feeling. You’ve inherited a codebase carrying weight for years. Decisions baked into the architecture nobody alive made consciously, dependencies nobody can explain, workarounds that became load-bearing walls. Every new feature costs more than it should. Every sprint starts with a tax you didn’t incur.

Accessibility debt feels exactly like this. It forms the same way, compounds the same way, resists resolution for the same structural reasons.

That compounding is the thing. Debt doesn’t stay still. Each sprint that runs without addressing it, each feature built on an inaccessible foundation, each component added to a design system that never had accessibility baked in, the balance grows. Not dramatically. Just steadily. Until the cost of fixing it is genuinely prohibitive and the conversation shifts from “when do we address this” to “we’ll have to live with it.”

Hold that.

How it forms

Accessibility debt isn’t usually negligence. It’s what happens when delivery processes, team structures, timelines, and incentives make inaccessibility the path of least resistance.

Here’s how it typically goes. A product launches under pressure, with accessibility scoped for a future sprint that never arrives. A design system gets built quickly, real craft, real care, but without accessibility embedded at the component level, and those oversights scale across every surface that touches it. A team hires for speed and assumes accessibility expertise lives somewhere, in someone, without ever naming where. An audit gets commissioned, returns a spreadsheet, gets triaged like any other bug list: some fixed, most deferred, the underlying conditions untouched. Six months later, half those issues are still there, because fixing them properly means rethinking decisions made years ago.

Every single one of those is structurally identical to how other technical debt forms. Delivery pressure over quality. Ownership that belongs to everyone in principle and no one in practice. Late-stage testing finding problems too embedded to fix cheaply. Systems scaling problems as efficiently as they scale solutions.

The team isn’t negligent. The system is producing the outcome reliably. That’s a more damning observation. Good intentions don’t fix it.

Why it stays invisible

Technical debt has some visibility to the people creating it. You feel the slow build. You dread the fragile test suite. You know which parts of the codebase nobody wants to touch. It’s legible. It shows up in your working day.

Accessibility debt doesn’t show up in your working day — unless you’re one of the users paying it.

The interface passes internal review. It looks polished in the handoff. It works in every browser the team tests. And somewhere, a user with a screen reader hits a form that was never labelled properly and can’t complete a task everyone assumed was trivial. A keyboard-only user reaches a component that traps focus with no way out. A user with a cognitive disability hits an interaction pattern so unpredictable they abandon the page entirely.

The team never sees any of this. The failure is silent. The user develops a workaround, asks someone else to do it, or leaves. None of those outcomes generate a bug report.

The debt is real and the interest is being paid. Just not by the people who created it.

That asymmetry is what makes accessibility debt different in kind, not just degree. The cost has been externalised, offloaded onto the people least able to push back, least visible in internal metrics, most likely to be treated as edge cases when they’re anything but.

Why retrofitting doesn’t fix it

There’s a version of this conversation that ends with an accessibility audit and a remediation sprint. Teams reach for it because it feels like a solution. It isn’t. It’s a minimum payment.

Think about credit card debt. You can make the minimum payment every month and feel like you’re dealing with the problem. But if you’re still spending, still building on inaccessible foundations, still shipping components without accessibility review, still running a process that systematically deprioritises this, the balance keeps growing. The minimum payment keeps you out of default. It doesn’t get you out of debt.

Retrofitting in practice: an audit as a spreadsheet. A two-week sprint before a major release. One person designated as the accessibility lead, knowledgeable, well-meaning, structurally incapable of fixing a systemic problem from one position. Component-by-component remediation on a product whose architecture makes every fix harder than it should be.

None of it is worthless. Remediation matters. Fixing what’s broken is better than leaving it broken. But remediation without systemic change is a treadmill. You’re always catching up, never getting ahead, and the debt accrues faster than you can service it.

The bolt-on model, build the thing then add accessibility, is intuitive and wrong. A semantically broken DOM can’t be fixed with ARIA. An interaction pattern built around hover can’t be retrofitted for keyboard users without rebuilding it from scratch. You can paper over the cracks, but you can’t change the structure without going back to the beginning.

The audit finds the symptoms. It doesn’t touch what caused them.

Where it actually needs to live

Hiring an accessibility specialist helps. It’s better than nothing. But one person can’t fix a systems problem. They can flag it, advocate for it, make things incrementally better. The structural issues stay put.

Accessibility has to be in the design tokens. In the component contracts. In the definition of done. In the hiring bar, the interview process, the onboarding for new engineers.

That’s not an accessibility programme. That’s just how you build things.

This shift is cultural before it’s technical. It needs people in leadership positions to model it, talk about it, and fund it. It needs designers and engineers to build accessibility knowledge, not borrow it when there’s an audit due.

If accessibility is debt, it belongs in the same conversations as performance budgets, test coverage, and code quality. Same level of seriousness, same structural investment, made a property of the system rather than a check at the end of the delivery chain.

The design system as the scaling mechanism

A well-built design system is one of the most powerful accessibility tools an organisation can invest in. Not because it magically solves things, but because it makes the right thing the easy thing.

If every interactive element in the system already handles focus correctly, if every colour pairing in the token layer already passes WCAG, if every component already has the right ARIA semantics baked in, then product teams building on top get accessible outputs almost by default. The right decisions get made once, at the foundation, and scale outward.

That’s the promise. It requires discipline to build it that way and an organisation that takes the system seriously enough to actually use it. But when it works, it scales accessibility the same way it scales everything else. Which is the whole point.

The inverse is equally true. A design system built without accessibility in the foundation doesn’t just fail to help. It actively scales the problem. Every team using it inherits the debt. Every surface built on it compounds it.

Where to start

The structural change takes time. In the meantime:

Automated testing in CI — Catch the easy stuff automatically. axe-core, Lighthouse in your pipeline. Not sufficient on its own, but necessary. Failing silently is worse than not testing at all.

Keyboard testing as a daily habit — Tab through your UI. Does it make sense? Can you reach everything? Can you tell where you are? Costs nothing. Finds more than most teams expect.

Screen reader testing — NVDA on Windows, VoiceOver on Mac and iOS, TalkBack on Android. Pick one and actually learn it. An afternoon with a screen reader will teach you more than any audit report.

Embed it in the definition of done — Accessibility criteria in the acceptance criteria. Not as an afterthought. As a gate. If it doesn’t meet the bar, it isn’t done.

Test with real users — Nothing replaces usability testing with people who actually use assistive technology. Do it as early as you can and as often as you can afford to.

Build the culture — Workshops, shared articles, making accessibility part of how the team talks about quality. People make better decisions when they feel equipped to make them.

---

Good design is useless if people can’t use it. That’s not a philosophical position, it’s a practical one. Treating accessibility debt with the same seriousness you bring to every other form of structural debt isn’t just the right thing to do. The cost is real, it’s compounding, and someone is already paying it.

Accessibility work is never finished. The web keeps changing, standards evolve, new devices and assistive technologies emerge. That’s not a reason to despair. It’s a reason to keep going. The goal isn’t a perfect score. The goal is to keep making things more usable for more people.

The question is whether that’s visible to you yet.