Building accessibility into your design files, not after them

Accessibility audits tend to happen at the end — a list of contrast failures and missing labels, handed to whoever has time to fix them before launch. By that point, fixing things properly often means redesigning, so they get patched instead.

Pick a palette that passes before you fall in love with it

It's much easier to choose accent colors that meet contrast requirements from the start than to adjust a palette you've already built a brand around. A quick contrast check during palette exploration — not after the brand deck is approved — avoids the awkward conversation later.

Design the focus state, don't inherit it

Browser default focus rings get overridden by global CSS resets more often than not, usually without a replacement. Designing an explicit, on-brand focus state for buttons, links, and form fields — and including it in the component spec — means it's far more likely to survive into production.

Write labels while you design, not after

An icon-only button needs an accessible label. The best time to write that label is while you're designing the button and know exactly what it does — not weeks later, when whoever's filling in alt text has to guess.

A short first-draft checklist

• 01Body text and accent colors checked against their backgrounds for contrast.
• 02An explicit focus state designed for every interactive element.
• 03Every icon-only control has a written label, even in the design file.
• 04Forms checked for whether error messages are visually and programmatically tied to their field.

None of this takes long when it's part of the first draft. It takes considerably longer when it's a fix list at the end.