Three Myths of Accessible Product Development
Accessibility isn’t a development cost — it’s a business imperative.
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:
- Accessibility adds significant time and cost to a project
- Accessibility only helps a small fraction of the population
- There is no business case for accessibility
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.
1. Accessibility adds significant time and cost to a project
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.
2. Accessibility only helps a small fraction of the population
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.
3. There is no business case for accessibility
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:
- Accessibility extends the reach of your product. Inclusive design widens the company’s customer group to include the many people living with disability, permanent or otherwise (see Myth 2 above) as well as aging and multicultural populations (language localization can have a big impact here). In the case of web development specifically, everything you do to implement accessibility has a direct impact on Search Engine Optimization, enabling your product to reach a greater audience.
- Accessibility reduces maintenance costs. Much of what you do to implement accessibility improves code quality more generally. This doesn’t just mean fewer bugs (see Myth 1 above); it also means that your code is simpler, better organized, more modular, and more readable. This lowers maintenance costs, reduces bandwidth and server load, and makes the product more reconfigurable and receptive to future updates. A small upfront investment pays dividends in the long run. (More detail on the technical benefits of accessibility here.)
- Accessibility reduces legal risk. This is particularly important when working with clients who operate in the US, where web accessibility is mandated in civil rights legislation. (More information on legislation and policies in different countries here.)
- Accessibility is good PR. Thanks to the hard work of disability activists and accessibility practitioners, major private sector consumer technology companies are increasingly adopting a more aware and intentional attitude towards accessibility — and they want people to know it. (Apple’s accessibility marketing is a prime example.) From a marketing perspective, implementing accessibility will help companies keep up with the industry trend and mitigate negative PR that could come from creating inaccessible products.
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.
