So you have a clear system to decide what to fix first. You've involved the right people in the process and you now have proof that you're moving the needle in the right direction.
How do you communicate this to your stakeholders in a way they understand what you're on about?
You can't assume that just because you prioritised the issues and your team fixed them, your job is done. If no one knows or understands what you've done and why it's important, you're wasting your breath. Good accessibility prioritisation lives or dies by how you communicate its results and next steps.
Here's how you can keep everyone aligned, without endless syncs that disrupt work.
Rules
1. Segment your audience
For each accessibility issue, you likely have three audiences. Business leadership, the dev team and the customer.
2. Tailor your message to each audience
You need to make sure you're talking their language if you want to be heard. That means talking about business outcomes with the leadership, process improvements with your dev team and user experience with your customers. Each will have their own jargon.
3. Tie results to what each audience cares about
Rephrase each result to highlight what it means for each. For business, speak risk and revenue. Devs understand code and debt. And talk about progress to the customers.
4. Talk about the next steps
Always include the next things you're planning to do and what that will mean for them. Again, make sure to talk in a language they understand.
Example
Let's say you identified an issue on your checkout page that prevented keyboard users from making a purchase. During the prioritisation session, you decided this is what you should focus on and during the sprint your team fixed the issue and released the fix.
Here's how I would present the results to each of the audiences involved.
For leadership
We identified a problem that affected 8% of assistive tech users on our checkout flow. The potential lost revenue was around 5k/month. It took us two days to fix, test and release a new version. We're now testing that with our customers who rely on assistive tech and gathering feedback. Looking to report back in the next two weeks.
For the dev team
We figured out there was a keyboard trap on the checkout page template. This caused 12 support tickets in the last month alone that we had to answer with the same boilerplate. We've now fixed the issue and QA have confirmed it works fine. We haven't gotten a new ticket since we released so that's already saving us time and headaches. We've planned a few user testing sessions next week and we'll confirm the keyboard trap is gone.
For the customer
We've identified an issue on our web store checkout that prevented you from completing the purchase with your keyboard. We realise this caused undue stress and we apologise. Last week, we released a fix to this issue and we're now monitoring to see if everything works as intended for everyone.
Why is it important to do this properly?
If you're not talking their language, or worse not talking to them at all, you risk losing trust, not getting the resources you need to keep doing the work and accessibility becomes "their" problem instead of your responsibility. All the while, your users suffer because you're stuck in internal debates.
And lastly, don't talk about how many issues you fixed last release. Nobody cares. They care about progress and what it means for them. So it's better to talk about real indicators for progress, not vanity numbers.
Next week, I'll share six indicators of progress you can use.