Accessibility isn't a checklist. It's a design decision you make early.

For a long time, I treated accessibility the way most teams do - as something to check before launch. Contrast ratios, alt text, keyboard navigation. Important, but bolted on at the end.

What changed my mind was watching a support ticket come in about a bulk-upload flow I'd designed. A user was navigating entirely by keyboard because of a motor impairment, and the flow I'd built assumed a mouse at every step. It worked, technically. It just wasn't usable for him.

That's the thing about accessibility - it rarely shows up as a bug. It shows up as someone quietly giving up on your product without ever telling you why.

A few things I now treat as non-negotiable, early in the process rather than late:

• Design the keyboard path first, not last. If tab order and focus states are an afterthought, they'll always feel like one.

• Don't rely on color alone. Status, errors, and states need a second signal - an icon, a label, a shape.

• Write real alt text, not filler. "Image of a chart" tells a screen reader user nothing useful.

• Test with the constraint, not just for it. Try navigating your own flow without a mouse before asking anyone else to.

None of this is about ticking a compliance box. It's about not quietly excluding people who never file a complaint - they just leave.

The teams that build genuinely accessible products aren't the ones with the biggest checklist. They're the ones who bring it into the room during the first design review, not the last one.