When we audited RHR Technologies for WCAG 2.1 AA compliance last year, we found 847 violations across the platform. The most common? Color contrast failures, missing focus indicators, and interactive elements without proper ARIA labels. None of these were malicious oversights — they were the accumulated result of designing and building fast without accessibility baked into our foundation.

The mistake most teams make is treating accessibility as a feature to be added later. It shows up in the backlog as "Accessibility sprint" — a discrete project with a start date, an end date, and a ticket for every violation. This approach works, kind of, for the violations you know about. But it doesn't prevent the next 847 from being introduced by tomorrow's feature work.

We restructured how we approached accessibility by making our design system the enforcement point. Every component in our Figma library now has an "Accessibility" section documenting: the required ARIA roles and attributes, the minimum contrast ratio for the component's text, the keyboard interaction model, and the focus management behavior. Engineers can't build the wrong thing if the right thing is in the component.

The most counterintuitive lesson: accessible design is usually better design. When you design for users with screen readers, you produce clearer heading hierarchies. When you design for keyboard navigation, you produce more logical tab orders. When you require sufficient color contrast, you produce interfaces that are easier to read in bright sunlight. Accessibility constraints, like all good constraints, improve outcomes.

We went from 847 violations to 11 (all in third-party components we're working to replace) in a four-month effort. The key was auditing first, systemizing second, and training the whole team third. You cannot add accessibility at the end of a sprint. It has to be designed in from the first wireframe.

Designing for Accessibility: Lessons from Our Design System Overhaul

Tags

Written by Alex Thompson

Comments (29)