Unseen Hurdles: Our Path to Making a Design System Accessible
As our design system evolved and expanded over the years, we didn’t pay much attention to accessibility (a11y). Many of our components ended up with all sorts of accessibility problems, from lacking proper keyboard navigation to not meeting WCAG contrast requirements.
A bit more than a year ago, we decided that we needed to make all of our web interfaces accessible, to comply with The European Accessibility Act. The EEA requires websites to be WCAG 2.0 compliant and will be enforced by June 2025.
In this article, I’m going to talk about the different challenges we faced fixing the design system, how we approached them, and what I would have done differently in hindsight.
Challenge 1: Focus States
Context
The journey began in 2021 while we were working on our Dark Theme. We noticed that some components would use the hover styling as the focus state, which is not an accessible pattern since a component could be in either of these three states: hover, focus, or hover+focus. It was something that was styled during the early days of the design system that most of us weren’t aware of.
We started exploring different focus styling options for different components and we ran into some challenges. First of all, we didn’t have any WCAG standards in mind in the beginning. We wanted to make focus indicators subtly integrated with our bright color palette, which was a problem later down the line when WCAG compliance was an added requirement in the middle of the implementation process as a part of the larger a11y project.
Design Process
Having no WCAG requirements in mind, in the beginning, we went with light inner borders for buttons and used our primary blue for everything else.
We began the implementation, and things were moving smoothly until the news came in; that we needed focus indicators to meet WCAG 2.1 requirements. Some of the good things that WCAG 2.1 requires are having a sufficient color contrast with the adjacent colors and components as well as a thick-enough and/or large-enough focus indicator that can stand out.
After familiarizing ourselves with different focus indicator requirements using this great article by Sara Soueidan, we found out that the inner border styling will be an issue as the contrasting area needs at least as large as a 2px thick perimeter around the button.
At this point, we had already implemented focus indicators for all components using the non-WCAG-compliant style. And with the beginning of the a11y project, we had only a couple of months to make the design system fully accessible. ‘We’ being just me as a designer, and a handful of UI developers.
Given these constraints, we opted to make the border 2px thick, which isn’t something that we loved as it didn’t fit with the ‘subtle’ style that we were going for, but it was sufficient and clean enough.
Learnings
Inner borders for buttons might not have been the best design for a subtle focus indicator, given that you need to make it at least 2px thick to meet WCAG requirements.
Challenge 2: Keyboard Navigation
Context
As we started working on keyboard navigation, we looked at W3C’s patterns page as a starting point. As we began to draft the keyboard navigation patterns for some of the more complex components, we realized that we had a few problems.
First of all, there was no coverage for many of our unique components and their variants. Our products often involve complex workflows with content-rich pages, allowing us some creative flexibility when designing components and patterns. Consequently, our components often deviate from native HTML components/ and standard web patterns. Some of the components that didn’t have a native HTML equivalent were multi-selects and multi-inputs.
Design Process
We started ideating and exporting different keyboard navigation behaviors based on what we think is the optimal behavior, tested it, and reiterated it.
After many iterations, we eventually realized that this process was overly time-consuming and required extensive testing. We decided to adopt well-documented keyboard navigation behaviors in established design systems that we found for different components.
We decided to do the same for all other components going forward. If there were any well documented examples of keyboard interactions for these components in well established design systems, we’d just copy those.
Learnings
I believe the first lesson here is if you’re trying to create a component that exists natively in HTML like the select input for example, make sure that the implementation works natively in HTML.
Other than that, for more complex components, unless you have time and resources to test different keyboard interactions with users, try to stick with something that’s established and consistent in other well-known design systems.
Challenge 3: Usage of Color
Context
One of the most common visually inaccessible design patterns is using colors as the sole indicator of conveying status or information. At the time the accessibility project started, we had already made improvements to many of our components including alert banners and input fields, where it was relatively simple to just add an icon preceding the text.
Many of our workflows are very dense visually. Adding icons to some components like status indicators or badges would cause a lot of visual noise and could potentially break the CSS of some layouts.
Design Process
First, we tried to see if we could use smaller and simpler versions of the icons we have to add in badges and replace status dots, but after testing them on low-resolution screens, we concluded that they aren’t very legible.
We then thought about removing the foreground from the smaller icons to fix the resolution issue, but given the shapes we were using. it couldn’t work.
The idea of using new shapes wasn’t thought of as an option at the time, given the time and resources again, but also the fact that we’ve been using the triangle for the red or critical alerts, wherein a lot of other places it’s used for yellow or warnings.
We ended up deciding to use full-sized icons, and since some using these icons would add 6px of height and width for the status indicators, and 17px of width to badges, we ended up adding a new version for both of these components to avoid breaking any existing layouts. This would
allow each product team to test how upgrading to the new versions would affect the pages and give them a chance to make any needed adjustments.
Learnings
I don’t think there’s much we should’ve done differently here, but after exploring how other design systems deal with this, I would have liked to rethink the shapes we use for status icons. This is something that we plan to explore once the a11y project is concluded.
Takeaways
With all the challenges and compromises we had along the way, we learned a lot of things, mainly that accessibility is not just a checkbox you tick, but rather an ongoing process and a mindset.
Ideally, accessibility is something you consider from the beginning, but it’s better late than never, and small improvements make a big difference, so it‘s not all or nothing either.
Try to leverage existing solutions when possible, adopt established design patterns, and read and learn from the experience of others, you don’t always have to come up with fancy solutions.
Our journey doesn’t end here, there’s still a lot of stuff that I’d like to cover. So this story is to be continued…
