I asked around a bit and it turns out the biggest challenge with accessibility debt is often knowing where to start. When you have so many issues to fix, how do you decide what to tackle first?
You could jump in blindfolded and start fixing things left and right. But you'll have no guarantees that you're moving the right needle in the right direction. It's better to have a prioritisation framework to help you focus on what matters most, whether it’s improving the user experience, reducing legal risk or aligning with business goals.
Here are the four prioritisation frameworks I use most often to tackle accessibility debt, from most to least favourite.
1. Frequency and severity
- When to use it: When you want to focus on issues that affect the most users or cause the most frustration.
- When not to use it: If your product has low user traffic or limited feedback channels.
- How to use: Rank issues based on how often they occur and how severely they affect users.
- Prerequisites: User feedback from surveys, support tickets or usability testing.
- Example: Fixing a keyboard navigation blocker on the high-traffic product checkout page is more important than adding an alt text to the product image page.
2. User impact vs. effort matrix
- When to use it: When your team has limited resources and tight deadlines.
- When not to use it: If you lack clear data on user impact and have problems estimating effort.
- How to use: Focus on issues that have the biggest impact on users but take the least effort to fix.
- Prerequisites: A list of accessibility issues from an audit or testing together with input from developers to estimate effort.
- Example: Fixing low-contrast text that affects many users is easier and more important than a complex ARIA issue affecting a few.
3. Business impact
- When to use it: When you need to align accessibility work with business goals (e.g., increasing conversions, reducing support costs).
- When not to use it: If business metrics aren’t clearly tied to accessibility issues.
- How to use: Align fixes with business goals, like improving conversion rates or reducing support tickets to convince stakeholders.
- Prerequisites: Clear business goals and metrics (e.g., conversion rates, support ticket volume).
- Example: Fixing a checkout flow barrier that impacts sales is more important than low contrast text on the about us page.
4. Legal risk assessment
- When to use it: When compliance is a top priority (e.g., upcoming audits or legal deadlines) or your product is in a high-risk industry (e.g., finance, healthcare).
- When not to use it: When the framework leads to neglecting smaller, high-impact user issues.
- How to use: Prioritise issues that could expose your organisation to legal or compliance risks.
- Prerequisites: Knowledge of relevant accessibility laws (e.g., European Accessibility Act, Equality Act, WCAG).
- Example: Tackle WCAG Level A and AA failures before looking at Level AAA enhancements.
The best framework depends on your product, users and team. Ask yourself:
- Who are your users and what barriers do they face?
- What are your business goals or compliance deadlines?
- What resources does your team have available?
I should mention that you don’t have to stick to one framework. You can combine them or switch from one to the other. The important thing is to start listing your accessibility issues and listening to your users.
Once you have a list to work with, score them using your chosen framework. Use a spreadsheets or your project management tool of choice. Next, create a roadmap with clear priorities and timelines.
As always, start small, pick one framework and see how it works for your team.
Next Thursday, we'll look at understanding the real-world impact of accessibility issues from the user’s perspective.