You've probably heard of technical debt. Every time you took shortcuts or created "temporary" solutions, you've taken on some technical debt. That's not necessarily a bad thing. All teams do it when trying things out. And as long you're aware at some point you need to pay it down, it's okay. If you wait too long, then you'll have a much harder time with future development.
So that's technical debt. What about accessibility debt?
Let me tell you a quick story.
Imagine a developer named Sarah and a product owner - Gary. During a design review session, Sarah stares at her screen, frowning at the new file upload feature's design specs. She already flagged the broken keyboard controls, but Gary, the product owner, makes the final call: "Let's ship what we have and fix it next sprint. How many users actually navigate with just a keyboard?" The accessibility tickets are marked "Not doing" and pushed back.
Three months and lots of other product features later, a user with a screen reader can't navigate the file management interface during a feedback session. What would have taken hours to fix initially now requires weeks of refactoring. The "temporary" solutions had become permanent. Only one thing left to do for Sarah. She opens JIRA and creates a new epic: "Accessibility Debt Remediation."
If you think about it, accessibility debt works the same way as any technical debt. The stakes are just higher for your users.
Think of it as the accumulation of accessibility barriers and issues that your team has postponed fixing. This could be anything from missing alt text on images to keyboard navigation problems that make your product harder to use for people with disabilities.
Throughout working with product teams, I've identified five common sources of accessibility debt:
- Rushed features that skip accessibility requirements
- Temporary fixes that become permanent
- Legacy code from before accessibility was a priority
- Lack of accessibility knowledge in the team
- Missing or incomplete accessibility testing
Let's briefly look at each.
Rushed features that skip accessibility requirements
This typically happens during tight deadlines or end-of-quarter pushes. You can spot it when your team skips accessibility testing in QA, postpones screen reader testing or launches features without doing any manual or automated testing. The telltale sign is finding basic issues like missing alt text, poor keyboard navigation or unclear focus states that end up in production. That's your lagging indicator. As a leading indicator, the best sign is missing accessibility requirements from your definition of done.
Temporary fixes that become permanent
These are the "we'll fix it properly later" solutions that you never revisit. Whenever you hear your developers talking about some "quick workarounds," your ears should prick up. To see just how much in debt you are, check your latest release notes for tickets labeled "temporary fix" and your backlog for tickets mentioning known accessibility issues that are more than two sprints old.
Legacy code from before accessibility was a priority
All code is eventually legacy code. So historical debt is inevitable. Review your oldest product features and components. If no one touched them since implementing accessibility standards, they're likely carrying debt.
Lack of accessibility knowledge in the team
This manifests in the most subtle ways, but there are always tells. Developers implement ARIA incorrectly. Designers create components with poor contrast ratios. QA miss critical accessibility issues. Review your team's pull requests and design reviews. If you see that accessibility feedback rarely comes up or if the same issues keep appearing, you likely have a knowledge gap. And that will eventually build up your accessibility debt.
Missing or incomplete accessibility testing
Accessibility testing is the easiest to spot and the easiest to overlook and dismiss or postpone. Check if your CI/CD pipeline includes automated accessibility testing. Look for gaps in your testing process as well. Are you only running automated tests? Do you manually test what automated tests cannot catch? Do you have testing sessions with screen reader users?
Start thinking about how many of these issues might be present in your product. And take stock of others that are maybe not so common, but still present. Things like custom one-off components instead of using accessible design system elements, external tools, plugins or content that doesn't meet accessibility standards.
The more you know, the better you can watch out for accumulating accessibility debt.
Next time, we'll look at how accessibility debt affects business metrics.