Accessibility in React Apps: A Practical A11y Guide
Semantic HTML, ARIA, keyboard navigation, and testing—build React apps that work for everyone.
Accessible UIs are better for all users and often required by law. Here’s how to do it in React.
Accessibility and inclusive design
Essentials
Semantic HTML — Use <button>, <nav>, <main>, <article>, headings in order. Don’t use <div> and <span> for everything; semantics give meaning to assistive tech.
Focus and keyboard — Ensure all interactive elements are focusable and order is logical. Support Tab navigation and avoid tabIndex={-1} unless you manage focus yourself (e.g. modals).
ARIA when needed — Use ARIA when HTML isn’t enough: aria-label, aria-expanded, aria-live. Prefer native elements (e.g. <button>) over custom ones with ARIA.
Color and contrast — Don’t rely on color alone. Check contrast (WCAG AA 4.5:1 for text). Use focus indicators (outline or visible ring).
Forms — Associate labels with inputs (<label for> or wrap). Show errors clearly and link them with aria-describedby.
A11y maturity (team survey):
Accessibility practice level
Testing
Use eslint-plugin-jsx-a11y, axe DevTools, and manual keyboard/screen reader checks. Test with real users when possible.
A short a11y intro for devs:
Takeaway
Start with semantics and keyboard support. Add ARIA where needed, test with tools and assistive tech, and iterate. Accessibility is part of quality, not an extra.
