Auditing your Design system for accessibility

How to fix A11y issues at the system-level

Web accessibility isn’t an afterthought. Instead, it’s the groundwork, and your Design System lays it for every product. But when there are accessibility gaps in a Design System, the groundwork is unstable–ready to crumble and ruin the products built on top of it.

It’s kind of like a game of Jenga. If the pieces in the base layer are placed incorrectly, the whole structure will topple over the second someone takes a piece from the layers above.

Design Systems provide consistency across all product adopters, but this is either a blessing or a curse when it comes to accessibility.

Let’s say a Design System offers a button component, but the button fails WCAG non-text contrast requirements. Not only does this impact each product that uses the button (e.g., forms and call-to-actions), the issue compounds as the button is used in “organism” UI components (e.g. cards and dialogs).

Why accessibility matters in Design Systems

Having accessibility baked into the Design System is critical to prevent redundant issues. So instead of addressing accessibility failures for each instance of a UI component, it’s addressed at the system-level–remediating the issue once to trickle down to all products.

Benefits of accessible Design Systems:

• Accessible product foundation: Design Systems give its product adopters an accessible baseline to build its features and modules–minimizing accessibility failures.
• Fewer fixes downstream: With built-in accessibility, Design Systems speed up development and prevent issues–eliminating costs and time to remediate failures (especially beneficial when product teams do not prioritize accessibility).
• Fosters inclusive design: By integrating accessibility in the process from the start, designers are more likely to prioritize other inclusive design principles, such as using clear language, designing for keyboard navigation, and providing text alternatives for visuals.

But how do you go about ensuring your Design System is accessible? How do you even start? Let’s review how to prepare for a Design System audit, what the audit process looks like, then how you can prioritize any accessibility issues identified.

Prep for the Design System audit

Design Systems have hundreds (sometimes thousands) of design tokens, complex UI components, as well as guidelines for usage–making it easy to feel buried in the workload. That’s why creating an audit structure upfront is so important. In this stage, you’ll set the scope of the audit, select tools to use, and identify the accessibility standards to measure your Design System with.

I. Set the scope

Though you may need to audit everything in the system, it’s not realistic to do it all at once or expect to be finished in a few days. Here are some pointers to get started:

• Start with the foundation: Audit design tokens first, like colors, typography, and spacing. These are the building blocks of your system, so if they’re inaccessible (e.g., poor color contrast), every component using the token will inherit those flaws.
• Prioritize high-use components: Identify the most-used UI components across your products. Typically, these are buttons, input fields, modals, and navigation menus. Because these components are used across almost every product page, they amplify any accessibility gap.
• Reinforce with documentation: Accessible design tokens and UI components can be misused if your documentation doesn’t advocate for best practices. Ensure your guidelines state clear accessibility requirements (e.g., “Don’t use color alone to convey meaning”). Your system needs to be the true source of inclusive design standards.

II. Select tools

Accessibility auditing includes both manual and automated reviews. Thankfully, there are many tools to help you for both designs in Figma and coded components in Storybook.

• Design and tokens in Figma: Use tools such as Figma’s native color contrast checker, Stark’s plugin to check contrast or vision simulators, or Microsoft’s Accessibility Assistant plugin for accessibility specs.
• Coded components in Storybook: Use tools like Storybook’s accessibility add-on, axe Devtools’ browser extension, or Chrome’s Lighthouse to automate finding accessibility issues at the component level.
• Assistive technologies: There are many assistive technologies to test components with, such as simply using your keyboard to operate the component or using screen readers like Voiceover (macOS) and Narrator (Windows).

III. Identify accessibility standards

Depending on where your product is used, as well as who uses your product, you’ll have different accessibility standards to comply with. This helps you determine your acceptance criteria (or what “good” looks like).

For example, if your product is used anywhere in the European Union (EU), you need to comply with the European Accessibility Act (EAA), which references WCAG 2.1, Level AA. Or if your product is used by federal agencies in the United States, you need to comply with Section 508, which references WCAG 2.0, Level AA.

Either way, most policies and laws refer to WCAG as the standard. So by following the latest version, which is WCAG 2.2, Level AA, you’ll be compliant.

Prep output: Established audit scope, tool selection, and accessibility acceptance criteria.

Step-by-step audit process

After setting the scope of your accessibility audit, you’re ready to start.

1. Take inventory of your Design System

• Create a list of all design tokens, UI components, patterns, and documentation from Figma designs and Storybook code (or any tool you house your designs and code)
• Take note of the usage frequency for UI components and patterns (Figma offers a built in feature to view library analytics on Organization and Enterprise plans)
• Link each item to its “single source of truth,” like the Figma component, Storybook code, and documentation page

Step 1 output: Simple spreadsheet (e.g., Google Sheets or Excel) with the detailed inventory list.

2. Audit design tokens (foundation)

• Color: Validate text and icon contrast for default, hover, active, focus, disabled, error, and on dark and light themes (WCAG Level AA requires 4.5:1 ratio for text and 3:1 ratio for graphics)
• Type: Ensure text readability with minimum sizes for body text, scalable units in rem or em, adequate line height, as well as truncation guidelines (WCAG Level AA requires text be resized by 200% without loss of content)
• Target size: Provide comfortable tap areas for touch gestures, as well as spacing between UI components that supports clear focus indicators (WCAG Level AA requires 24 by 24 CSS pixels for target sizes)
• Motion: Ensure tokens allow motion to be reduced or removed entirely (WCAG Level A requires any motion that last longer than 5 seconds can be paused)

