Accessibility debt: the problem nobody talks about

Introduction

Accessibility problems rarely arrive all at once. More often, they accumulate quietly.

A button is implemented without a visible focus state. A color combination is approved even though the contrast is too low. A form component is created without a reliable relationship between labels, instructions, and errors. A document template is published without accessibility requirements. A procurement process asks vendors about delivery dates and price but says nothing about accessibility. Each decision may look local when it happens. Over time, however, those decisions are copied, reused, embedded in templates, inherited by new projects, and normalized as part of the way the organization works.

The result is what we can usefully call accessibility debt.

The term is related to technical debt, but it describes a different kind of accumulated obligation. Accessibility debt appears when barriers are allowed to persist inside the systems that produce digital products: design decisions, reusable components, code, content practices, document templates, governance, and workflows. The immediate cost may be easy to ignore because the product still ships. The long-term cost becomes harder to avoid because every new page, feature, campaign, or product can reproduce the same barrier.

That is why accessibility debt cannot be managed effectively as an endless list of isolated bugs. If the same issue appears in hundreds of places, the most important question is not how quickly the team can fix each instance. It is why the issue keeps being created.

The distinction changes remediation from a page-by-page exercise into a systems problem.

What is accessibility debt?

Accessibility debt is the accumulated cost and effort created when inaccessible decisions remain unresolved and continue to influence new work.

A website with a handful of individual accessibility issues certainly has problems to fix, but those issues do not all represent debt in the same way. Debt becomes especially significant when a barrier is embedded in something reusable or repeatable: a component, a template, a workflow, a content standard, a design token, a document format, or a governance process.

Imagine a custom dropdown that cannot be operated reliably with a keyboard. If it appears on one page, the organization has one implementation problem. If the component is part of a shared library used across twelve products, the organization has a source of accessibility debt. Every reuse increases the number of affected experiences, the amount of testing required, and the cost of correcting the pattern later.

The same principle applies outside code. A publishing workflow that does not require alternative text can generate inaccessible images across years of content. A document template without proper heading styles can produce hundreds of inaccessible reports. A design process that approves interaction patterns without keyboard or screen-reader considerations can introduce barriers before development even begins.

Accessibility debt is therefore not simply the number of issues in an audit. It is the extent to which an organization has embedded inaccessible assumptions into the systems that generate future work.

This is also why debt can remain invisible for a long time. A product may continue to function for many users. Teams may become accustomed to known limitations. Automated tools may catch only part of the problem. The true scale often becomes visible when the organization conducts a deeper audit, enters a new procurement environment, begins a redesign, or tries to remediate several products at once.

How accessibility debt accumulates

Accessibility debt rarely comes from a single bad decision. It grows through repetition.

Some sources are technical. Others are visual, editorial, or organizational. In mature digital ecosystems, several of them usually interact.

Design decisions

Design choices can create debt before a line of code is written.

A color palette may include combinations that repeatedly fail contrast requirements. A component specification may not define focus states. A mobile interaction may depend on precise gestures. A modal may be designed without considering keyboard order or how focus should move when it opens and closes.

If those decisions remain inside a shared design library, they become defaults. Designers reuse them because consistency is normally a strength. The problem is that consistency also scales mistakes.

This is one of the reasons accessibility needs to be part of the design process from the beginning, as we explored in Why Accessibility Should Be Part of Web Design from Day One. A design system that resolves accessibility early can prevent repeated barriers. One that does not can distribute them very efficiently.

Components and code

Reusable code creates some of the clearest examples of accessibility debt.

A component library may include buttons, tabs, accordions, form fields, dialogs, navigation menus, tables, alerts, and other patterns that appear across many pages and products. When those components are accessible, they provide enormous leverage. When they are not, the same leverage works in the opposite direction.

One missing accessible name can affect every instance of an icon button. One incorrect heading pattern can be copied across dozens of templates. One custom control with incomplete keyboard support can spread to every application that depends on the library.

This is why design systems matter so much in accessibility remediation. As discussed in What Is a Design System — and Does Your Organization Need One?, shared systems turn individual decisions into infrastructure. Accessibility debt often grows for exactly the same reason.

