As designers, developers, and managers of digital products, we all know that accessibility is important. It broadens the reach of what we make and brings more people into the digital community. Yet between the competing priorities of product development, and in an industry where time to market is valued above almost everything else, the simple fact is that accessibility is often sidelined or overlooked. This, I hope to show, is a mistake, and a costly one too.
Based on my own experience advocating for accessibility, there seem to be three big misconceptions that push it into the backlog or take it off the table entirely. They are as follows:
Each of these myths is false, and works to dissuade businesses from investing in, incentivizing, or prioritizing accessibility. Let’s go through these one by one.
To be sure, learning how to make a product accessible will add time at first. If the designers and engineers in your organization aren’t familiar with implementing accessibility best practices, they’ll need to be trained.
Yet as these practices become second nature, the additional effort required approaches zero — and in the long run, they actually save you time. That’s because a lot of the bugs that QA tests for in a digital product (bugs which then have to be fixed) wouldn’t be there if the product were made with accessibility in mind in the first place. And as all developers know, it takes a lot longer to fix code than to get it right at the outset.
Let’s take an example. If you’re building a website with accessibility in mind, then you’re using proper semantic elements whenever possible. But if you build a site using unlabelled divs throughout, or structure the DOM without a logical tab order, then you’re going to have to refactor and rewrite large sections of your code base to make it pass QA.
QA fixes of the “accessibility sort” aren’t quick to remedy either; they’re usually systemic and require considerable reworking. In fact, many of these bugs require deep UI design changes as well, so now you’ve got developers and designers back-pedalling to undo the error. And if one of those teams is external, that’s a lot of coordinating.
To be fair, not all QA standards are that rigorous, and some products can get out the door with the aforementioned kinds of bugs. But let’s say you don’t take the extra time required to make your product accessible, and all of a sudden your product takes off. Now lots of people are using it and there’s pressure to make it accessible — even an expectation that it be so. If you built your product without preparing for this, then going back and fixing it to make it accessible is a massive endeavour.
You’re going to have to make your products accessible at some point or another. The only question is when.
Implementing accessibility at the beginning rather than at the end reduces the amount of redesign and refactoring required, dramatically increasing project speed overall. Because the reality of product development is that you’re going to have to make your products accessible at some point or another. The only question is when.
It’s easy to think that accessibility only applies to a tiny number of people. But the reality is that roughly 1 in 7 people are living with disability, visible or otherwise. And while there is a lack of reliable data on how many people are benefitted by accessible digital products, many of those living with permanent visual, auditory, motor, and cognitive impairments will be in a better position to reap those benefits if your product is made accessible to them.
The population myth starts to unravel further when you understand that beyond permanent impairments, accessibility also benefits people with temporary and situational impairments — in other words, everybody on the planet. Examples of temporary impairment include injuries, surgeries, or medications that have cognitive side effects, while situational impairments are consequences of specific environmental conditions such as using your phone on a bright day or simply having one’s hands full.
Whatever the category of impairment, people stand to benefit from accessibility. A person driving their car (situational), a person with an injury to their arm or hand (temporary), or a quadriplegic (permanent) all gain from the inclusion of voice interactions into a product. While it makes the experience more convenient for someone with a situational impairment, it will help someone with a permanent condition live a more independent life.
Accessibility also benefits people with temporary and situational impairments — in other words, everybody on the planet.
Take visual impairments. Appropriate contrast and text size in the design of your application directly benefit individuals with permanent visual impairments, but also make it a lot easier for someone to read if they are outside using their phone in direct sunlight.
The point is that most of the attributes that make a product more accessible to some also make it more usable for all. In this sense, accessibility is a form of usability. If you expand your scope to include temporary and situational impairments, it’s easy to see just how many lives an accessible product can touch.
Anyone advocating accessibility in their organization will at some point need to address its business value. And for business-to-business companies, a team that can communicate the business value of accessibility to its clients is equally invaluable, because they can set accessibility as an expectation at the beginning of the project.
Accessibility is a viable business priority for the following four reasons:
For a more comprehensive overview of the many business benefits of accessible web development, see the W3C content on the business case for web accessibility.
Digital product companies work with complex technologies, high customer expectations, and the need to move fast — factors which combine to make product development a difficult undertaking. In such a high-pressure environment, it’s easy to see how accessibility can fall through the cracks. But once you understand that accessibility reduces overall development time and maintenance costs, makes it more usable for a greater number of people, and increases business viability, its benefits are hard to deny.
If you and your organization are committed to product quality, to building better products, accessibility isn’t just nice to have. It’s key. Committing to accessibility may not be easy at first, but better products are always going to be hard, and that’s exactly why we should be doing it.