Audit or Build Your Design System With Accessibility in Mind

Accessibility conformance is a hot topic and has gained a lot of momentum in recent years. It’s no wonder, because all organizations want to avoid lawsuits, and most understand that accessibility conformance helps their customer base and attracts prospects. In my experience,
as organizations evolve, they often explore inclusive design principles, where they shift left to address accessibility earlier in the SDLC, typically in the design phase. However, one thing that is often overlooked is the design system itself. It’s the foundation for all digital assets developed by the organization, but if it lacks built-in accessibility – from the smallest element up – that deficit will turn up again and again as various components become baked into forms, templates and web pages across the organization.

In this blog, we take a look at the importance of auditing your design system and the benefits that flow from doing this.

The evolving organizational mindset

On your way to WCAG compliance, you may learn that the accessibility journey never ends. In my years of working with our clients around the world, this is a lightbulb that I’ve seen turn on time and time again – the understanding that accessibility is an ongoing commitment. When organizations realize this, they have begun to make an important shift. One where there’s an expansion to improve internal processes, education, personnel and infrastructure in support of accessibility. However, in my work with clients, I routinely find that the design system – the blueprint from which all your digital products/experiences are made – has been overlooked by many organizations as they begin or even continue on a well-established accessibility journey. 

The good news is that awareness of this issue is growing. In our recent global accessibility survey, 79% of developers said they build accessibility into their design plans at the earliest stages.

Starting the design system audit

There are two angles on design system audits: auditing for internal accessibility, meaning, checking that all designers and developers – regardless of abilities – can use the system in an easy and productive way, and/or, auditing to see if the system has accessibility built into its DNA from the ground up. In this blog, I look at the latter and how we help organizations evolve their existing design systems and make all components accessible. This way, when designers and developers are using and reusing components throughout their regular SDLC activities, they don’t have to consider accessibility from scratch at each step; it’s been baked in from the start. The ultimate goal is to build this system and create operational guidelines that support its use, maintenance and ongoing improvement.

A quick tour of atomic design

A design system – the single source of truth for a user experience, be it through your app or website – must itself be designed well in order to design great experiences. If we want the ultimate experiences to be accessible, then it’s best (translated = easiest, most efficient) to build in accessibility from the start.

In his book, Atomic Design, Brad Frost likens the building blocks of a design system to the deconstruction of its elements (in chemistry, we call this matter) to atoms, the most basic level. From the bottom up, atoms join to make molecules which are joined to make organisms, Next, Frost moves away from the chemistry analogy and uses language that resonates more with clients. He defines the next level, templates, as groups of organisms woven together to form pages, which are specific instances of templates wherein placeholder content is replaced with real representative content. If the atom, say, a button that will be used on your websites, is not accessible – the color contrast is wrong or the dimension is off – then everything that is built with that button will carry its flaw. It’s like a genetic trait that is passed on. How do we avoid this? We audit the system from the atom level right up to the page level. If we’re building from scratch, then we build with this focus on accessibility at the most basic level.

Examples of auditing work with the design systems of global enterprises

When it comes to design systems, we do a wide variety of work with organizations.

Recently, we did a major audit with a global communications and collaboration platform company. We found significant issues. We helped them modify 40 different components from the design library. These changes had major cascading impacts that saved a tremendous amount of time among developers and designers. In this case, it was about efficiency, making products accessible and standardizing things. We don’t want to have to go to each page and website and figure out the button color, or go to the next site and sort out keyboard navigation, etc. For some components, we can factor out the core elements and make them accessible and save a lot of duplication of effort.

In another example, we’re working with a major television network and streaming provider. They first engaged with us to do accessibility conformance testing, creating a baseline understanding of gaps and what they need to improve. Out of this came discussions around shifting left, where we guided them on doing in-sprint testing and validation over time, and then shifting into design review and this type of new, iterative thinking.

This led to the network asking for a design review assessment. They wanted us to audit their system and identify inaccessible components. They understood that all code that they’re developing as a basis for their apps and websites originates from their design system. By auditing the components, they knew they would be reducing major rework down the line. There was a collective lightbulb that went off for the organization, and the design system audit happened very quickly and organically.

We’re also currently working with a large gaming company which has created a plug-in that is part of Figma. Their design system integrates with that. We work with them to create enablement so the team can best leverage these systems. So, here, it’s not issues in the construct of the system, but rather that it’s key to establish the processes and a full understanding of the systems for all that work with them.

Going deeper into design systems audits

There have been studies that indicate that a majority of bugs found by automated testing methods originate in the design phase. From what we see in our work, we find this to be very true. By shifting left, a great majority of these bugs could be avoided. Even so, it’s a broad team effort to look at accessibility in design systems. In our work at Applause, we are typically talking to product teams and QA, but to improve design systems, you have to engage with designers that really want to understand the impact on the product. Collecting feedback and insights from people with disabilities in your basic design choices is also critical to lay an accessible foundation.

The goal is to elevate the design system into an educational resource, providing clear accessibility guidelines, code examples and explanations for design decisions. Promote cross-team collaboration and a sense of shared ownership to ensure development teams have the necessary knowledge to implement accessible designs. This holistic strategy will help prevent accessibility bugs early on, fostering empathy between teams and leading to more inclusive digital experiences.

While we start with the audit, identify components and suggest remediation, the crucial question is, where did the issue originate? For example: let’s say a designer works with a form with different buttons, labels, error messages and different visualization content around it. There must be clear instructions on how to implement these components so engineers don’t make assumptions and misinterpret what is intended by design, such as with keyboard navigation and focus order. Designers don’t always know how to include specifications in design.

So, we will help create guidelines in the component design library so there’s clarity during the handoff from design. It’s about efficiency and making everyone accountable. When these processes are in place, it makes it easier to evaluate where defects are coming from. Is the bug a result of bad design or bad implementation? You have this question a lot when you’re working with organizations that haven’t shifted left.

When we can see where issues occur, we can better customize our services to what is really needed. This enablement is key to help avoid repeat issues in future.

When doing audits, we often see patterns. We see the same button issues, same label issues, the same navigation mistakes that occur across different pages. You realize that the problem is with a template, or, perhaps a form that has an issue. These patterns point to what needs to be fixed, and they raise the question of what should be done next. The answer is always to shift left.

KPIs are born out of these patterns as well. As organizations begin shifting left, they should also then start tracking these trends and setting targets to make incremental improvements. For the communications platform company I referenced earlier, one of the KPIs we’re tracking is the number of issues that can be found at the design level, but split out by issues that can be easily remediated, like color contrast, for example. Other issues may require redesign, having to go back to the drawing board.

Interestingly, sometimes a usability issue rather than an accessibility conformance issue forces a component back to redesign. This underscores the need to shift left and use inclusive design principles that incorporate users with disabilities early in SDLC. Again, by catching this early on, you eliminate a lot of potential pain later on when developers start to implement.

Auditing the design system makes economic sense

The cost of not being accessible is significant. And, much — if not all — of this pain begins in a design system that is not tuned for accessibility.

It’s good to know what the actual causes are behind remediating issues, as it takes a lot of resources. For example, in a WCAG audit, it’s not uncommon to find 200-300 bugs. All this information has to be groomed and digested by a product manager and put into the backlog. They must prioritize what goes in sprint one, sprint two, etc. Velocity suffers when all of this is taking place, as your team is pulled away from working on new features. And this is assuming that engineering made the mistake! Many of these issues go back to design, such as a contrast issue where engineers are just implementing what they got from design.

No matter where the blame lies, the fact is, you’re losing time.