Accessibility Debt: How to Prioritize a Backlog Without Freezing Releases

2026-10-14

Accessibility debt works like technical debt with one uncomfortable difference. Technical debt mostly costs the engineering team. Accessibility debt costs customers directly, every day it sits in the backlog, in the form of checkouts they cannot complete and information they cannot reach. It accrues interest in lost sales and legal risk, not just in future refactoring.

The usual responses both fail. Fixing everything before the next release freezes the roadmap for a quarter and teaches the business that accessibility is the thing that stops shipping. Ignoring the backlog teaches the team that accessibility is the thing nobody means. The workable path is a prioritization system that treats debt as a normal, managed part of shipping.

Rank by harm, not by rule

Most backlogs are sorted by WCAG success criterion or by the severity a scanner assigned, which tells you about the code, not about the customer. A better ranking starts from user tasks. Can a keyboard user complete checkout? Can a screen reader user find the price, the reviews, and the shipping information? Issues that break those tasks outrank everything, even if the scanner called them moderate.

The next tier is reach. An issue in the header or the product template affects every page, so it outranks an identical issue on one landing page. Multiply harm by reach and you have a rough priority score that non specialists can understand, which matters because the backlog is argued about in rooms where nobody can recite success criteria numbers.

Make the top slice a normal sprint habit

The teams that clear debt reliably do not run accessibility quarters. They reserve a fixed slice of every sprint, often ten to twenty percent, for the top of the accessibility backlog. The slice is small enough that releases keep moving and large enough that the backlog visibly shrinks over a few months, which keeps leadership support alive.

Protect the slice the way you protect any capacity commitment. When a launch threatens to eat it, the conversation should be explicit: we are choosing to let this debt accrue interest for two more weeks, and here is what it costs. Most of the time the launch can wait, or the slice can be borrowed and repaid. What kills debt programs is the silent version, where the slice just disappears.

Stop new debt at the pipeline

Paying down the backlog while new issues land at the same rate is bailing a leaking boat. Automated checks in CI catch the mechanical issues, missing alt text, unlabeled controls, contrast regressions, before they merge. They will not catch everything, but they catch the cheapest issues, which are also the most numerous, and they teach developers the patterns by failing fast.

Pair the automation with a lightweight review for new templates and flows. A thirty minute keyboard and screen reader pass on a new checkout step or a redesigned navigation catches the issues scanners miss, and it costs far less than discovering them in a backlog audit six months later. The goal is not a gate that blocks shipping. It is feedback fast enough to fix things while the code is still warm.

Review the backlog against reality quarterly

Backlogs rot. Issues get fixed incidentally by redesigns, templates change, and priorities shift. Once a quarter, revalidate the top of the backlog against the current site and current user tasks. You will usually find that a fifth of it no longer applies, which is a free win, and that some issues have grown teeth as traffic shifted to the pages they affect.

Use the review to report progress in business terms: tasks that are now completable, pages that are now usable, and the trend in new issues per release. Leadership does not need criterion counts. It needs to know the debt is shrinking, new debt is slowing, and customers who were blocked can now buy. That is the report that keeps the sprint slice funded.

Frequently asked questions

What is accessibility debt?

The accumulated backlog of accessibility barriers in a product: unlabeled controls, keyboard traps, contrast failures, and similar issues that make the site harder or impossible to use for people with disabilities. Like technical debt, it grows when shipping outpaces fixing, and it costs real customers until it is paid down.

Should we stop releases to fix all accessibility issues at once?

Usually not. A full stop freezes the roadmap and frames accessibility as the thing that blocks shipping. Reserving a fixed slice of every sprint for the highest harm issues clears the backlog steadily while releases continue, and it is easier to sustain politically.

How should we prioritize which issues to fix first?

By harm to real users, starting with issues that block core tasks like checkout and navigation, then by reach, issues in shared templates outrank one page issues. Scanner severity and rule numbers are a starting point, but user impact is the ranking that matters.

How do we stop accessibility debt from growing again?

Put automated checks in the build pipeline to catch mechanical issues before they merge, add a short manual keyboard and screen reader pass for new templates, and track new issues per release. Paying down the backlog only works if the inflow slows at the same time.