Accessibility debt can begin inside a reusable component long before the barrier becomes visible across an entire product ecosystem.

Content and documents

Not all accessibility debt lives in interfaces.

Organizations also accumulate debt through content practices: unclear link text, missing alternative text, improperly structured headings, videos without captions, documents without semantic structure, tables that cannot be understood by assistive technology, and PDFs created from inaccessible source files.

These issues are especially difficult when content volume is high. A single inaccessible report can be remediated. Hundreds of reports produced from the same template create a very different problem.

The underlying source may be a document template, an authoring tool, a publishing workflow, or a lack of guidance for the people creating content. If the organization focuses only on repairing published files, the same problems can continue to appear every week.

Processes and governance

Some accessibility debt is created because nobody clearly owns prevention.

A vendor receives no accessibility requirements. Designers do not know which standards they are expected to follow. Developers receive accessibility feedback only at the end of a sprint. Content teams have no publishing checklist. Procurement does not ask for evidence of accessibility capability. Audits happen periodically, but findings are not connected to the teams or systems that produced them.

In these environments, even good remediation work can decay.

A team fixes a set of issues, launches an improved version, and six months later the same barriers begin to return because the organization changed the output without changing the process.

Governance does not need to mean a large committee or a complicated approval structure. It means making accessibility part of ordinary responsibilities, standards, quality checks, procurement, and ownership.

Why the same issue appears across hundreds of pages

Large accessibility audits often contain a pattern that initially looks overwhelming: the same issue appears again and again.

There may be hundreds of low-contrast buttons, dozens of forms with the same labeling problem, repeated heading-order issues, or the same navigation barrier across every page template. If each occurrence is treated as an independent bug, the remediation estimate can become enormous.

But repetition is also useful evidence.

Repeated issues often indicate that the true problem exists higher in the system. A shared component may be wrong. A template may contain the same structural mistake. A design token may be generating insufficient contrast. A CMS pattern may encourage editors to create headings incorrectly. A document template may be missing the semantic structure authors need.

The number of affected pages tells us something about scale, but it does not necessarily tell us the number of fixes required.

This is where organizations can make remediation substantially more efficient. Instead of asking, “How do we fix these 400 buttons?”, the better question may be, “Which component generates these 400 buttons, and can we correct the source?”

The difference between those two questions is the difference between treating accessibility as a backlog and treating it as infrastructure.

Accessibility debt is not the same as an accessibility backlog

An accessibility backlog is a list of known work.

Accessibility debt is the underlying condition that causes inaccessible work to accumulate or become more expensive over time.

The two overlap, but they are not interchangeable.

A backlog might contain ten issues discovered during an audit. If each issue is isolated, well understood, and unlikely to recur, the organization may simply need to prioritize and resolve them. That is work waiting to be done, but it does not necessarily indicate a systemic problem.

Debt becomes more significant when the same issue keeps returning, when fixing one page leaves dozens of other instances untouched, or when new work continues to introduce barriers faster than the organization removes them.

The distinction matters because a backlog can shrink while debt continues to grow.

A team might close fifty accessibility tickets during a quarter while simultaneously launching new templates, components, and content workflows that introduce another hundred instances of the same problems. The activity level looks high, but the system is not becoming healthier.

A useful accessibility program therefore needs to track more than closed issues. It needs to understand recurrence.

What makes accessibility debt expensive

Accessibility debt becomes expensive for the same reason many forms of structural debt become expensive: dependencies accumulate around it.

A component that would have been easy to change when first created may later be used across multiple products. A content model that initially affected one section may become part of years of archived material. A visual rule may be embedded in templates, brand guidance, design libraries, and third-party implementations.

By the time the organization decides to correct the problem, the work may involve much more than changing the original source. Teams may need to update dependent products, retest interactions, coordinate releases, migrate content, communicate with vendors, revise documentation, and ensure that the remediation itself does not create regressions.

There is also an opportunity cost. Time spent repeatedly correcting avoidable barriers is time not spent improving products, addressing new user needs, or reducing other forms of risk.

