Building accessible frontends that scale

Most teams treat accessibility as a pre-launch audit: run axe, fix the loudest violations, ship. That works fine for a marketing page nobody touches again. It falls apart on a high-traffic eCommerce platform where dozens of engineers ship features every week, and every one of them can quietly regress a focus trap or a color contrast ratio.

The shift that actually moved the needle for us was treating accessibility as a default, not a review gate.

Bake it into the primitives

If your button component is accessible, every button in the app is accessible — until someone reaches for a raw <div onClick>. The fix isn't more code review, it's fewer opportunities to opt out. We consolidated interactive elements (buttons, links, form fields, modals) into a small shared component set with:

• Correct semantic HTML by default (<button>, not <div role="button">)
• Visible focus states that survive design refreshes
• ARIA attributes wired up once, not per usage

Once those primitives existed, "is this accessible" mostly became "did you use the primitive."

Keyboard-first, not keyboard-also

Mouse-first design with keyboard support bolted on afterward always feels bolted on. Tab order fights the visual layout, modals trap focus incorrectly, and dropdowns are unusable without a mouse. Designing keyboard flows first — then layering visual polish — produces a cleaner result for everyone, not just keyboard and screen reader users.

Make regressions visible, not just possible to catch

Automated tools (we lean on axe-core in CI and Lighthouse in PR previews) catch maybe 30-40% of real issues. The rest — logical heading order, meaningful alt text, focus management on route changes — need a human. What worked for us was pairing automation with a lightweight manual pass on any PR that touches interactive UI, rather than a separate audit cycle that happens too late to matter.

The payoff wasn't just compliance

The interesting outcome wasn't fewer WCAG violations — it was that mobile-first, accessible components also converted better. Larger tap targets, clearer focus states, and less layout shift helped every user, not just the ones accessibility work is nominally "for." That correlation is why this kind of work is worth defending in a roadmap conversation: it isn't a tax on velocity, it's a form of it.