Accessibility is a practice, not a one-off task.
It’s not about crossing items off a checklist before a product launches. To “do accessibility” is to intentionally make product decisions that consider the needs of disabled people and their experiences. Teams should strive to be “accessible beyond compliance,” as it’s often called, by centering inclusivity around the entire design and development process.
This commitment to accessibility is grounded in four guiding principles: Perceivable, Operable, Understandable, and Robust (also known as POUR principles); which shape how users experience digital content.
- First, content must be perceivable, ensuring that users can sense and recognize it in ways that work best for them.
- Content must be operable, providing users with multiple ways to navigate and interact with content based on their preferences.
- Content must be understandable, ensuring users can comprehend the language, layout, and controls provided.
- Lastly, content must be robust, built to accommodate various assistive technologies and support a wide variety of user interactions.
This often involves something of a culture shift in the way a team approaches design and development:
- Instead of interactions only through touch or cursor, designers must also include interactions with keyboard-only navigation, screen readers, and voice input as equally important modalities.
- Engineers must actively manage live regions so that announcements are not overwhelming or insufficient. They have to make sure that the interface doesn’t break when the user sets the zoom for 400%.
- Factoring assistive technologies into UX solutions requires many more decisions to be made. Some solutions used in the past may need to be dropped entirely.
Additional work might seem burdensome, but treating support for assistive technologies as something extra—not a baseline—is ableism. Once a team has built enough familiarity with supporting assistive technology through actively using it, supporting assistive technology will come naturally.
When this occurs, teams can have robust conversations on accessible design solutions, and weigh the tradeoffs between one solution and another. They’ll shift left to consider the needs of people with disabilities from the beginning of a project and throughout the development cycle, rather than just at appointed touchpoints or after critical decisions have been made. Like everything else with UX, there is always more than one solution. Developing expertise helps with finding creative solutions that are accessible AND usable.
Play 1.3 instructs you to learn how to use assistive technology. This play encourages you to take how those technologies work into consideration as you build the user experience.
How We Know We’re Doing This
- All our design, content, and interaction decisions are inclusive and consider assistive technology in addition to cursor and touch interaction
- We look at multiple ways to support accessibility and examine the tradeoffs between them, if there are any
- Our team is thinking about the amount of verbosity from the screen reader
- Our accessibility conversations sound a lot like UX conversations
- Our team is proposing specific accessibility solutions instead of generically stating a need to be accessible
How We Know We’re Coming up Short
- We think about accessibility as a set of benchmarks or a checklist
- We have the screen reader simply announce everything
- We see trade-offs between design or engineering best practices and accessibility best practices
- We only consider one solution to meet accessibility requirements
