Web Accessibility: What You Say vs. What I Hear
My background is in web design and development. These days, I’m an Accessibility Specialist advocating on behalf of the user. I use assistive technology to audit, review, and examine software the way a person with a disability might use it. I then work with product teams to identify and resolve these issues.
And I’ve noticed a recurring theme.
Issues identified through assistive technology such as screen readers are often treated as bugs—backlogged and forgotten in lieu of new feature development.
Let me be clear: I think looking at accessibility this way is all wrong.
Accessibility issues are missed requirements
Looking back, I regret much of my attitude and inexperience in my early days as a developer. Now I try to bring a new perspective to help people avoid my past mistakes. When it comes to implementing changes, I’m often met with resistance—from designers, engineers, product managers, and more.
But let’s look at some of those objections in a different way…
What people say: “I didn’t know this had to be accessible.”
What I hear: “I didn’t know this had to work.”
When we don’t consider accessibility, some people are simply blocked out from content that we put together and experiences that we’re building. What’s the point of designing it if we aren’t designing for as many people as we can? Designing for accessibility may be the only way some people can experience what you’ve built.
What people say: “How do we get this to pass ADA?”
What I hear: “We’ll build the very best product we can for most people. But when it comes to the people who need us the most, let’s do the minimum.”
Fair question, it’s important to know the legal implications of what we’re building whether it’s a brick and mortar, physical experience or software, but as accessibility consultant Austin Seraphin says, accessibility is not usability.
Meeting legal compliance is doing the bare minimum to avoid lawsuits. Ethically, we should strive to do more. Having done design and worked with some very talented people, I’ve seen that so much thought and consideration goes into crafting an experience. But sometimes when it comes to accessibility, it’s about checking a box. If you don’t normally do the bare minimum, don’t give your customers with disabilities the bare minimum.
What people say: “I know this is an issue, but we don’t have capacity to work on it now. We’ll create a user story and put it in the backlog for prioritization.”
What I hear: “I know my product is useless to some people, but we have things we deem more important to do for the foreseeable future.”
The original statement is problematic. To me, it’s the software development version of, “we should really hang out sometime!” with no further action taken. Make accessibility a priority.
What people say: “Is this really an issue?”
What I hear: “This problem doesn’t affect the majority. Should I be concerned with the minority?”
Humans are skeptical by nature, but disbelieving something does not make it non-existent. If you can’t acknowledge or understand there is a problem, it doesn’t make that problem go away.
What people say: “This feature is going away soon. Do we have to fix it?”
What I hear: “If this were any other high priority issue blocking most other users, we’d fix it.”
Modern digital experiences are constantly changing and ever-evolving. Even when working on one product, we’re constantly improving it. New features are added; old ones are taken away. It’s not an excuse to keep delaying things that might block people from accessing what we’re building.
This is a tough one to make a case for. I understand it does not make sense to devote resources to a previous platform, but we have to be certain its replacement does a better job. Until you’ve cleared a path, people must live with the obstruction you’ve left in their way or move on to something better-designed to suit their needs.
Avoid creating barriers for people
While the following list isn’t comprehensive, it could be a starting point for thinking about accessibility in your work and organization. Consider how you could unintentionally make it difficult for people to access your content and begin by shifting your perspective.
- Think about accessibility from the very beginning. Communicate it across business, design, development, and testing.
- Make accessibility a priority, a business case, and a part of your organization’s definition of “done.”
- Include people with disabilities in your user personas and conduct research and studies with real people.
- Make sure everyone gets accessibility training. Learn how to use assistive technology.
- Think about multiple methods to convey information and interact with user interface.
- Apply proper keyboard support and think about tab order. This will ensure a baseline level of accessibility for various assistive technology.
- Design and develop according to the latest standards.
- Create internal accessibility standards and requirements.
Let’s change the dialogue around accessibility. People want to hear what you’re saying.
