Introduction
Based on my talk at Design Systems London earlier this year, this post explores the valuable insights I have gained on how to make design systems more accessible (and why we should make this happen).
At Mews we want to build the most accessible possible products and in an effort on doing so we spent a few months during last year learning more about accessibility and improving all the components in our design system.
What is accessibility?
Accessibility revolves around the principle of making websites usable by as many people as possible. I personally favor a definition that encompasses inclusivity, focusing on people rather than disabilities or impairments. After all, we are all people, and there should be no division between “us” and “them.”
Why is accessibility important?
While many assume that individuals with accessibility needs represent only a small percentage of the population, the reality is that over 1 billion people currently experience some form of disability. This eye-opening illustration made me realize that accessibility needs can fluctuate based on various factors. That’s the human side, but what does it mean for business? From a financial standpoint, neglecting disability needs can cost businesses approximately £2 billion per month. Want to make a case for the importance of accessibility to your boss? This statistic will definitely grab their attention.
Source: https://devblogs.microsoft.com/xamarin/the-journey-to-accessible-apps/
A bit of backstory
Last year, when our design system team was smaller, we found ourselves without a designer for several months. In response, we decided to improve our existing components and dedicated nearly half a year to learning about accessibility. I have to admit that our components were not initially very accessible.
Throughout the months we spent enhancing accessibility in our design system, we discovered some easy wins—small but highly effective steps that can significantly improve the accessibility of your components without requiring excessive effort.
Making design systems more accessible
If you think about it, the fact that you are building components that then get reused multiple times in multiple products makes it easy to realize the importance of accessibility in a design system. Design systems provide an excellent opportunity to build accessibility and inclusivity into your component libraries from the get-go. Rather than relying on individual developers to understand accessibility when building similar components, you should ensure accessibility is ingrained by default in your components.
The easy wins
So let’s explore four easy wins that can make a substantial difference in terms of accessibility and fortify the inclusivity of your design system.
- Make your colors accessible
Ensure your background and foreground colors have adequate contrast ratios. Tools like the Webaim contrast checker can assist in manual verification, or you can take inspiration from Stripe’s approach by building a comprehensive color palette based on color spaces.
Source: https://webaim.org/resources/contrastchecker
- Write semantic code
While it may seem basic, using the correct Hypertext Markup Language (HTML) elements is crucial for making your components accessible. The web was designed with accessibility in mind, and browsers fully support and understand HTML elements and their behavior, making them more robust and accessible. So whenever and wherever possible, consistently use the correct HTML elements and prioritize writing semantic code. To illustrate this point, consider a button implemented without using a semantic element compared to one that does. Using semantic code, you not only reduce the amount of code required but also enhance its readability. This contributes to a more resilient, reliable, and accessible component.
- Keyboard navigation
Testing for keyboard accessibility is simple—test your components by navigating and interacting with them solely using the keyboard. Typically, if a component is inaccessible via the keyboard, it is either due to non-semantic code or additional code interfering with keyboard navigation. Speaking of keyboards, please consider the importance of focus. Browsers have default styles for focus, but if you choose to remove them, remember to carefully implement your custom focus outline.
- Test with screen readers
Screen readers enable individuals with various needs to use digital devices independently. It’s important to use inclusive language here and not only consider visually impaired individuals. Many people utilize screen readers for various reasons beyond visual impairments. Testing with screen readers can be a time-consuming process, particularly at the initial stages, as there are multiple options available. However, the effort is worthwhile, and there are many online guides to assist you in the process.
By focusing on these easy wins, you can achieve significant accessibility improvements, fostering a more robust and inclusive design system.
Lessons learned
But of course, there are always two sides to the same coin. While easy wins are crucial, it’s equally important to address drawbacks and missing elements to achieve a truly 100% accessible design system. Here are some suggestions based on the lessons we learned while improving the accessibility of the Mews design system.
- Understand what to check
It is important to understand what we should check during testing to achieve great accessibility. The UK government provides a webpage on Web Content Accessibility Guidelines (WCAG) 2.1, which helps in understanding the guidelines.
https://www.gov.uk/service-manual/helping-people-to-use-your- service/understanding-wcag
I also like IBM’s design system, Carbon. They have a fantastic requirement section that allows you to choose the specific standard you want to test against, along with the type of content. It provides a comprehensive checklist of items that you can utilize. This feature is incredibly useful. For instance, if you aim for WCAG 2.1 for web content as we do at Mews, you’ll end up with 34 requirements to fulfill.
- Test extensively
Go beyond the easy wins and test for various accessibility aspects, such as zoom text, low contrast, and reduced animation. Many online guides and tools are available to assist you, such as the Axe Devtools Chrome extension by Deque, which enables you to conduct tests directly within your browser.
At Mews, we utilized the Microsoft-developed Accessible Insights tool when testing our components. It provides a checklist of checkboxes for testing and can even automate certain checks. It is also available as a Chrome extension.
And remember that having accessible components doesn’t guarantee an accessible page. Always test the complete page or user journey to ensure accessibility remains intact when combining multiple components.
- Leverage accessibility tools
You don’t have to handle everything manually; take advantage of the leverage tools available that can aid you in identifying and resolving issues quickly and efficiently.
The eslint plugin jsx-a11y is a valuable tool that can provide real-time accessibility feedback within your integrated development environment (IDE) if the code you’re writing lacks accessibility. You can configure your design system to prevent any code changes if the plugin detects any errors.
Storybook, a popular tool for building UI components, includes an accessibility add-on that highlights any accessibility issues within your components. You can even pinpoint specific violations, and the corresponding segments of your component will be highlighted.
- Provide the right data
Use the force, AKA provide the right data, to avoid being yelled at by your computer. When building a design system, you cater to two sets of customers: the end-users of your product and the fellow developers within your company who utilize your components for building the final product.
To ensure that components are implemented in the most accessible way, there are various approaches you can take. For example, if you’re using React, incorporating PropTypes enables you to ensure that essential accessibility properties, such as the alt tag for an image, are not overlooked. Alternatively, if TypeScript is your choice, you can make the types that matter for accessibility a requirement.
As a simple example, consider an image where the alt property is mandatory. If a developer forgets to include it while implementing the component, an error will arise that must be resolved before committing the code.
- Commission a professional audit
Though I have to admit we still haven’t done this at Mews, consider obtaining a professional accessibility audit to ensure thorough testing and evaluation. While much can be accomplished with learning, testing, and implementing tools, an expert auditor can provide deeper insights into how individuals with accessibility needs would interact with your product.
Would you like to work for Mews?
Check out our job vacancies! 👀
Conclusion
So, those were the easy wins and the lessons learned in our journey to improving Mews’ design system accessibility. I want to leave you with a couple more thoughts.
Remember, the work is never truly finished, but even a little effort is better than none at all. Don’t feel overwhelmed by the amount of work or the knowledge you need to acquire. Instead, focus on the improvements you can make. For example, if your overall accessibility is currently at 10%, and you know that with some work, you can raise it to 20%, don’t dwell on the remaining 80% that’s still missing. Recognize that moving from 10% to 20% means you’ve still effectively doubled the accessibility of your components.
Lastly, your most powerful weapon is empathy. Regardless of your skills or the time you have available, genuinely caring about accessibility is the secret to making your design system truly accessible. I sincerely hope that after reading this, you’ll take the initiative to check and improve, even if just a little, the accessibility of your own design system.
