Accessible software design doesn’t happen on accident. If I design based on my own instincts, the software will work great for someone exactly like myself — with all the same abilities and preferences. I can see the difference between red and green, so I wouldn’t think twice about putting those colors next to each other in a layout. It’s only when someone with colorblindness tries to use the site that it doesn’t work at all.

All good design starts with thinking about the audience, and accessible software design is no different. If, instead of assuming everyone would see it like me, I took the time to run my layout through color checkers for different types of colorblindness, we’d skip the problem above and anyone would be able to use the site.

As we work on making Table XI and our larger community more inclusive, we’re also working on making our products more inclusive. It’s not a huge extra effort to be empathetic and think through how someone with different experiences and abilities would interact with our designs. But it does make a huge difference to the people on the other end when they can navigate our products independently. We’re certainly not perfect, but we’re getting better at accessible web design every day, just by listening to the people we’re trying to serve. Here are a few of the things we’ve learned, and what to keep in mind when you’re building your own accessible software.

 

Defining your unique software accessibility guidelines

To build accessible software, you have to understand the limitations that many people navigate the internet with, and adapt to meet them. Then you have to understand the context that your particular audience brings to your design.

For the first, there are lots of resources. The Web Content Accessibility Guidelines from W3C is a standard — it gives you a great overview of how to make something useful for most people. There are also plenty of virtual and in-person groups for designers who want to focus on accessibility. I host a UX meetup group in Chicago, and it’s great for testing projects and getting feedback about designs when they’re in-progress.

For the second, there are no standards. The audience you’re trying to target will have its own unique references and experiences, and it’s your job to do as much research as you can to figure out how to build something that fits within that framework. Millennials, for example, may be familiar with all the visual shorthand of the internet — a hamburger to launch a menu, an x to close a window. Older audiences, on the other hand, may prefer to see those things spelled out. It’s not a disability we’re designing around, just a different life experience we need to understand, be empathetic to, and incorporate into our final design.

 

Testing for software accessibility with the people who matter most

All of the research in the world can’t replace the value of simply putting your software in front of the people who will ultimately be using it. You want to do as much research as possible beforehand, because that’s our job as designers, one, and two, so we can use the feedback we get during testing to refine the design, rather than redo it altogether.

Testing doesn’t need to wait until the product is done, either. No matter what stage of development you are in, getting some constructive outside feedback can offer insight. We periodically meet with a web accessibility group while we’re designing, for example, to get a greater understanding of how differently abled people use technology, so we can test features and learn from the tests others have run.

The closer you can get to your unique users, the more valuable your testing will be. Just be willing to let go of any assumptions you made based on research — the experience of real users should always win out.

 

Understanding accessible software challenges by looking at the real world

As you amass a list of the ways people experience the internet differently, it can start to feel overwhelming to design something that works perfectly for everyone. The truth is, you can’t. You can only design something that works well enough for the most people, and best for your target audience.

To understand how this works in practice, it’s helpful to think of a real-life example. Color-blindness affects how people see color in a whole range of ways, but one common way is by making red and green appear roughly the same. That’s kind of a big deal in a world where green means go and red means stop. Fortunately, road signs and traffic lights are designed with this in mind. By always keep the lights in the same place, people who are colorblind can know what “color” the light is, even if they can’t see it. The red of a stop sign may be imperceptible, but the shape and the language both communicate the same thing.

Great, accessible design should be as versatile as a stop sign — layered in a way that makes it useful to many without disrupting anyone’s preferred experience.

 

A few software accessibility best practices to keep in mind

While the best design will be unique to your audience, there are a few accessible design best practices that you should keep in mind on every project. Unsurprisingly, most of these are also just … design best practices. Keep these in your toolbox, and you’ll be better able to stay cognizant of other people’s needs throughout the design process.

  • Stay consistent within the internet. The reason the traffic light example above works is because red and green are in the same position on every traffic light. If some city planner decided to get creative and switch things around, there’d be a lot more accidents. You should design something that feels interesting and different, just not so interesting and different people are going to be perplexed.
  • Stay consistent within your design. Consider each design an ecosystem with its own rules to follow. Whatever style you choose for hyperlinks, text blocks or any other element to a page, keep it consistent. Breaking format can confuse and deter users from engaging with your page if the style shifts.
  • Make copy clear. Words are just as much a part of the experience as visuals. Make sure your copy is clear, engaging, and written with the audience in mind. This will be the primary way anyone with a visual disability navigates your site, but it’s also a big part of the way everyone navigates your site.
  • Use proper alt text and tagging. Anyone with a visual disability will rely on tools like screen readers to translate your design to audio. Just like the copy has to be clear, the images, navigation elements and buttons need to be clear as well. Making sure those elements communicate what they need to visually, and with text, will make your site useable.
  • Keep it simple. The fewer elements, the fewer opportunities to break your own system or introduce something that’s not accessible. Color is a great example — while there are plenty of color checkers out there, I also like to grayscale my designs. It’s a shortcut to see if my color scheme is clear and contrasting enough to still make sense.

 

With accessible software, good design is good design

Accessible design isn't anything more than being empathetic toward your users — a.k.a. design. The process of researching, understanding and testing with an audience remains the same, you’re just being more expansive in how you think about that audience.

The tips I’ve laid out here will only add to your design practice. Simple, clean, consistent design is versatile — it will be useful to as many people as possible without anyone feeling they’re getting a different experience.

In an ideal world, every product would work as well as a stop sign. Until then, we need to do our best to design for the most people in a way that feels accessible and elegant.

Read
Using the Google product design sprint process to get testable prototypes in a week