This does not mean organizations should attempt to eliminate every accessibility issue immediately. That approach is often unrealistic. The more useful goal is to identify which forms of debt are generating the greatest amount of repeated work, exclusion, or future risk.

A debt model can be understood through three connected stages:

The important point is not to calculate a fictional monetary value for each row. It is to understand how a small source can create a large remediation surface.

The cost of accessibility debt grows when a small source is allowed to reproduce across a larger system.

Fix patterns before pages

When accessibility issues repeat, the most effective remediation often begins above the page level.

This does not mean individual pages should be ignored. Critical barriers affecting real users may need immediate correction wherever they appear. But if remediation stops there, the organization can spend significant effort treating symptoms while leaving the source untouched.

A pattern-first approach looks for leverage.

If a form field is inaccessible across twenty pages, fix the shared component and then verify the instances. If heading structures are repeatedly wrong, examine the template or CMS controls that authors use. If contrast issues appear throughout the interface, review the design tokens rather than adjusting each color manually. If PDFs repeatedly require the same repairs, change the source template and publishing workflow.

This approach is particularly powerful in design systems because the same mechanism that distributed the problem can distribute the solution.

A corrected component may eliminate a barrier across hundreds of instances after a single coordinated update. A revised content pattern can prevent future errors before they are published. A stronger procurement requirement can stop a new source of debt from entering the ecosystem at all.

That is one of the most important strategic differences between accessibility remediation and accessibility maturity. Remediation fixes what exists. Maturity changes what the organization produces next.

Preventing new debt

Accessibility debt cannot be reduced sustainably if new debt is being created at the same time.

Prevention does not require every team member to become an accessibility specialist. It requires the organization to place appropriate accessibility decisions at the points where they have the most leverage.

Design systems can establish accessible defaults. Component reviews can include keyboard and assistive-technology behavior. Content guidance can define expectations for headings, links, images, and documents. Procurement can require suppliers to explain how they address accessibility. Quality assurance can combine automated checks with targeted manual testing. Product teams can include accessibility acceptance criteria in critical journeys.

The objective is not to add a separate accessibility gate to every activity. It is to integrate accessibility into the work that is already happening.

This also means defining ownership clearly. Someone should know who maintains accessible components, who updates content guidance, who triages audit findings, who evaluates exceptions, and who ensures that known issues are not repeatedly reintroduced.

Without ownership, accessibility work tends to depend on individual advocates. That can produce excellent short-term results, but it is fragile. When those people change roles or leave, the organization can return to the same patterns that created the debt in the first place.

How to start paying accessibility debt down

Organizations with significant accessibility debt often face the same problem: everything looks important.

An audit may contain hundreds or thousands of findings. Several products may be involved. Teams may already be working at capacity. Trying to fix everything at once can make the program feel impossible before it begins.

A better starting point is to separate impact, scale, and source.

First, identify barriers that prevent or seriously disrupt critical user journeys. A problem that blocks registration, service access, donation, application, authentication, or essential information should not wait simply because it appears in fewer places.

Then identify issues with high repetition. If the same barrier appears hundreds of times, determine whether a shared source is responsible.

Finally, locate the systems that continue to create new instances. A component library, CMS template, document workflow, or vendor process that keeps generating barriers should be treated as a priority even if every existing instance cannot be remediated immediately.

This produces a more useful remediation sequence:

protect critical journeys → correct high-leverage sources → reduce repeated instances → prevent recurrence

The sequence will differ between organizations, but the principle is consistent. Accessibility debt becomes manageable when teams stop treating every issue as equally independent.

Paying down accessibility debt starts by identifying the sources that reproduce barriers, not by treating every repeated instance as a separate problem.

This is where the business case for accessibility becomes practical. As we discussed in The Business Case for Digital Accessibility, accessibility investment is easier to sustain when it connects to real organizational costs, risks, and outcomes. Accessibility debt makes one of those costs visible: the price of repeatedly correcting decisions that could have been resolved closer to their source.

If your audits keep finding the same problems, another round of page-by-page fixes may not be enough. The more important question is whether those issues are being generated by the components, templates, content practices, or governance behind the pages.

That is where remediation can begin to create lasting value.