The accessibility debt problem and how to stop adding to it

Every engineering team understands technical debt. The shortcuts taken under deadline pressure that slow down future work. Accessibility debt works the same way but is less visible, compounds faster in certain dimensions, and tends to get reclassified as "not a priority" in a way that technical debt rarely is.

The pattern is consistent: a team ships a product with no keyboard support because the deadline was tight. The product grows. Now keyboard support is missing across 80 screens instead of 8. The fix that would have taken a week at launch will take a quarter now, and will require touching every piece of the product, because keyboard behavior lives in components that are shared everywhere. The debt is the same unit of problem; the interest is the surface area it covers.

The three kinds of accessibility debt

Not all accessibility debt behaves the same. Structural debt is the most expensive kind: it lives in shared components, in the application architecture, in the way the DOM is generated. A dialog component built without focus trapping propagates that failure everywhere a dialog appears. An input component built without proper label association fails on every form. These aren't individual bugs. They're patterns that replicate at the rate the product ships new features.

The fix for structural debt can't be addressed ticket by ticket, because each ticket only patches one instance of a problem that's generated by the underlying implementation. You fix the component, not the occurrence.

Contextual debt is different. A specific flow has missing keyboard support. A specific page has incorrect heading structure. A specific form has unlabeled fields. These failures don't propagate; they're localized. They're also usually easier to fix per-occurrence, though fixing them all takes time proportional to how many there are.

Knowledge debt is the kind that determines how fast new debt accumulates: the team doesn't know what correct looks like. They don't know the focus management spec for a dialog. They don't know the ARIA pattern for a combobox. They don't know that a click-only interaction is a failure. Every ticket they complete under knowledge debt is a new instance of debt at a rate they're unaware of.

Why it compounds

Technical debt slows down development in ways that are legible: the codebase gets harder to change, builds get slower, onboarding gets harder. Engineers feel it and can articulate it. Product leadership can observe the productivity decline.

Accessibility debt compounds silently. The product works fine for the majority of users who don't use assistive technology. The failures are invisible to everyone on the team because no one is testing with the affected technology. The compounding happens in the gap between what the team can see and what the user experiences.

The interest payment comes in one of a few ways: a formal VPAT request from an enterprise customer who requires documented conformance. A complaint from a user who can't complete a task. A lawsuit citing ADA noncompliance. By the time the interest payment is due, the principal has grown to the size of a multi-quarter remediation project.

How to stop adding to it

The primary intervention is making accessibility a release criterion before it's an audit finding. This is structural: it changes the conditions under which code ships, not the conditions under which code is evaluated after the fact.

What this means practically: adding an accessibility checklist to the definition of done so that every ticket that touches UI is reviewed against a short set of checkable requirements before it's merged. The list doesn't need to be long. It needs to cover the failure modes that appear most often: visible focus states, keyboard reachability, labels on interactive elements, correct heading hierarchy, alt text on images. Five questions that can be answered in three minutes per ticket will prevent a large portion of new debt.

The second intervention is closing knowledge debt before it accumulates. A shared reference that answers the questions developers encounter in practice: what keyboard behavior should a date picker have, what ARIA roles does a tab panel need, when is aria-live appropriate? Not a training deck. An active document. This reference gets better as engineers encounter new patterns and add them. It becomes the answer to "how do we implement this accessibly" before the question is escalated or ignored.

The third intervention is treating existing debt as a backlog with priority, not a category of work outside the normal planning process. Every component with documented accessibility failures goes into the backlog with an estimated fix effort and a priority based on usage surface area and severity. High-traffic components with critical failures get fixed before low-traffic components with minor ones. The backlog is reviewed in planning. The work is scheduled. It's not a separate track that never gets time.

What a realistic remediation looks like

A codebase with two years of accumulated accessibility debt will not be fully remediated in one sprint. The work tends to be larger than it appears when a team finally looks at it closely, both because the surface area is wide and because fixing structural issues requires coordination across many files.

The sequencing that works: start with shared components because the fix-to-benefit ratio is best there. Then address the highest-traffic flows because that's where the most users are affected. Then work through lower-priority contextual debt based on available capacity.

This isn't a six-month project that ends with everything fixed. It's an ongoing practice of reducing the existing debt while not generating new debt at the old rate. The goal isn't a perfect VPAT; it's a process that keeps the debt under control instead of letting it grow until the interest payment exceeds the team's ability to respond.

A team that has closed its knowledge debt, added accessibility to its definition of done, and committed to a remediation backlog will, over 18 months, look like it has a mature accessibility practice. Not because they did something heroic, but because they stopped doing the things that were generating the debt in the first place.