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.
