From 24 Accessibility: https://www.24a11y.com/2018/unlocking-accessibility-for-ux-ui-designers
Tap, tap, one, two… is this thing on?
Ahem … My dear designer friends, I have a confession to make, on behalf on anyone who’s ever worked in the field of digital accessibility. We, the accessibility community, have been lying to you for the better part of the last twenty years.
You see, all of this time, we’ve been repeating that accessibility, or a11y for short, was easy. Somewhat hinting that if you didn’t embrace inclusion through the implementation of the Web Content Accessibility Guidelines (WCAG) in your designs, it was probably because you couldn’t be bothered about people with disabilities on the Web. Or worse, that you just didn’t care about inclusion. In other words, that you were a despicable, selfish human being. In this era of division and pettiness, I’m here to shine a beacon. They say the holidays are a wonderful time to ask for forgiveness. So I am coming bearing gifts, in the hope that you can, one day, forgive our naughty little selves.
First, the shocker…
Web accessibility is hard. It’s complicated. It’s got an incredible amount of moving parts. Worse, not all of it is even relevant to you, as designers. I realize most accessibility experts you ever crossed path with probably told you otherwise. That you needed to understand WCAG in order to do your job. That you absolutely had to learn about the different Success Criteria. That it mattered for you to figure out this whole thing about levels A versus AA and AAA. But you won’t hear any of that today. Huh huh, that’s right. Not from me, my dear designer friends. I am here to tell you otherwise.
You don’t need to care about all of that WCAG stuff
WCAG is a great exercise in theory. And for those of us who work in the field, it is immensely valuable. But you’re not one of those people, and you have bigger fish to fry. There are so many areas you already have to try to stay on top of, with artificial intelligence, conversational interfaces, asymmetrical layouts, optimistic user interfaces, user-responsive design, particle backgrounds, and more! Besides, in your down time, why would you ever want to catch up on your WCAG documentation, when there are so many great series on Netflix waiting to be binge watched? I hear Claire Hale Underwood is killing it.
So yeah. Accessibility is hard. And it gets super complicated fast when you want to do it right. I guess I’m just tired of accessibility people trying to con you into thinking otherwise. Accessibility is hard, not so much because of how complex each Success Criteria is. Some of them are a bit cryptic, granted. Yes, I’m looking at you, SC 4.1.2. And some might even argue that WCAG 2.1 doesn’t make things any easier, either! After all, there’s a reason why hundreds of “Understanding” pages are needed to explain what WCAG is really about. And we still wonder why everyone else cringes at the idea of learning about accessibility?
But if it was only about language, maybe it wouldn’t be so bad. What really makes accessibility so hard for most people is the sheer amount of considerations found within each guideline, each Success Criteria, each special need arising from users with particular disabilities and contexts. It’s hard because, when you start adding up all of the rules, account for all the subtleties, pay attention to all the details and consider all the different contexts of Web use, the list adds up so fast that you cannot possibly be expected to wrap your head around it. Everything spins way too much.
So you do what most people do. You grab a concept here and there, like contrast and maybe even use of color, you memorize that blind people have no use for a mouse, and you more or less consciously just push back on the rest of it. You know, for now. You’ll do a bit more on the next project. I don’t blame you. As I said, this is complicated.
What you need is a Babelfish for designers
Have you ever read Douglas Adams’ “The Hitchhiker’s Guide to the Galaxy”? In this intergalactic epic, the Babelfish is a fictitious alien fish, that performs instant translations. Think of it as your low-fi, 1978 version of the Pixel Buds. The Babelfish would often come in handy to translate WCAG speak into a set of requirements that actually make sense.
UX practitioners, UI designers, accessibility specialists. We all design parts of that experience, and we all want and care about the same things. We want to POUR our best into our work (see what I did, there?), so we create better user experiences for the people who visit our sites, applications, and products. We care about contributing to the best quality of work possible.
As designers find themselves drawn to inclusive design principles, many of us feel accessibility stifles creativity with its overly complex set of seemingly arbitrary rules that appear impossible to apply to real-life projects. But what if, instead of approaching accessibility from a technical perspective as most of us have always done, we started looking at it as a set of heuristics that can be applied broadly to design? What if we developed general rules of thumb that naturally fit into existing frameworks practiced by many designers? What if we considered the possibility of only tackling some of those heuristics at first, knowing we could progressively add to our list as time goes on?
We already know that people with disabilities account for about 15 to 20% of the world’s population. That’s a lot of people. As we age, we all develop issues that bring us closer to the experience of those who are disabled on the Web. We are now living longer lives. As a result, accessibility is clearly – and will continue to be – a growing need. There’s no better person in the project lifecycle than the designer to tackle this head on. Yet, the tools available to you to be successful in doing so are severely limited.
It boils down to this: if designers check their work for accessibility, fewer large accessibility problems will be encountered down the line. Examples include but are not limited to choosing an accessible color palette with good contrast, writing meaningful alt text when imagery is selected, or designing a visible focus ring on active elements for users who navigate entirely with a keyboard. In many cases, remediating issues later on in the development process ends up being much more expensive and time-consuming than catching them early on. There are dozens of such examples or situations where a designer can proactively contribute to easing the development process and create an accessible experience for everyone.
Enter accessibility heuristics
So here’s my gift to you. A set of 10 cards, that basically translate all the relevant parts of WCAG in heuristics you can more easily work with. Most of you are already familiar with the concept, thanks to the great work from Jakob Nielsen, back in 1995. It’s worked great for usability for over 23 years, why not learn from it and apply something similar to web accessibility? I think it’s long overdue. Of course, these heuristics are largely inspired by WCAG. They ultimately map to relevant parts of the guidelines found in the W3C accessibility documentation. But research has shown that approaching accessibility through the lens of these heuristics is better adapted to how we think as designers. Hopefully, you will agree, too.
01 – Navigation and Wayfinding
Users can easily navigate, find content, and determine where they are at all times within the system.
02 – Structure and Semantics
Users can make sense of the structure of the content on each page and understand how to operate within the system.
03 – Contrast and Legibility
Text and other meaningful information can be easily distinguished and read by users of the system.
04 – Language and Readibility
Content on the page can easily be read and understood by users of the system.
05 – Error Prevention and States
Interactive controls have persistent, meaningful instructions to help prevent mistakes, and provide users with clear error states which indicate what the problems are – and how to fix them – whenever errors are returned.
06 – Predictability and Consistency
The purpose of each element is predictable, and how each element relates to the system as a whole is clear and meaningful, to avoid confusion for the users.
07 – Visual and Auditory Alternatives
Purely visual or auditory content that conveys information has text-based alternatives for users who can’t see or hear.
08 – Multiple Interaction Methods
Users can efficiently interact with the system using the input method of their choosing.
09 – Time and Preservation
Users are given enough time to complete tasks and do not lose information if their time runs out.
10 – Movement and Flashing
Elements on the page that move, flash, or animate in other ways can be stopped, and do not distract or harm the users.
Each one can be broken down into a series of contextualized considerations and potentially open just as many cans of worms. That’s going to be a topic of discussion for another day. In the meantime, if you want to learn more about those heuristics and how they can be applied to your designs, make sure to follow me on Twitter at @dboudreau, where I will keep expanding on the concept as part of my life-long journey to break down accessibility by roles in the project lifecycle.