How to Describe Complex Designs for Users with Disabilities
You’re a developer who has just been handed a complex design spec. You know the designs support accessibility because your UX team read a Medium post about accessible design a few months back. It’s now up to you to build an accessible experience, but where should you begin?
There is the WCAG 2.0, which is widely respected as “the truth” as it relates international accessibility standards. There is also the WAI-ARIA specification which is an important part of any accessibility focused developer’s toolkit. Going back in time, there’s the U.S. Federal Government’s standard, Section 508 of the Rehabilitation Act.
While not known for enduring relevance, the technical accessibility standards in Section 508 contains one very sage suggestion. It states that,
“… sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology.”
Originally written for software, these words are even more relevant today given the prevalence of web based applications. They describe the type of information users with disabilities need in order to successfully complete a task. This could be a blind user with a screen reader, a voice input user with a physical disability, or any number of other types of users with a variety of assistive technologies.
The basic fundamentals of making any interaction accessible with both the keyboard and for screen reader users comes down to providing three basic pieces of information: identity, operation, and state.
Users interacting with an element as basic as a checkbox, or as complex as drag and drop experience, have to consider these three questions:
- Identity: What am I interacting with?
- Operation: How do I use this thing?
- State: What is the current status of this thing?
A Closer Look at Checkboxes
A sighted user is given many visual cues related to identity, operation and state. Let’s take a look at a simple checkbox as an example.
When I see a square next to the words, “I agree to these terms and conditions”, I’ve identified a checkbox.
I know how to operate the checkbox, by clicking on the square. Doing so will toggle it from checked to unchecked.
If I see a checkmark inside of that square, I know that its status is “checked”.
How would a blind user obtain this information?
“I agree to these terms and conditions. Checkbox, Unchecked. Press spacebar to check.”
If a screen reader reads this to a blind user, they are given three important pieces of information.
- The identity of the object: a checkbox to declare whether or not I agree
- The state: unchecked
- The operation: pressing the spacebar will toggle the state
With this in mind, let’s consider three methods, from most preferable to least preferable, to provide identity, operation and state to assistive technology: using native controls, using ARIA, and as a last resort, getting clever with hidden text and live regions.
Native Controls
Native controls such as form controls and buttons are always going to be the best option. In the example above, a real checkbox is ideal, since it does all of the work for you. You don’t have to create the operation using JavaScript, the checkbox already identifies itself and its state, and furthermore, people know how to use them.
For more complex interactions, such as drag and drop, consider if a native element can be used behind the scenes. Consider resizing the width of columns in a table:
A slider or range input is the perfect native equivalent for this behavior and it provides its own identity, operation, and state.
This can be visually hidden using CSS, while still left available for screen reader users. Synchronize its value to the width of the column and a blind user gets to interact with a familiar form control. A sighted user will still drag and drop as expected.
WAI-ARIA
In places where using a native control is not possible, follow the ARIA (Accessible Rich Internet Applications) best practices for common design patterns such as menus, dialogs, and autocompletes.
These guidelines are written so that UI patterns not available natively in HTML will still properly identify themselves to assistive technology users.
Let’s take for instance, a standard select element:
This is a natively accessible element. It is perfect for using in forms, for choosing an option from a list. They can even double as menus. Unfortunately, they’re “ugly” in the eyes of many design teams and are very difficult to style and keep consistent across browsers. Because of this, their use is widely rejected in modern web applications. Instead, people create their own drop down menus.
If building your own interactive UI from scratch, it’s very important to use the appropriate markup, provide the appropriate keyboard behaviors, and include as well as update ARIA attributes. This is the only way to provide proper identity, operation, and state to assistive technology users.
Live Regions and Hidden Text
If there is no equivalent native element to what you are building and no ARIA guideline exists, you have to deliberately provide information using a combination of techniques.
- A <span> that is visually hidden using CSS, but still readable by screen reader users
- An “aria-live” region
- A JavaScript method to update the text contents of this region
When text is added to a live region, it is placed directly into a screen reader’s queue and spoken to their users. By hiding this region visually, we are creating a method to directly communicate with screen reader users.
If you are building a complex UI, such as a sortable list that uses drag and drop, these methods are a must.
To identify the drag and drop, use aria-describedby to associate hidden text to each list item that says, “Press space bar to grab this item.” This will provide identity. When the users grabs the item, provide operation and state by placing text in the live region:
“{Item name} grabbed, use the arrow keys to reorder, spacebar to drop. Escape to cancel. Current position in list, 1 of 7”.
You can also provide the final status after an item is dropped:
“{Item name} dropped. Final position in list, 4 of 7”.
To reiterate, this method should only be used after native elements are ruled out and ARIA specified components either don’t exist or don’t work. As you are providing identity, operation and state on your own, user testing will be necessary to determine the best way to communicate this information to your users.
Now go take those accessible designs and create an experience that can be enjoyed for all users, including those with disabilities. Through these methods, you will be able to provide identity, operation and state information to all of your users regardless of how simple or complex the interaction.
Jesse is the Principal Accessibility Specialist at Salesforce. Send him a tweet @jessehausler, his phone is lonely.
Follow us at @SalesforceUX.
Want to work with us? Contact uxcareers@salesforce.com
Check out the Salesforce Lightning Design System
