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.
Carly Gerard says:
Great article, Denis! Many people will look to WCAG as the “gospel truth” for accessibility, so to speak, but even I have to remember that they are ultimately guidelines at the end of the day. I agree the better way to design with accessibility in mind is to consider how a variety of users will interact with a component/page/site. Well done sir :).
Denis Boudreau says:
Thanks, Carly. 🙂
You are absolutely right. Guidelines are really only guidelines, and in our noble, yet somewhat desperate quest for accessibility at all cost, some people tend to forget that this is all they are: recommendations, suggestions that can help make the web a less hostile place for some people, some of the time. And that’s great, but there’s so much more to it than what the WCAG working group could capture back then in the specification (hence WCAG 2.1, and whatever will follow next). A lot of site owners tend to develop a false sense of security when they think that their site has achieved WCAG compliance, and then are shocked when they still receive complaints about content not being usable by some.
This is not a new concept, but compliance != accessibility
I certainly recognize that measurable guidelines are needed, and WCAG does that amazingly well, but there’s so much that could also be covered and isn’t or could ever be, that I believe designers need to approach the entire challenge of digital inclusion much more holistically than WCAG will ever allow for. By providing designers with broader concepts they can apply, maybe, just maybe, we can help them be more successful in trying to do their part. And then everyone will benefit, both in the wild out there, and also in the lifecycles where these digital products are being developed.
Sheri B-H says:
I think there is an extension to that formula – compliance != accessibility != usability
Asha says:
A Great article and has a lot of good advice which we can follow !!
Regards,
Asha
Denis Boudreau says:
Thanks, Asha! Glad you enjoyed the post. Keep an eye out for me on Twitter (@dboudreau) over the next couple of weeks, as I’ll keep developing the concept and providing ways for designers to break down how these heuristics can be used for evaluation purposes.
Todd Kloots says:
Oh the sense of catharsis I had when reading this post! Thanks for writing this Denis. This topic has been on my mind for so long. Every time I see a blog post, Tweet or conference talk about a11y being easy the first thing I think of is the author or speaker has never worked on making a web application accessible.
I’ve always suspected a11y likely was easy back when the web was new. But the messaging from the industry never changed to match the increasing complexity. Which make sense I suppose. No one likes bad news/to hear things are going to be difficult.
I do certainly agree that leading with any guidelines is only going to set you and your organization up for failure as you’ll be more likely to be ticking boxes and less likely to consider the end to end UX for folks with disabilities.
Leading with design to understand and solve for the human problem resonates with my experience.
Rajesh Duggal says:
For my currently project at TD Bank we are leaving TD’s simplified accessibility info portal.. and instead I’m onboarding the project team deep into WCAG. Because since they, most likely, will continue to live and work in Canada, Ontario they will need to know how do AODA/WCAG for all projects for the remainder of their professional working careers. So they might as well start learning this stuff now. Not just for this particular project.. but for their decades long professional careers in Ontario.
Eva Anderson says:
For a number of years, I’ve worked on design projects for government agencies that required accessibility standards. WCAG can be overwhelming to decipher, and following the most recent 508 Refresh even moreso. These heuristics are a welcomed gift. Thanks for posting!