We commonly see “accessible” features in public spaces: wheelchair ramps, curb cuts, automatic doors or braille buttons. We also see where the design met the rules but was hardly accessible or inclusive, like a ramp that was too steep or an elevator door that was too narrow.

The same problem exists in software design. Tools often follow the letter of the law but do little to solve the accessibility and inclusivity needs of those who aren’t the “median user." There may be many reasons teams miss the mark on accessibility, and it usually comes down to believing one of three myths: Accessibility is a fringe need, it takes too long or makes design uglier.

It’s convenient to think that only a small number of users have a disability. However, think of this definition by WHO, and the number of people this represents. They define a disability as “a mismatched interaction between the features of a person’s body and the environment in which they live.”

Have you ever been driving and needed to access your maps? That’s a mismatch. What about trying to see your screen or phone with fogged glasses or in full sunlight? Think about a parent using their phone one handed while they carry a child. Looked at this way, it’s clear that everyone experiences a disability at one time or another. It’s helpful to think of disability at three levels: permanent, temporary or situational. Some users have permanent disabilities, many users experience temporary disabilities and everyone has situational disabilities.

So who do you design for? Too often, teams picture in their mind a median user. While this can be a helpful exercise in marketing and sales personas, in terms of usability, this person doesn’t exist. The Airforce learned this the hard way. While redesigning the seats for their planes, they analyzed their pilots and determined the median height before creating what they thought was the perfect chair. Soon after, and to their bewilderment, crashes increased significantly. Why? Because no one was exactly the median height. Most were taller or shorter. They went back to the drawing board and designed an adjustable chair that fit the extremes.

When you build software, don’t design for the median experience. Design for the extremes, and you’ll end up covering the median along the way.

One of the strengths of software teams is how lean and agile they are. It’s ingrained in every startup to build the minimum viable product. Unfortunately, this often pushes out minimum accessible products as well. You know from Myth #1 that more users experience some sort of disability accessing your software than you might imagine. But why else should you take the time to build truly inclusive software?

Let’s start with the carrot, and then get to the stick. The spending power of disabled people is huge and getting bigger at $21 billion. While there’s obviously overlap, that’s bigger than the spending power of the African American and Latino segments combined. There’s a large market for accessible software products.

Now to the stick. Designing for accessibility is the law! The number of ADA lawsuits has doubled in the last 10 years. Beyonce lost a lawsuit because a blind person couldn’t order from her clothing line. Dominos also lost a big case because it was difficult to order online. If you haven’t been burned yet, chances are you will be in the future.

As Frank Lloyd Wright said, “You can use an eraser on the drafting table, or a sledge hammer on the construction site.”

You may remember an article from a few years ago published on Wired titled “How the Web Became Unreadable.” In it, the author describes how he thought his eyesight was going south. He then uncovers some of the aesthetic design choices that have made reading articles on a mobile phone almost unbearable, things like small font sizes, grey font color and generally poor contrasts.

In other words, just because a design looks great doesn’t mean the user experience is any good. The best design is the one that works the best, not the one that looks the best. Design trends are going to come and go. But accessible design is a hallmark of great software.

Accessible design can become the norm. Julie Rodriguez and Piotr Kaczmarek wrote a book called “Visualizing Financial Data.” Piotr is colorblind and purposefully created graphs and charts with clean typeface and strong contrasting colors. Their book is an industry standard thanks to how legible they were able to make their visualizations.

Your software won’t be perfectly inclusive overnight. No one even expects that. But there are some steps your team can take to improve the accessibility of your software.

1. Diversify your team. If you’re building for accessibility, hire disabled developers or designers. You can also take steps like increasing user research or taking on a disability consultant. Put yourself in the shoes of someone with a permanent, temporary or situational disability. In other words, design with disability, not only for it. 

2. Involve your whole team. Some of the breakdown in achieving quality design happens because designers and UX researchers aren’t working closely enough or early enough with developers. Get everyone in on the process early. 

3. Advocate for change with business leaders. Help them understand the market potential and benefit to every user. 

4. Use the great resources at your disposal. The IBM and Microsoft accessibility toolkits are a great place to start. Vox also has a great resource if you’re designing media or content. And if you’re working in a strict compliance environment, check out the 18F Government guidelines.

==========

Want a deeper dive into how to build accessible and inclusive products? We’ve got you covered. Watch Raquel Breternitz’s latest webinar, Inclusive, accessible principles for product teams.