WCAG Accessibility Checklist for Real Products
From keyboard and focus to contrast, forms, and ARIA—what product teams should lock before launch, not after complaints.
Ali Mortazavi
Founder, Paradise Code
Accessibility is product quality, not a later layer
If the keyboard fails, part of your users—and many power users—are blocked. Treat WCAG as a legal/ethical baseline and as an engineering quality signal. Late fixes cost more than designing it right from day one.
Practical target for most products: meaningful AA on primary journeys, with automated and manual testing as complements.
Keyboard, focus, and order
All primary interactions must complete without a mouse. Focus must be visible, logically trapped in modals, and restored to a sensible point on close. `outline: none` without a replacement is a design offense.
Tab order should match visual order. Build custom widgets on correct roles—or use accessible libraries such as HeroUI/React Aria patterns.
HTML semantics before ARIA
A button is a `<button>`; a link is an `<a href>`. ARIA is for when native HTML is not enough—and then it must be complete and correct. A wrong `aria-label` is worse than none because it lies to assistive tech.
Headings should form a real hierarchy. Landmarks (header/nav/main) make screen-reader navigation possible.
Forms, errors, and status
Every input needs a visible label—placeholder is not a label. Errors should be textual, field-associated, and focusable. Announce success/failure with appropriate `aria-live` regions.
For multi-step forms, expose the current step and progress to everyone—not only via color.
Contrast, motion, and media
Text and controls need sufficient contrast; pair disabled states with extra meaning. Honor `prefers-reduced-motion` for animation. Meaningful images need alt text; decorative images get empty alt.
Essential video needs captions. Forget autoplay with sound.
Testing in the definition of Done
Put automated tools (axe and similar) in CI, but do not trust them alone—they catch only part of the issues. Require manual keyboard checks and a screen-reader pass on money paths.
Every design-system component should have an a11y story. When primitives are right, features break less often.
Frequently asked questions
Is AA enough or should we chase AAA?
For most web products, AA is the realistic target. Pursue AAA on specific surfaces when needed.
Can color alone indicate errors?
No. Pair color with text/icons/patterns so color-blind users are not left behind.
Build a custom modal or use a ready one?
Unless you have deep a11y experience, use an accessible ready pattern. Modals are among the hardest widgets.
How should we prioritize?
Signup, login, payment, and primary content first; lower-traffic pages later.
Insights
Need these ideas implemented in your product?
Paradise Code supports you from consult to full delivery.