.png)
Up to 67% of accessibility defects begin in design, with a domino effect occurring when you pass those designs to development. However, considering accessibility when building your design system can nip those issues in the bud.
Design systems are an easy and efficient way to bake high accessibility standards into all of your tokens and components. By incorporating accessibility into patterns and documentation, you can be sure that your future work will reach the standards set early on.
Adhering to accessibility standards and best practices
It is crucial to meet the relevant accessibility standards for your users. The WCAG is a fantastic set of guidelines to help you build in an accessible way, andwe will use their examples throughout.
When you have a set of best practices to follow, it makes the process of designing for them much simpler. This is why accessible documentation is so important for design systems; documentation sets the tone for the rest of the design system, and ensures that anyone onboarded into the system understands the context and standards of what they're working wiht.
If we start at the beginning, we can make design tokens accessible. For example, it’s bad practice to use pure black on a pure white background (and vice versa) when dealing with text: it can hamper some people’s ability to easily read text. We can consider this during the selection of our color palettes at the beginning of a project.
We could also apply techniques like this to other design tokens. For example, we could ensure font sizes are of an adequate size to read. This would mean all text in the product would be of a sufficient size to read, even if you have poor vision.
Moving onto components in our design system, let’s say we are building a graph. We’d have to consider:
- Text legibility (e.g. labels)
- Minimum touch target sizes
- Consideration of color blindness
- How to zoom in and focus on areas of interest
- Alt text explanation of the information displayed in the graph
In terms of WCAG guidelines, if we were aiming for AA compliance, some guidelines that would apply to us here are:
These aren’t exhaustive lists of considerations; they’re a few examples.
In this example, the component supports a number of accessibility criteria:
- Text colors used have at least a 4.5:1 contrast ratio.
- An image and text support the use of color on the graph.
- Colors used for the bars have a sufficient contrast to the background color.
We can reuse accessible components throughout the product. Traditional accessibility audits tend to sample a few pages, rather than every page on a website, which naturally leads to missing issues. Pattern-based design solves these problems; when working with patterns including codified accessibility standards, you can be sure that all of your components have been accessibility tested.
Collaborating on accessibility with developers
The next step is to ensure our designs translate into accessible code by the developers working on the product.
Developers should be using semantic elements to build the product. Why? Because these semantics are what enable assistive technology to interpret your product. For example, screen readers can allow readers to jump between headers (H1 elements) on a news site. This is convenient for the user and simple to build.
Design systems become even stronger when design and development work together. Development can use designs as the blueprint for their work and contribute to the design system with the code required to build this component. Design can then review the solution, and determine whether improvements needed from a usability perspective.
Additionally, we can check the instances of these components for their ability to produce useful and correct attributes for their context—for example, images having a descriptive alt text. The components could have their own test suite, which automatically checks for any problems too.
Both Design and Development should collaborate on documenting why and how they meet certain guidelines. In the football example shown, we could document that the text with the player’s name and number of goals scored should switch between light and dark text depending on the color of the background. This will help people new to the component understand how to use it.
The domino effect of incorporating accessibility early on
With each accessible improvement, you are stitching the fabric of your product to be inclusive in the future. Each component makes the product more usable everywhere it’s used.
But as quickly as these changes can help, a poorly implemented component can bring the whole experience crashing down. For instance, take a modal. Quite often these can be mistakenly coded to become keyboard traps which have no way to escape. Even if every other component is beautifully crafted, this single modal can stop a user in their tracks.
This highlights the need for careful reviews of changes and proper version controls for your design system. You can ensure no regressive changes make their way to production.
Examples of accessibility-focused design systems
Some companies have published great examples of how they consider accessibility:
- Airbnb have embedded accessibility into their design system platform and philosophy.
- Uber has sought out elements of the web that are difficult to make accessible to screen readers (e.g. drag-and-drop lists). They’ve then built a library of components they can repeatedly leverage to make their customers’ lives easier.
- Apple publishes great documentation which educates others on how to develop inclusively using their platform.
Accessibility should be a natural part of your design system
A design system is a living, breathing part of your product. It’s never finished, much like accessibility which you can always improve. If we make efforts to improve accessibility through our pattern-based build process, we can create a more inclusive product.
Solving accessibility issues early on will save you time and money on re-work in the future, while showing your users that you care about them and their needs.
