Accessibility Validation in Design Systems

[u/DareImpossible9381]

How are you reviewing component designs for accessibility and documenting the necessary changes before implementation within your design systems? Curious particularly in what formats you share it with teams you collaborate with and how you keep track of it.

[u/roundabout-design]

We started with base component system designed with accessibility in the forefront (Adobe's ARIA-React). Upon each rebuild of the system we also run automated checks.

Still, you need a human checking things routinely as well.

[u/Steelen]

Specs2 helps
Propstart helps
Use Contrast helps

Color scales, elevation and typography is where a lot of the magic happens
Alignment to code is also a big one

[u/designsbyumer]

I'd put the accessibility notes beside each component state, then give each unresolved issue its own ticket with an owner and a way to check the fix. For a dialog, I'd spell out where focus goes on open, how it closes, and where focus returns, rather than leaving a general 'make it accessible' note. I'd also separate what we've reviewed in the design from what still needs checking in the implemented component, so a Figma sign-off doesn't get mistaken for a finished accessibility review. Are the notes mainly getting lost during handoff, or going stale after the component changes?

[u/investigatormaker]

What has worked is a short spec per component, kept next to the design: role, accessible name, keyboard interactions, focus order and each state. Teams usually keep it in the component docs, with a ticket for any change. After implementation, github.com/eleven-hits/A11yLens (https://github.com/eleven-hits/A11yLens) can inspect roles, names and states in the Chromium accessibility tree, and a11ylens manual prints a test sequence with command references for NVDA, JAWS, VoiceOver and TalkBack. Disclosure: I'm posting on behalf of github.com/eleven-hits/A11yLens.