Accessibility is one of those things developers talk about a lot but rarely prioritise until a client asks — or worse, until a lawsuit happens. I've been guilty of this too. But after working on a healthcare platform where patients with visual impairments needed to book appointments, my perspective shifted completely.
Start with semantics
The single highest-leverage thing you can do is use the right HTML element for the job. A WCAG AA requires a contrast ratio of at least 4.5:1 for normal text. I use the [APCA contrast calculator](https://www.myndex.com/APCA/) during design — not after. Catching a failed contrast ratio at the Figma stage costs nothing. Catching it in QA means going back to the designer, regenerating assets, and re-testing. Don't skip this step. Every interactive element needs a visible focus ring. Removing Unplug your mouse. Navigate your entire UI using only Tab, Shift+Tab, Enter, and Space. If you can't reach or activate something, neither can a keyboard-only user. This takes ten minutes and routinely surfaces issues that automated tools miss. Accessibility isn't a feature you add. It's a quality bar, like performance or security. Build it in from the start, and it costs almost nothing. Bolt it on at the end, and it's a nightmare. Your future self — and your users — will thank you. is not a is not a Colour contrast is non-negotiable
Focus states matter
outline: none without providing a custom focus style is an accessibility violation. The good news: modern CSS makes beautiful focus rings trivial::focus-visible {
outline: 2px solid #70FF00;
outline-offset: 3px;
border-radius: 4px;
}Test with a keyboard
Final thought