Designing for accessibility is just designing well
The most accessible products we ship are not the ones built by teams that treat accessibility as a separate workstream. They are the ones built by teams who treat accessibility as part of the definition of "done" for every feature, the same way they treat performance and error states.
The five things that catch most regressions
Most accessibility regressions in production come from a small set of patterns. Address these five and you have caught the majority of issues before they ship.
Semantic HTML. Use the element that means what you want. <button> for actions, <a> for navigation, <label> for form labels. Most ARIA is a workaround for the wrong element.
Visible focus. Every interactive element has a visible focus ring. The native one is fine. Removing it without replacement is the single most common accessibility regression on the modern web.
Keyboard navigability. Every interactive control reachable and operable with the keyboard. Modal dialogs that trap focus. Menus that close on Escape. This is testable manually in five minutes per page.
Color contrast. Body text at 4.5:1 against its background, large text and UI elements at 3:1. Modern design tools surface this in real time; there is no excuse for shipping below the bar.
Text alternatives. Every meaningful image has an alt, every icon-only button has an accessible name, every form input has a programmatically-associated label.
The tooling that pays back
Two automated checks catch a meaningful percentage of issues at near-zero cost:
- An axe-core check in your CI on every changed page.
- An eslint-plugin-jsx-a11y rule set on your React or Vue codebase.
Neither replaces manual testing with assistive technology, but both will catch the regressions that are most likely to slip through review.
The harder part
The genuinely hard accessibility work is in complex, custom widgets — combo-boxes, date pickers, rich-text editors, data grids. The right answer is almost always to use a vetted library rather than build your own, and to budget time for testing against a real screen reader (VoiceOver and NVDA cover most of the bases).
Treat accessibility like security: a non-negotiable property of the product, owned by everyone, automated where possible, manually verified where it matters. Done well, it is invisible. Done badly, it is the only thing some of your users will remember.