Last time, we talked about evaluating real-world user impact to help you make strategic decisions and fix issues that block critical tasks.
But prioritising accessibility isn't just about user impact. You have to also consider feasibility.
Technical constraints can make some fixes harder than others. What looks like a simple colour contrast fix might need your team to completely redesign the component. Reworking some component with ARIA attributes to make it keyboard-accessible could be a five-minute update.
Your team needs to evaluate technical complexity and help you make realistic decisions.
Before prioritising fixes, you'll need to understand:
- How much development work is actually required
- What dependencies might slow things down
- Whether that "quick fix" will cause new problems
Here are the questions I use to help teams decide:
- How deep does this fix go? Surface-level tweaks like colour contrast or missing alt text are usually quicker than structural changes like keyboard navigation and focus management.
- Are we reinventing the wheel? If the issue is present in some shared component library, then fixing it once should solve multiple instances at once.
- Who else needs to be involved? If you depend on other teams, like back-end APIs for dynamic content, this will probably slow you down.
This is where I like to use the User impact vs effort matrix framework.
And a word of warning!
I've encountered three common scenarios where the fixes weren't as straightforward as we thought:
- It's never just a small tweak, especially without a technical review to back the claim up. That one-line code change might break responsive layouts or conflict with other accessibility fixes.
- Whenever you touch legacy code, expect delays and many unknowns. I've rarely seen legacy code with any sort of accessibility testing coverage or comprehensive documentation about the original intent.
- If you first need to refactor X before you can fix Y, you're bound to never get the actual fix deployed in time. And that's because usually you'll quickly discover that you need a few other fixes before you can fix X.
Without first understanding these, you risk over-promising, under-delivering and instead adding more to the accessibility debt you were trying to get rid of in the first place.
You might stop and call these "temporary workarounds." Been there, done that. They were rarely temporary. They just made future fixes more time-consuming, increased the risk to introduce new bugs in the code and discouraged everyone from working on accessibility.
And that's the last thing you need when you're trying to convince the "business" to put resources into accessibility.
We'll talk about how you can align your accessibility work with the business' goals to properly communicate value in next Thursday's email.