Accessibility work has a reputation for being tedious, late-stage, and vaguely moralistic. Most of that comes from teams treating it as a compliance pass instead of a design concern. Done early, the work is small and mostly mechanical - done late, it's a rewrite wearing a polite name.
Start With the Keyboard
If you can't Tab through your UI and reach everything in a sensible order, nothing else matters. Before touching ARIA, do the keyboard pass:
- Every interactive element must be focusable and have a visible focus style. Don't let designers talk you into
outline: nonewithout a replacement. - Focus order follows reading order. If it doesn't, fix the DOM, not
tabindex. - Modals trap focus on open and restore it on close. Nothing eats user trust faster than
Esclanding them back at the top of the page.
Use the Platform Before You Reach for ARIA
The first rule of ARIA is: don't. A native <button> beats <div role="button" tabindex="0" onKeyDown={...}> on every axis - it's shorter, accessible by default, and handles edge cases you'd otherwise forget (disabled states, form submission, the Enter vs. Space distinction).
Reach for Radix or React Aria when you genuinely need a composite widget - combobox, menu, dialog. They've already fought the battles your team is about to.
Test With the Tools Users Actually Use
- Run axe DevTools in CI on your rendered pages. Catches roughly half of WCAG issues automatically.
- Turn on VoiceOver (macOS) or NVDA (Windows) for ten minutes a sprint. Automated tools can't tell you that your labels are technically correct but incomprehensible.
- Test with browser zoom at 200% and with the OS set to reduced motion. Both surface layout bugs that desktop-at-100% never will.
The work compounds. A team that makes accessibility part of the definition of done ships fewer regressions, argues about fewer redesigns, and - not incidentally - builds products more people can actually use.