Without much introduction, I'll dive into the simple methods for tackling web accessibility issues in product teams. I've used these methods time and again and they always yielded great results.
1. The 80:20 rule (Pareto Principle)
The Pareto principle suggests that 80% of accessibility issues stem from 20% of the root causes. In practice, it means that a small subset of recurring issues tend to create the biggest accessibility barriers. So your job is to focus on these top 20% of issues to solve 80% of your accessibility challenges.
You do this by:
- Identify the high-impact issues by conducting an accessibility audit and ranking issues by severity and frequency.
- Prioritise the critical 20% and focus first on these common problems that affect multiple users across various pages.
- Automate, if you can, to detect and fix repeated patterns.
- Always validate fixes with users.
2. The Sherlock Holmes method
Ask Who, What, Where, When, Why and How to analyse an accessibility issue in context. Instead of just fixing surface-level problems, this approach uncovers the systemic gaps causing them.
Here's an example for a recent issue I dealt with for a modal dialog.
- Who is affected? (screen reader users, keyboard-only users)
- What is the problem? (modal dialog cannot be dismissed)
- Where does it occur? (payment page, product edit page)
- When does it happen? (on all desktop browsers)
- Why is it an issue? (without a keyboard-only way to dismiss the dialog, users are trapped)
- How can it be fixed? (add Escape as a way to dismiss the dialog and test across devices)
3. The five whys
Ask Why? repeatedly to dig beneath the surface and find the root cause of an accessibility issue. Instead of treating symptoms, create lasting solutions.
Here's an example to diagnose the same modal dialog issue above.
- Why can't screen reader users edit the product? Because they cannot dismiss the modal dialog.
- Why can't they dismiss the modal dialog? Because developers didn't follow the correct ARIA pattern or didn't use semantic HTML.
- Why didn't they use semantic HTML? Because accessibility wasn't part of the design process.
- Why wasn't accessibility in the design process? Because the team lacks accessibility training.
- Why is there no accessibility training? Because leadership hasn't prioritised accessibility in the team.
Here's the thing.
Accessibility is too complicated to solve without breaking it down into smaller logical parts. Otherwise, it's just scary (yes, I've heard this term used). You could jump into building these large roadmaps to tackle accessibility and then not follow through. So why not start with doing the work first.
Implementing any of these three methods can change how your product team approaches web accessibility.