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?
