When customers start complaining because the latest release introduced some accessibility barriers, it's easy to blame the work done in the last sprint.
"What if we didn't change those colours last minute?" or "what if we tested with some real users?"
Except it's not that last minute decision that did it. It's usually the first or the second or the tenth decision that led to this problem. Or, more realistically, the sum of all the seemingly small decisions you made along the way where you ignored accessibility.
In the rush to push out that new feature, accessibility got left behind. It wasn't intentional; it's just that you had other priorities. But here's the kicker: those seemingly minor tweaks or additions can snowball into major accessibility issues.
Let's say you wanted to redo your website's navigation menu. You wanted a better user experience and to make it more visually appealing. So, you decided to implement a modern design with fancy animations and dropdowns. It looked great and worked great during internal testing.
But underneath the surface you had a host of accessibility problems.
First off, the new menu relied heavily on mouse interactions, making it difficult for keyboard-only users to navigate. Then, the colour scheme you chose looked stylish, but the low contrast made it impossible for users with low vision.
So now your customer support is fighting off complaints and it looks like you did more harm than good with the new menu. You started off with nothing but good intentions and ended up alienating a significant portion of our user base.
But was it really this new menu that highlighted the accessibility issues?
Or was it:
- the lack of awareness in the team,
- no accessibility knowledge, and
- no processes to incorporate accessibility earlier in your SDLC?
So what do you do now?
You could be the hero, save the day and fix the menu. And you should definitely do that. But don't let that be the end, because that overlooks the real issue.
Start thinking about accessibility earlier. Ask better questions to uncover what might cause a barrier and when. Train your team to at least have the awareness of potential pitfalls. You'll be avoiding a lot of costly redesigns and rework and have fewer critical accessibility issues in production.
If you want to avoid starring down the barrel of a gun every time you release new features you'd be better off creating the conditions for success, rather than just saving the day today.