Ship Fast, Stay Accessible: A Practical Checklist

There’s a persistent myth that accessibility is a polish phase — something you bolt on at the end when there’s time left over. In practice, the opposite is true: the cheapest accessibility work happens at commit time, and the most expensive happens after launch.

Here’s the checklist I actually run before every release. None of it requires specialized tooling, and most of it takes under a minute.

## Keyboard first

Tab through every interactive element. If focus disappears, gets trapped, or moves in a surprising order, that’s a bug — not a nice-to-have. Every disclosure, modal, and menu needs a visible focus state and a working Escape.

## Semantics before ARIA

Reach for the native element first. A <button> with a click handler beats a <div> with role=button and four ARIA attributes every single time. The best ARIA is the ARIA you didn’t need to write.

## Contrast is a contract

Run your two most-used text colors against a contrast checker. Body text needs 4.5:1, large text 3:1. If your design system encodes color pairs as tokens, you check this once and never again.

## Motion is opt-out

Wrap every non-essential animation in a prefers-reduced-motion query. Loading spinners can keep spinning; parallax heroes should not.

## Forms tell the truth

Every input gets a real label (not placeholder-only), errors are announced to screen readers, and the error text says how to fix the problem, not just that one exists.

None of this is heroic. It’s the difference between a codebase where accessibility compounds and one where it’s perpetually overdue.