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 <button> is not a <div onClick>. A <nav> is not a <div className="nav">. Screen readers rely on these semantic cues to describe the page to users. Get this right first, and you've solved 60% of accessibility for free.
Colour contrast is non-negotiable
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.
Focus states matter
Every interactive element needs a visible focus ring. Removing 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
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.
Final thought
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.