Design systems are a great way to include accessibility into your products. Some might even think the job is done once accessibility standards are met in the design system. While it does help, that’s not the case! Here are five myths that we come across when it comes to design systems and accessibility.

illustration of a myth stamp

Myth 1: Once we’ve established an accessible color palette, we don’t need to test for color contrast any more.

False. Contrast is the comparison of two items to see their differences. While you have tested some color combinations for accessibility, this doesn’t mean all combinations in the palette are accessible.

For example, a color palette includes a green, a blue, and white. The blue and white have enough color contrast when used together. And the green and white have enough contrast together. Yet, the green and blue, even though they are in the palette, do not have enough color contrast between them.

While some combinations in your palette will have enough contrast, not all combinations will. Also, sometimes two colors seem like they have enough contrast, but they actually don’t. As a best practice, always double check the color contrast between two colors.

Pro tip: In your design system, list common color combinations and their color contrast ratios
This will help designers and engineers quickly see which color combinations are accessible. Then for infrequent color combinations, they can use a color contrast checker.

Pro tip: Bake color contrast checking into your workflow.
Identify tools your team can use; some of our favorites for color accessibility standards include:

• Paciello group’s Colour Contrast Analyser (Free; It also has an eyedropper tool so you don’t need to know hex values.)
• Stark makes plugins for Figma, Sketch, and Adobe XD

illustration of a myth stamp

Myth 2: The UX has to be fully accessible or we can’t have it. This will also make our solutions so constrained!

False. While you should aim to have your user experiences accessible, it’s not always possible. Brute forcing accessibility isn’t a solution if it creates poor usability for everyone. Accessibility also isn’t meant to constrain your creativity. Instead, you can provide an alternative equivalent. They provide alternate ways of navigating or obtaining the information a person needs.

For a small example, a blind user won’t ever be able to see an image. This doesn’t mean you can’t use images at all. Instead, you can alt text, which describes the image. This allows blind users to get the relevant information they need.

For a more complicated example, maybe you have an interactive infographic. Users move their mouse over elements to find more information. Alternatively, you can ensure keyboard navigation for the infographic. This provides keyboard-only users with access to all the same information.

Pro tip: Think of accessibility as a challenge that up-levels your skill set, rather than something that cramps your style.
The demand for ensuring accessibility is high. Teams find designers and developers that understand accessibility desirable. So embrace the challenges of making things accessible as a way to grow your skills. Also, don’t feel like you have to know everything or go it alone. Collaborating with teammates can create some of the best solutions!

Myth 3: Accessibility is only the responsibility of designers/developers.

False. Accessibility is a shared responsibility among designers and developers. There are aspects of accessibility that a developer will know well, that’s not expected knowledge for a designer. For example, how to code something for a screen reader to consume. Then there are aspects that a designer will know well, that’s not expected knowledge for a developer – such as, the order of how a user navigates through a flow.

Creating accessible solutions are usually part design and part implementation of the design. Sometimes accessible solutions aren’t always as clear as using existing code conventions. For instance, you have a clickable card that also has a series of buttons on top of it to dismiss or favorite the card. In this case, we want users to understand the card is clickable, but that it has more functionality on it. While the experience might seem straightforward, the implementation isn’t. When this happens, designers and developers can brainstorm together to figure out a solution that is both accessible from a design and implementation perspective.

Pro tip: Don’t try to create the solution on your own. Loop in other designers or developers.
If you’re working through something complex, collaborate with others to find a solution. This can make things more fun and less frustrating. If you’re a designer, explaining the intent of the experience can help developers provide some implementation options. Once the team arrives at a solution, ask if you’re fulfilling the original intent of your web design or app design. Sometimes you can over design an accessible solution and it ends up missing the original intent.

Pro tip: Document any accessibility patterns or solutions in your design system.
Sometimes these solutions are hard to come up with or challenging to implement. So if you can share your solution, it’ll make it easier to adopt accessibility across your products. It’ll also ensure consistency of these experiences too, which users will appreciate!

illustration of a myth stamp

Myth 4: If our design system components are accessible, we’re all set with accessibility.

False. Design systems are only a partial solution to addressing accessibility. Accessible reusable components can improve the accessibility across your product. But they don’t  account for everything. Your site or product needs to consider the accessibility of unique pages, flows, or screens. These are too specific to include in a design system.

For example, your app allows users to buy items. Your design system can cover the accessibility for the buttons, form elements, and interaction states. But, page or flow-specific accessibility like navigation order, heading-level hierarchy, and alt text for images will still need addressing.

Pro tip: Make adding in accessibility as easy as possible for your team.
The easier it is to do something, the more likely people can incorporate it into their workflow. This means including as much accessibility in your design system as possible. It also means ensuring your team has tools to annotate accessibility in designs. For example, a Figma library for accessibility annotation components (e.g., tab order, alt text).

Myth 5: We created a solution for one impairment, so it solves for all impairments.

False. One solution won’t necessarily solve for all impairments. Sometimes a component might need multiple solutions to be accessible across all impairments. For example, buttons need multiple accessibility solutions. Keyboard-only or partially-sighted people will need the focus state on the button. While blind users won’t need a focus state, they need the button coded so their screen reader recognizes it as a button. So the button component needs both the labeling and focus state to be accessible.

Pro tip: Think of all the usability aspects of impairments when evaluating a component or pattern.
It can be tough making sure you’ve thought of everything or having a solution for everything. Check with a peer to make sure you’ve covered all the bases. It can be a great learning experience for everyone. Here’s a quick checklist:

Can a user navigate or comprehend this if they:

• are blind?
• have partial vision?
• cannot hear?
• have partial hearing?
• cannot speak?
• only use a keyboard or special input devices?
• are neurodiverse?

What next?

• Share this article with colleagues, especially if they’ve believed some of these myths before.
• Start collaborating with your teammates. Solving accessibility issues is a lot more fun and easier with others!
• Document any patterns, guidelines, and tools in your design system. This can help  make accessible design more natural for the team.
• Come talk with us on the zheroes Slack community! We love chatting about accessibility and are here to help!