Blog

Designing Accessible Design Systems at Scale

By Priya Nair, Senior Backend Engineer·Product·May 28, 2026

Retrofitting accessibility into an existing component library is expensive precisely because the decisions that matter — color contrast ratios, focus order, keyboard operability — are structural, not cosmetic. By the time a design system has fifty consuming pages, fixing them means touching fifty call sites instead of one component.

We build contrast and focus-visible behavior into the base primitives (buttons, form fields, interactive cards) before any page consumes them, so a contrast fix or a keyboard-focus fix ships to every consumer the moment the primitive updates. Every interactive primitive gets a keyboard interaction pass and a screen-reader label requirement before it's considered done — not as a separate accessibility audit pass afterward.

The part that's easy to skip: automated tooling catches missing labels and contrast ratios, but it doesn't catch a focus order that's technically valid and still confusing to actually tab through. We test new primitives with a keyboard and a screen reader before they ship, not just with a linter.

The payoff shows up later — a design system built this way from the start doesn't need a dedicated accessibility remediation project every time a new page ships.

#React
Back to all articles

Related Articles