Designing Accessible Design Systems at Scale
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.
Back to all articlesRelated Articles
Beyond Accessibility Compliance: Designing Interfaces People Actually Want to Use
A WCAG-compliant interface and a genuinely usable one aren't automatically the same thing.
How We Cut P95 API Latency by 40% Without a Rewrite
Three changes that mattered more than the framework we were using.
A Practical Guide to RAG Pipeline Evaluation
The metrics that actually predict whether your RAG system will hold up in production.