Step 2 output: Identify any issues with design tokens and the proposed changes (e.g., font sizes need to be set in rem units to be scalable).

3. Audit core UI components

• Create a test checklist to reuse for each UI component (prioritizing the most used components identified in Step 1)

Example test checklist:

• Keyboard flow: Can you open, move, select, close using Tab, Shift+Tab, Arrow keys, Space/Enter, etc.?
• Focus management: Where does focus start and land? Is it always visible?
• Semantics: Are interactive elements given explicit roles (e.g., button versus div)? Is any ARIA usage correct?
• States and feedback: Is any loading, selected, or error state using color alone to indicate the current state? Does it also include text cues?
• Screen reader announcements: Are labels, descriptions, error text, or live updates announced by a screen reader (e.g., Voiceover)?
• Zoom and reflow: At 200 to 400% zoom, does the content and text reflow without overlap or by clipping the content into a horizontal scroll?
• High-contrast and dark mode: Does the component accommodate to the user’s preference and pass contrast requirements?
• Pointer independence: Are there any hover-only affordances? Does the component also work via touch and keyboard?

Step 3 output: Identify any issues with UI components and the proposed changes (e.g., focus indicator is lost in the “Global header” component).

4.Validate UI patterns

Confirm system-level patterns are accessible by default:

• Navigation skeleton: Include a “Skip to main content” link, logical heading structure (H1 to H2), and landmark roles (e.g., header, nav, and main).
• Forms: Any grouped input fields use a fieldset or legend, there is a clear required and optional field pattern, and error messages are inline and programmatically tied to its input field.
• Empty and loading states: Include meaningful messaging and aria-busy or live regions when appropriate.

Step 4 output: Identify any issues with UI patterns and the proposed changes (e.g., required input fields in a form are not properly announced by the Voiceover screen reader).

5.Log audit findings

For each identified issue, capture the following:

• Title: Short and specific blurb (e.g., “Primary button lacks accessible name”)
• Evidence: Screenshot or screen recording of issue, and steps to reproduce
• Impact: Which user group(s) is affected, and which WCAG standard does it fail
• Severity: Is it a critical, major, or minor issue? (more on this in the next section)
• Effort (T-shirt size): Small, medium, or large effort to remediate the issue
• Recommendation: How to fix the issue in design and/or code

Step 5 output: Completed log of the audit’s findings for tokens, UI components, and patterns in either the spreadsheet or word document.

How to prioritize accessibility issues

After you have a log with the audit’s findings and what needs to be done for remediation, you need to determine the order you’ll fix each accessibility issue. Instead of simply going down the list of the log in chronological or alphabetical order, you should prioritize the list by the issue’s severity level and effort required.

But what makes one accessibility issue more severe versus another? And how do I know what issues will take more effort to fix? Let’s get into each question below.

Severity levels

WebAIM offers a resource to help rate issues between critical, major, and minor levels. Because critical issues cause the most user impact, they should be addressed before any other issue.

• Critical: These are severe barriers that cause content to be unusable to people with disabilities, such as not being able to use a webpage with a keyboard-only or having incorrect semantics on important UI components.
• Major: These are significant barriers that cause content to be difficult to use, but people with disabilities may be able to find a workaround or still operate the webpage; this includes missing focus indicators or poor heading level structure.
• Minor: These are inconveniences to people with disabilities because they affect their user experience; this includes slight color contrast issues or redundant alt text that’s repeated to screen reader users.

Effort to fix

The effort needed to remediate accessibility issues depends on the complexity of the issue, who needs to be involved, and how long the fix will take.

• Issue’s complexity: Is the issue a small adjustment (adjust color token), structural change (implement focus order), or complete rebuild (replace custom widget with native HTML)? The more complex means more effort.
• Team involvement: Is the fix design or code-only? Or is cross-team collaboration needed? The more people who need to be involved means greater effort.
• Timeline: How much time is needed to fix the issue? Adding alt text to images takes less than 1 day, adding keyboard support takes 1–3 days, while rebuilding a component can take 1–2 sprints. The longer the timeline, the more effort is needed.

Prioritization matrix

An effective way to view and communicate the required effort is with a 2×2 severity/effort grid:

• High severity + Low effort = Quick wins (prioritize first)
• High severity + High effort = Strategic projects (plan & then prioritize)
• Low severity + Low effort = Good for hygiene (batch into sprints)
• Low severity + High effort = Reconsider for the backlog (is it worth fixing now?)

An accessibility audit strengthens the foundation your entire product ecosystem is built on. By scoping carefully, inspecting systematically, and sizing each effort realistically, you create a Design System that supports accessible and resilient UI components and patterns.

But you don’t need to fix everything at once. Start with quick wins like checking design tokens, auditing a core UI component, and updating your docs. Each step compounds into a more inclusive system for everyone.

Don’t wait for accessibility bugs to pile up downstream. Audit your Design System now, and make accessibility part of the foundational structure.

Auditing your Design system for accessibility was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post first appeared on Read More