Every product team we work with eventually ships a feature that fails an accessibility audit. The good news: most accessibility failures are predictable. The better news: they are preventable with a few habits baked into the design process.
Here is what we teach our clients.
Test with a screen reader on day one.
VoiceOver on macOS, NVDA on Windows, TalkBack on Android. Pick one, install it, and run your feature through it before you write a line of code. The first session will be uncomfortable — that's the point.
Semantic HTML is 90% of the work.
Native HTML elements come with accessibility for free. Use a real <button> instead of a styled <div>. Use <label> instead of a placeholder. Use <nav>, <main>, <article>. The browser does the rest.
Focus order is a design decision.
The order in which elements receive focus when a user tabs through the page is a design surface. Think about it. Map it. Test it. Don't let it happen by accident.
Colour is not enough.
If your error state is communicated only by red colour, screen reader users will not perceive the error. Pair colour with iconography, text, or ARIA live regions.
Run an audit before launch, not after.
Most of our clients' accessibility bugs are caught in the first audit and never make it to production. The teams that audit at the end spend 3x as long fixing bugs they could have prevented.
Accessibility is a craft. It is also the right thing to do.