A little while ago my friend Wendy, a writer, messaged me for some advice. “How can I convince my colleagues that designing for accessibility is a must, not a maybe?”
Yes, “You will ultimately get sued” is a pretty good reason, but she wanted to find some positives. As an interface designer, I was more than happy to respond – accessibility in design is one of those things I rarely keep quiet about. For many companies, it’s an afterthought, or left completely out of the design process. But the way I see it, successful design does two things: the first is making something deliberate (to “render intent,” as Jared Spool writes), and the second is improving the human experience. In other words, to design is to intentionally better people’s lives in large and small ways. If you’re leaving some people out of that equation, you haven’t succeeded.
So, you or someone in your organization isn’t sold on designing for accessibility? You need to read this.
Considering the accessibility (or “a11y,” as the kids say) requirements of your audience is absolutely part of designers’ jobs. In fact, it’s a core definition of great design, in general.
Successful designers make conscious (and unconscious) decisions about how they display and convey certain intentions to certain groups of people. If what a designer comes up with doesn’t reduce a point of friction in their audience’s everyday lives, doesn’t improve how individuals live and communicate with each other, or can physically, emotionally, or cognitively harm someone, then that design has failed. Period.
Despite designers’ best intentions, there will always be a situation or context they have not considered. This happens because the lens through which we see the world skews a certain direction: our past experiences, biases, and lack of awareness become this lens. It isn’t a malicious lens, generally; we simply all have blind spots. But the very best designers are always looking for new opportunities to fill these blind spots by forcing themselves to consider the cases that may have been overlooked — we call these “edge cases,” or, even more aptly, “stress cases.” What are the limits? What are the extremes? What could cause someone distress in any given situation?
To understand how audiences use products, designers do user research and testing. In doing so, they define the considerations that must be made in order to improve the human experience.
“Inclusivity extends beyond acceptance and lets everyone thrive. That’s where the real magic happens.”
Diversity in a design environment is also crucial: by surrounding ourselves with people of different views and backgrounds, we can cover more of our blind spots and provide more thoughtful solutions. Diversity needs to extend beyond race, gender, sexual orientation, heritage, beliefs, and cultures to include physical and cognitive capabilities. Considering a wider range of who our users are, where they are from, what tasks they are able to perform, how those actions are performed, and what their perception of those things will allow us to deliver on their basic requirements.
The best designers also look inside situations and environments that focus on inclusivity — the next step after diversity. Inclusivity extends beyond acceptance and lets everyone thrive. That’s where the real magic happens.
When thinking about accessibility, in my experience, the majority of able-bodied folks often jump straight to thinking about the “obvious” things that would limit one’s capabilities: wheelchairs, vision impairments, and so on. But that’s not always the case. Take, for example, a father holding his child in one arm, using his mobile device in another; or a woman who just received laser eye surgery and is blind for the afternoon. These are cases where both users are temporarily physically limited yet still expect to interact with the world as they regularly would. If we design for the stress cases and scale from there, we can create frictionless experiences for everyone, regardless of their situation, context, or ability — temporary or permanent.
Money Well Spent
A common counterpoint to designing accessibly relates to bang-for-buck: “Less than 1% of our users are blind, so why should we spend money on something so few people would be affected by?” That type of thinking occurs when accessibility is interpreted as a feature or enhancement and not as a value.
“Why wouldn’t you make the best possible product for the largest amount of people you can?”
Accessibility is a principle that should be applied at all times to bring in a larger user base, increase the time using your product, along with many other benefits. However, in the real world, on a real project, there may not be enough time or resources to do everything. In this situation, user research and testing are often the first to get dropped. In that case, it falls on designers to make sure they deliver quality products to the biggest group.
Here are the 7 areas I’ve found most effective to focus on when you’re in a crunch:
- Color accessibility: Running your visual designs through a color-blind test is really fast. When selecting colors, be sure to check the contrast ratio of the foreground and background using a tool like Lea Verou’s Contrast Ratio or WebAIM’s Color Contrast Checker. If you’re looking for more information, Geri Coady’s book Color Accessibility Workflows is a great resource.
- Touch target sizing and positioning: Reduce UX friction by making sure your touch targets are at a minimum 44–48px. We want to make sure fingers of all sizes can accurately tap around on mobile devices, and that the content within tappable elements is comfortably readable at a typical viewing distance for any given device. Furthermore, where we place elements in an interface matters too. Can people reach far away elements? How much effort are users exerting? These are questions we need to find the answers to.
- Proper HTML: Writing semantic HTML really isn’t that difficult. It means using the proper elements for their proper contexts, such as <article>, <aside>, <nav>, <section>, etc. It also means using using WAI-ARIA role attributes for older browsers or areas without an explicit HTML tag.
- Check keyboards on inputs: There are several different types of keyboards available to users on mobile devices, each designed for a specific context. See what keyboards are available and learn how to implement them correctly — it’s pretty easy. Some users are incapable of using keyboards — have you considered how they will use your product? Every day we’re figuring out new ways to interact with products around us; keyboards are being used less and less in favor of newer input types like voice… have you considered this situation?
- Avoid hiding content: As a general rule, meaningful content should be exposed by default. Don’t hide behind a rollover or hover effect! People who use your product without touching it aren’t able to access this information — neither can mobile users. Hiding content behind modals or inside accordions are great for focusing users’ attention, but can be problematic; be sure to test!
- Use a screen reader: Once your design has been implemented, do a thorough pass using a device screen reader; it’ll help you identify areas that have been overlooked. Every phone has a built-in method of reading the contents of a screen, like Android’s TalkBack and iOS’s VoiceOver.
- Double-up on state changes: Often times one type of indication, whatever it may be, is not enough. Borders, shadows, background and foreground colors, iconography, text weight, text styles, positioning, animation — these are all visual cues that can be combined one way or another to represent status and state change.
Ideally, there would always be enough time to research and design properly. That begins by putting on your sales hat and convincing clients and stakeholders that accessibility is important for their bottom line, for the general user experience, and for all of their users – oh, and that they should be paying for you to do it properly.
But even in the smallest cases, there is always an opportunity to do at least some sleuthing. (Erika Hall’s Just Enough Research is a fantastic, easy-to-digest resource that can set you on the right path.) My colleague Mitch Lenton, for example, recently did some guerilla user testing at the mall close to our office about some new features he was working on. He didn’t have a budget for anything official, but even collecting initial remarks from a diverse group of folks helped establish actionable items and reveal blind spots.
What, Not Why
At Mobify, it’s a core belief that accessibility is everyone’s responsibility – just as web performance and user experience are. But at the end of the day, reasons for prioritizing accessibility don’t matter as long as the results are there. Some messages resonate more strongly with certain people: “Let’s do it so we don’t get sued” is fine for those folks. I’m reminded of this passage from Slack’s take on diversity:
“Everyone at Slack agrees that diversity and inclusion are important, but not everyone at Slack agrees about why. Some people here believe diverse teams produce better business results. Others see the issue in terms of social justice and addressing inequality of opportunity. And some just don’t want to work at a place where the population is overwhelmingly homogeneous. All are valid and important reasons. At the end of the day, the ‘why’ isn’t important when we all clearly agree on the ‘what.'”
When designing digital products like website and apps, taking accessibility into consideration — just as one would with color, layout, typography, speed, performance, and everything else a designer thinks about — not only enhances value for those who want it, but sets a clear baseline of which audiences are deemed worthy of our time and attention. Or, as Microsoft declares in their Inclusive Design principles:
“As designers, it’s our responsibility to understand the power of the interactions we design for people. We design to embrace the things that make us human. It’s what drives us to create a world that makes lives better. The result is technology that’s inclusive.”
So, I ask: For whom will you create?