One of the best ways to sell this approach comes from engineer and accessibility advocate Cordelia McGee-Tubb, who compares it to making blueberry muffins. McGee-Tubb says, “You can’t put the blueberries in the muffin after the muffin is baked.” If you did, it wouldn’t be the same. You’d make a mess, not to mention the taste would be off.
To avoid making this kind of mistake in the design process, conduct regular accessibility design reviews. These reviews:
- Happen before any code gets written (and continually with major iterations)
- Focus on design-related concerns such as content, markup for components, color use, interactive element functionality, state design, and visual design
- Can surface questions about the design and its potential accessibility trouble spots
Taking the time to conduct accessibility design reviews means fewer bugs when the design gets built, and more importantly, an interface that works for more people. Here are some things to consider.
Think about the size of your project
Every project brings different requirements. What works for one may not work for another.
Review designs at major iterations
Your reviews should happen whenever a major milestone or change occurs in your project. If a stakeholder or customer needs to approve changes, then consider doing another accessibility review.
For smaller projects, having one or two checkpoints before launch can be enough. The checkpoints provide a regular way for the primary designer and a reviewer to look at recent changes and discuss how they might impact accessibility. For larger projects, regular checkpoints can be the way to go.
Who should be involved?
Any designer with basic accessibility knowledge can serve as a reviewer. If you have accessibility specialists on staff, even better. Also bring engineers into this process regularly because they might have important insights to add. An example might be talking through how a form field interaction might work and what impact it would have on accessibility. Those collaborative conversations can’t happen without bringing the right people together.
How many people you involve depends on the size of the project. At a minimum, include the designer, engineer, and accessibility specialist. Inviting stakeholders, quality assurance staff, and other roles could also be helpful.
What to look for when reviewing a design
Once you’re ready to conduct the review, examine a number of key areas:
Think about focus order
Look at the page structure and visualize the source order and how people move from one element to another with the keyboard. Make sure the product or page follows a sequence when tabbed through with a keyboard that preserves the established meaning and functionality. Are there any potential trouble spots? Which elements create interactions where you might have to manage focus?
WebAIM provides a good introduction to the basics of keyboard accessibility on websites and web applications.
Examine copy
Look at link text, label text, heading text, heading order, and page titles. Heading structure should be hierarchical (and describe the page content), and label and link text should make sense outside of the context of the current page. Also, be mindful of the language you’re using. Plain language is essential for anyone to understand the message, but it is critical for people who may have reading disorders or cognitive disabilities. Clear, simple language will address this.
Often our designs mean we write copy specifically for screen readers, but it may mean that the experience becomes poorer for others. For example, partially visually hidden link names may work great for people who use screen readers, but this approach can be problematic for people who rely on voice control software. Designers need to balance their approaches.
Pay attention to colors
While you may use a design system with set colors, it’s a good idea to review the colors to make sure there aren’t any potential issues, such as lack of contrast for text and interface elements and text on top of images.
WebAIM shares another good introductory article, this time on the challenges of contrast and color accessibility on websites and web applications.
Look at page context and components
Design systems can help with accessibility at the component level (the building blocks included in the design system), but be mindful of how the entire page context can change that. How do the components get used and come together? Does that create potential problems?
Annotate the designs
Annotations can both help engineers implement designs faithfully and also help those exposed to the annotations learn about accessibility. Both the designers and accessibility subject-matter experts should annotate the designs with:
- Potential trouble spots
- Questions
- Accessibility guidance for engineers, including:
- Focus order
- Focus management
- Heading levels
- Aria states and attributes
- HTML structure (including landmarks and buttons vs. links)
- Alternate text
- States (hover, focus error, and perhaps more)
- Page titles
Accessibility reviews for better designs and experiences
Accessibility design reviews are an essential component to the design process. They give you a chance to pay attention to accessibility criteria before reaching the engineering phase. Doing so regularly means you’ll spend less time remediating accessibility bugs in quality assurance or production. As a result of these efforts, you’ll not only save your organization money, but you’ll also create a better, more inclusive experience for your customers.
Check out our Accessibility Beyond Compliance Playbook to learn more on maturing your understanding of accessibility and to better equip your organization and teams with practices that will lead to more equitable digital services.
