Can a Design System be Accessible?

Written by
Date published
August 5, 2020

No, but it should enable accessibility (a11y).

Design system accessibility is not a "set it and forget it" process.

Accessible Design System Expectations

Over the past couple of years at Rangle, I’ve had the opportunity to work on a handful of design systems (DS), and one consistent ask is to “make the design system accessible”—or get it to a point where a client can certify that everything within the design system meets their minimum legal requirement for accessibility (like WCAG 2.x AA). On the surface this sounds achievable, but certifying accessibility in your DS doesn't mean that your apps and sites will automatically meet these requirements.

The misconception is that a DS with a11y baked-in means you won’t have to educate your teams about a11y. This is definitely not true. Websites and applications built with your accessible DS will not necessarily be accessible by default. A11y is not something that one can "do it once in your DS, and never think about it again".

Context is Key

Much of accessibility is context-specific, and can’t be fully implemented without that end-usage context. Take images, for example: In order for an image to be accessible, it needs to have relevant alt text applied. This text is read aloud by screen readers to make the image perceivable to users with vision impairments.

In your DS, the image component could be created to allow alt text to be applied, but it is still up to the consumers of the design system to pass in relevant alt text.

Screenshot of a website containing an image of a knit hat and gloves. The image is focused on by a screen reader, and the screen reader overlay reads “ah5d7sjjegsuk32ks, image"

Though you could try to set an alt text default (using the title or filename of the image), you would still be able to have images that are not perceivable to screen reader users, because a file named ah5d7sjjgsuk32ks.jpeg would be read out as “ah5d7sjjegsuk32ks, image”. It’s up to the designers and developers consuming the DS to understand and determine what the image description should be and apply it each time.

Why It’s Worth The Effort

Design systems that are built with a11y as a focus aren’t guaranteed to make your end products accessible, but design systems that don’t have a11y built-in are guaranteed to make them inaccessible. If that same image component has no ability to apply alt text, even an experienced accessibility expert will be completely unable to apply alt-text. Consequently, they won't be able to make any images accessible.

Not all aspects of accessibility can be built into a design system, but building it with a11y as a core goal will lay the foundation for accessible end-products. This is similar to how the design kit in a DS will lay the foundation to design your end-product.

Two pyramids are shown drawing a parallel between design foundations and accessible foundations in a design system. The base of the Pyramids represents the design system work, for design you can build in Typography, colours, spacing, basic components, for Accessibility; colour contrasts, interactive states, and base semantic elements. The top of the pyramid represents work done in the consuming application, for design you will need to create full page designs and user flows, and for accessibility; the full keyboard flow, aria attributes and alt text"

For example, designating brand colors in a design system allows the product designers to easily create designs using those exact brand colors, but it does not guarantee they will use the colors. Similarly, creating a color palette in a DS with color contrasts that are sufficiently accessible to colorblind users allows the consuming team to easily create a product that is accessible to the colorblind, but does not guarantee that those consuming the system will use these colors correctly. Conversely, creating a palette without those color contrast criteria guarantees they can’t!

Laying an Accessible Foundation

When thinking about which aspects of a11y you can build into your foundation vs. which you will need to do later (when consuming the DS), you can break it down into the three main categories: visual features, keyboard interaction, and screen reader requirements.

Visual Accessibility

What can I build in?

  • Visual interaction states for components
  • Visual indicators of error states
  • Accessible color contrasts that meet minimum requirements
  • Components that look like what they are (Buttons that look like buttons, textfields that look like text input fields)

What will I need to do later?

  • Ensure components are placed on backgrounds that meet color contrast requirements
  • A visual flow to the page with how components look and work together

Keyboard Accessibility

What can I build in?

  • Custom keyboard focus changes for unique components (when you click a button to open a modal, the keyboard focus moves to the first interactive element in the modal, when the modal closes keyboard focus returns to its previous location on the page).
  • Visual indicators of keyboard focus location
  • Rules for component keyboard interaction with interactive elements, using appropriate semantic elements as a base for components. For example, a Button component should use a <button> element, a textfield should use an <input type=”text”> element
  • Visual states, like disabled, match with the browser expectations (i.e. an anchor tag with no href applied is considered disabled by a browser)

What will I need to do later?

  • UX design for the keyboard flow throughout a page, moving between components
  • Implement keyboard flow designs in development
  • All interactive elements can be accessed with a keyboard (nothing is hover only, or unreachable)
  • Custom keyboard focus rules, for non-DS components or unique requirements
  • Don’t unnecessarily override keyboard focus

Screen Reader Accessibility

What can I build in?

  • Semantic elements as a base for all components so the a11y tree will be populated correctly
  • Allow for all a11y related attributes (roles, aria attributes, alt text) to be passed down to the semantic element
  • Some aria associations (Connect form field with its label using aria-labelledby)

What will I need to do later?

  • UX design for what should be read out when interacting with specific elements
  • Hamburger Icon Button used to open a menu reads as “Main Menu”, User Icon reads as “Your profile”, etc.
  • Apply aria attributes and alt text to components and make sure that text is meaningful
  • Group elements in the proper type of group (list items should exist within a list)
  • Use landmark elements correctly (nav, footer, header elements, etc.)
  • Apply role attributes to components when necessary.

This is by no means a comprehensive list, but I hope it gives you a better idea of the foundation pieces that you should build into a design system to facilitate accessibility. Also why, despite this, those who use the design system to build experiences still need to have an understanding of a11y.

In Conclusion

I firmly believe that “Accessible Design System” is a misnomer, because using an accessible DS does not guarantee an accessible end product. Everyone on your team is responsible for ensuring that the end product is accessible to all audiences, and is easy to use for all your potential customers and end users.

A design system can’t be accessible. Rather, a design system should enable accessibility.


See what Ranglers are writing about on our blog