If you have been working with accessibility on the web, you’ll know that the current Web Content Accessibility Guidelines (WCAG version 2.0) have been around since 2008. In those nine years, the web and the way we interact with it has changed — a lot. Since version 2.0 was released the smartphone market became accessible to developers with the App Store, Google Chrome 1.0 was released, and GPS was starting to enter consumer electronics. That’s an incredible amount of change, and the WCAG needs to keep up.
This September, a first draft of WCAG 2.1 was released by the working group overseeing the updates which included an additional set of 21 new success criteria to help content and application creators accommodate users with different needs. These new success criteria focus on the usability of these new technologies for the great diversity of users that are active on the web.
With this focus on usability, I found that the majority of the WCAG 2.1 success criteria fit into Nielsen’s 10 Usability Heuristics. Those heuristics are a valuable guideline for interaction design, and can help us make usable products for everyone. (Read the full set of Nielsen’s Heuristics from the Nielsen-Norman Group here.) I strongly believe in the tie between accessibility and usability when creating content for the web. You can create beautifully usable and accessible content by following these Heuristics, with a consideration for the needs of users with assistive technology.
Having worked in the world of accessible web for quite a while now, I know it can seem daunting when you first look at the criteria that need to be met. The good news is, for the most part it’s very easy to implement any changes you need to make to meet the criteria. But all the same, I’ll go over the 18 new success criteria for Levels A and AA, and show you how they can be considered as examples of five specific heuristics. In fact, if you’re already following these five specific Nielsen Usability Heuristics, you may already be addressing the new criteria coming into WCAG 2.1.
*Note: This article was written based on the WCAG 2.1 Working Draft 12 September 2017, which is available here. If you’re reading this at a later date, some criteria may have changed.
The Criteria and HeuristicsUser control and freedom
“Users often choose system functions by mistake and will need a clearly marked ‘emergency exit’ to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.”
These success criteria focus on preventing users from being stuck in a state or triggering one accidentally. If content appears on hover or focus of a cursor, it’s easy for the user see how they got the content got there and return to the previous state. Similarly, if a user accidentally triggers an action, they’re able to reverse it as needed.
“Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.”
This group of criteria focus on design patterns that frequently cause users to slip up. By solidifying the acceptable target size for triggers, and increasing the suitable contrast for typographic or graphic elements, you’re allowing users to more easily identify and interact with elements.
“The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.”
I found this pair of criteria to be the most intriguing. This heuristic suggests that users don’t have to guess or remember the state of the application, something that becomes even more challenging if you’re working with users that have mental or cognitive barriers. So the first criteria is simple — inform the user if something in the interface has changed. Don’t make them dig around for it.
The second one enforces the ability for users to use alternatives to remembering a password for authentication. The new (anti-) pattern of disabling password managers is not compliant with the simplest level of accessible development. Additionally, I’d interpret this as encouraging alternative ways for a user to authenticate, such as through social logins or easy password reset links such as found in Slack.
With this one, I’d like to point out that this doesn’t actually reduce the security of an application. There needs to be a balance struck between security and usability. If you force users to remember a password without the assistance of a password manager and do not provide an easy way to recover from a forgotten one, they are forced to find alternative solutions to retain the password. A sticky note on a computer monitor, for example.
Flexibility and efficiency of use
“Allow users to tailor frequent actions.”
- 2.6.2 Orientation
- 1.4.10 Zoom Content
- 1.3.4 Purpose of Controls
- 1.4.13 Adapting Text
- 2.5.2 Concurrent Input Mechanisms
This set of criteria really focuses in on allowing users to control, customize, and adjust your content to work with their own environment. Tying one specific interaction to one specific input mechanism, such as shake-to-undo, is no longer reasonable in a world of such diverse methods of interaction. Your content could be accessed by someone using a tablet, a smart watch, or even eye-tracking devices, and so we must be agnostic and flexible with our interfaces. As such, these criteria emphasize that while you can design for one mode of interaction, such as a touch screen, you can’t block other modes.
It’s important to note: while alternative input mechanisms have been used with assistive technology for years, we’re just seeing this diversity of input mechanisms in the more mainstream technology. It’s outdated to assume a keyboard and mouse, or even a touch screen, is available to the user accessing our content, quite frankly.
“Dialogues should not contain information which is irrelevant or rarely needed.”
I like to group these under the “Less is more” category. Web content creators tend to get very excited about all of our new toys, and we like to play with them all at once. Real time updates pushed to your phone, hardware accelerated animations, asynchronous communication, breakpoints specific design. Things can get out of hand. By allowing users to pause or reduce animations, we can allow for a more controlled experience. Interruptions, such as pop ups or notifications, are kept to a minimum. And — this one I love — if the visual interface shows a label for an element, assistive technology has access to the same word for label.
While there’s still some time before these new criteria fully join the WCAG, there’s work that you can start on now.
If you’re not familiar with these heuristics, take a look at them and see where your application follows or diverts from them. By improving usability, you can make your content more accessible to a variety of users.
If you’re not already WCAG 2.0 compliant, consider an accessibility audit. The WCAG 2.1 only adds new items to the guidelines, so you won’t lose anything by improving your accessibility now.
And finally, these guidelines are still going through review, so if you do have any feedback the working group is looking for it! You can submit your feedback to the WCAG 2.1 right on GitHub.
Improving the web for everyone is our passion— if you’re interested in making the web work better, apply to join our team here.