Accessibility Debt Tracking

Track accessibility debt the way you'd track technical debt — as a known liability with a cost that compounds over time.

What Is Accessibility Debt

Accessibility debt is every known accessibility issue that exists in your product but hasn't been fixed. It includes:

Issues found in audits that were deprioritised
Tradeoffs where accessibility was deferred
New features shipped without full accessibility
Regressions introduced by updates or redesigns
Known gaps in assistive technology support

Why It Compounds

Unlike a feature request that just waits, accessibility debt grows:

Each new feature built on top of an inaccessible foundation inherits the inaccessibility
Users with disabilities develop workarounds that break when you eventually fix things differently than they expect
Legal exposure increases with time and awareness
The longer an issue persists, the more expensive it becomes to fix (code has grown around it)
Team knowledge of why the issue exists fades

Debt Record Format

For each known accessibility issue, track:

Issue: clear description of the accessibility barrier Severity: critical (blocks task) / major (significant difficulty) / minor (friction) Who's affected: specific user groups Where: page, component, or flow WCAG criteria: which success criteria it violates Discovered: date and how (audit, user report, testing) Deferred because: the reason it wasn't fixed immediately Workaround: any temporary alternative for affected users Estimated fix effort: small / medium / large Remediation deadline: when it must be fixed Owner: who is responsible for the fix

Managing the Debt

Triage Rules

Critical (blocks task): fix in current sprint, no exceptions
Major (significant difficulty): fix within 30 days
Minor (friction): fix within 90 days
Any issue older than its deadline gets escalated

Preventing New Debt

Accessibility acceptance criteria on every story
Accessibility check before merge (automated + manual)
Regression testing for previously fixed issues
New features cannot ship with critical accessibility debt

Paying Down Debt

Allocate a percentage of each sprint to debt reduction (10–20% is common)
Fix debt when you're already touching the component
Prioritise by: severity × number of users affected
Celebrate debt reduction — make it visible

Tracking Regressions

When a previously fixed issue reappears, it's a regression
Regressions should be treated as critical by default
Add automated tests for every fix to prevent recurrence
Track regression rate as a quality metric

Assessment Questions

Is there a documented list of known accessibility issues?
Does each issue have a severity, owner, and deadline?
Is accessibility debt being paid down each sprint?
Are regressions caught and treated as critical?
Is the debt trend improving or worsening over time?

accessibility-debt-tracking