Power up your design system with accessibility testing

What makes a design system accessible?

Many would assume that if a design system’s parts and tools are accessible, then the design system itself is accessible. But measuring the accessibility of a design system is different than measuring product accessibility. A design system isn’t something the public directly uses. Instead, the users of a design system are the product teams within an organization, so how you vet it will be different.

So, what makes a design system truly accessible? Its ability to help diverse product teams build accessible digital products.

Level 1: Testing the elements

A typical design system includes a set of styles, components, and patterns. These elements are the building blocks used to make products. Making sure these elements are accessible creates a solid foundation that ensures accessibility from the ground up.

Start by using testing techniques that can identify basic issues. For example, tabbing with a keyboard to check that interactive elements have a visible focus indicator. To save time and effort, be sure to fix any known issues before testing with users.

These accessibility testing techniques are great for testing individual elements:

• Manual testing with assistive technologies
• Visual and code inspection
• Automated testing, linting, and browser testing tools

Usability testing at the element level

After fixing known issues, consider testing with people with disabilities. When testing individual styles, components, and patterns, rather than testing user experience, focus on making sure each element is ‘functionally accessible’. For example, an individual component should work as intended, for everyone, across all assistive technologies.

Testing with users at the element level requires a thoughtful and creative approach. Be sure to provide participants with extra guidance and context when testing individual elements. It will be important to explain how the goal of the testing session is to explore individual pieces of a product, rather than the product as a whole, or a specific user journey. Because of this, moderated formats are the best fit for this kind of testing, as it allows you to provide testers with necessary guidance and support throughout the process.

Considerations for different types of elements

• Styles: When testing styles on their own, present them through carefully selected components and patterns. It can be difficult to experience a style’s intent and effect without context. For example, testing typography’s effect through paragraphs, buttons, and headings will be more meaningful for a user than looking at a type scale.
• Components: Focus on testing functionality and understanding, rather than context and suitability. Can a component be used successfully by an assistive technology user, independently and in ways that they would expect?
• Patterns: These offer more context than individual components, but they still lack a realistic user journey. Focus testing efforts on whether a pattern is generally usable, and suitable for a range of testers, ensuring that each user can achieve its intended outcomes.

Tips for success

• Seek the right users: When testing individual elements, testers who are comfortable with a high level of ambiguity make great partners. Find testers who can think outside the box, have existing accessibility testing experience, and have a moderate level of digital literacy. Fable’s community of assistive technology users are uniquely qualified to help digital teams test and mature the accessibility of their design systems.
• Test with users’ devices: Have testers use their own devices and assistive technology setups. This creates a more realistic testing environment and makes sure testers are comfortable and properly equipped.
• Provide coded examples: Testing in code provides testers with a realistic experience of the elements, even if that experience is not in the context of a broader user journey. Some design systems may not have formal coded examples for all elements. If this is the case, consider sourcing coded examples from trusted product teams and including those teams in the testing process.
• Remain open-minded and adapt as needed: Even if testing doesn’t quite go to plan, remember that non-ideal test situations can also provide valuable insights.

Level 2: Testing the system

Once individual elements work well on their own, it’s time to put them together. Accessible text areas and date pickers are important in isolation, but how they fit within the broader design system also matters.

At this level, testing with people who use assistive technologies in their everyday lives becomes incredibly valuable. When testing individual elements at Level 1, teams can conduct manual tests themselves to validate things like proper ARIA use and keyboard navigability. At Level 2, the focus shifts to testing how parts of a system work together. This requires a user-focused approach.

The best way to test how a design system works in a real-world situation is with a real-world user journey. Many design system teams don’t have direct access to such a journey, but they can partner with a supportive product team to put it all together. That way, the product team gets help testing their product, and the design system team gets a place to test their components. For example, work with a ‘payments’ team to check if all payment-related components and patterns work well together by testing an end-to-end checkout flow.

New or recently updated elements can be tested in partnership with teams that are building new features. Partner with teams before feature launches, to test if both the product feature and its updated design system elements are accessible.

In some cases, a selected product’s journey and use case might be a good fit, but the code in production doesn’t match what was used in the design system (due to customizations or other factors). In this case, it is better to build a copy of the journey using design system elements. If the goal is to check design system accessibility, then the test should use design system code.

If a real product journey isn’t available to you, proceed with caution. While it is possible to test basic design system functionality with a best-guess user journey or to leverage available templates, a prototype won’t necessarily be an accurate representation of how the design system works or is used in the real world.

Level 3: Testing the journey

Levels 1 and 2 test a design system’s parts and whole. If a design system were a typical product, you could stop there. In this case, the design system should also be tested for its ability to facilitate the creation of accessible products.

Encourage and support product teams in arranging regular accessibility testing. The results can help validate the value and intended impact of the design system. If a design system’s offerings are not improving product accessibility, engage with product teams to learn why. Be open to revisiting design system documentation, processes, and communications to improve outcomes.

That said, a design system shouldn’t only work for well-supported teams. Consider ways to test with, and gather feedback from, teams with a range of accessibility expertise and access to support. Helping small and complex products to improve accessibility is just as important as helping larger products.

Increasing accessibility and quality across all products, regardless of size and complexity, shows the true value of a design system.

From design system accessibility to product accessibility

Testing a design system’s accessibility is not a replacement for testing accessibility at the product level. Testing a component’s accessibility is always good, and testing whether a system of components work together is great. This work will save teams time and effort in the long run. But a well-tested design system doesn’t replace the need for a well-tested product. Every product will have specific local problems that arise during product development that are important to catch.

The best way to measure the impact of a design system on accessibility is by testing products built with that design system. When it comes to measuring product accessibility, consider using Fable’s best practices for product accessibility KPIs or benchmarking accessibility over time.

Collaboration is key

Throughout each level of accessibility testing, collaboration helps drive the work forward. If there’s an opportunity, work with others! From testers to product teams and everyone in between, support each other’s work toward improving accessibility.

Unlocking accessibility at scale

In 2022, the UK Government’s design system team began working on a high-stakes component: an ‘exit this page’ safety feature. This component intends to help people leave sensitive services quickly. But such a high-stakes component is only effective when it is easy to use and works consistently across multiple services.

Testing the ‘exit this page’ component at the design system level led to a more accessible and safer experience for everyone. Investing time in accessibility improvements, and testing the results with people with disabilities, enabled the team to provide a consistent, predictable, and accessible solution: a component that ensures people know why it is there and can trust that it will work when they need it.

An accessible design system is a powerful tool, and a great benefit to any organization and their end users. Testing accessibility at the design system level can add complexity and nuance. But findings gained from testing will carry forward powerfully, boosting many products at once, and scaling accessibility across teams.