1.5 Choose the Right Design System

Design systems are incredibly useful.

They provide a consistent user interface (UI) through reusable components, typography, and color palettes. Many design systems have accessibility and accessibility features baked right into them, which could significantly reduce—but never eliminate—accessibility defects. 

But when design system components have accessibility defects, the sitewide impacts for assistive technology users are huge. For example, if a design system’s button component was marked up with a clickable div instead of a semantic button, assistive technology users will not be able to interact with ANY button in the application.

Many projects already have an existing design system in place or one pre-selected—many federal government contracts require the U.S. Web Design System (USWDS). But some projects don’t, and teams will need to make the critical decision about which design system to use. Complicating matters, design systems might claim to support accessibility without actually doing so. 

So how can teams determine whether or not they are choosing an accessible design system? Never take a design system’s accessibility claims at face value. Instead, use some of these “smell tests” to help determine if a design system is the right choice.

Design System Accessibility Smell Tests

• If a design system does not include any accessibility notes, it is probably not accessible.

• If a design system does include accessibility notes, make sure it’s actually accessible. 

  • Try using various components with keyboard-only navigation or a screen reader, and see what happens. A technically compliant component may still be hard to use!
  • Ex: Users expect to activate a button (<button> or role=“button”) by using SPACE or ENTER. A design system has a deletable chip component, which keyboard users can activate using DELETE or BACKSPACE. This is technically accessible—the chip can be deleted—but very confusing for keyboard users, who might not be able to learn a custom input method to use the component because it hasn’t been communicated.
• Run accessibility extensions like Axe DevTools on components.
• Determine if it’s possible to add ARIA (Accessible Rich Internet Applications) attributes to components and the HTML elements within them.
• Read through code repository issues to see how maintainers are responding to accessibility issues.

• Check the modal component. If it does not do ALL of the following, there’s a strong probability accessibility issues exist throughout the design system:

  • Transfer focus to modal window when it is opened.
  • Transfer focus back to the opener when closed.
  • Be able to close when the user presses the ESCAPE key if the modal can be closed.
  • Trap focus within the modal when it is open; in other words, the user cannot escape the modal using tab navigation.
  • Prevent screen readers from accessing content behind the modal when it opens, particularly through the rotor or headings menus.
• Look at the select box. If its opened state uses a custom design in place of the browser default, chances are it will not have sufficient keyboard support or may have taken liberties with available functionality. If a design system has a custom select box, chances are the design system prioritizes visual presentation over accessibility. Note: Customizable select boxes are on the way.

Accessible Design Systems May Still Have Defects

If a design system passes all accessibility “smell tests,” it’s still possible that there are accessibility defects contained within them. Nothing is 100% perfect 100% of the time. Good design system teams will prioritize accessibility defects and publish fixes within a reasonable amount of time. Whenever there is an accessibility defect in an otherwise accessible design system, consider the following options:

• Create an issue in the design system’s code repository to let the maintainers know there is a defect. Be as descriptive as possible, they might not be aware the issue exists.
• Don’t wait for the design system to resolve the issue, it might require a lot of time to push the update, and it might include breaking changes to your project. Instead, either find an alternative solution or build your own accessible version of that component.

Even if a design system offers accessibility “out of the box,” that doesn’t make projects that use them immune to accessibility defects. While the components in isolation might be fully accessible, it’s easy to implement them in inaccessible ways.  

Examples of Accessible Design Systems

There are plenty of design systems to pick and choose from, but only a few of them have great accessibility. Typically, design systems owned and maintained by government entities will have better accessibility support because they serve a highly regulated space. Two design systems to consider are:

• U.S. Web Design System
• GOV.UK Design System

Even if these design systems are not the best fit for a project, they provide a high standard of accessibility and can serve as benchmarks to compare other design systems against.

Many design systems, such as the U.S. Web Design System, allow custom theming for altering their default properties in order to conform to alternative visual design styling without sacrificing accessibility. For other design systems, look into Assessing components for WCAG 2.2.

How We Know We’re Doing This

How We Know We’re Coming up Short