React is the most widely used JavaScript UI library, powering applications from small marketing sites to complex enterprise platforms. React's component model and virtual DOM give developers unprecedented control over rendered HTML - but that control means every accessibility decision is manual. Under the EAA, any React application serving EU consumers must meet EN 301 549 requirements.
Common React accessibility issues
Custom components replace native elements without preserving semantics
React makes it trivially easy to build custom buttons from divs, custom selects from lists, and custom inputs from spans. These custom components almost always lose native keyboard support, ARIA roles, and screen reader announcements that browser-native elements provide for free.
State changes aren't announced to assistive technology
React excels at reactive state updates - but when a component re-renders due to state change, screen readers don't know what changed. Toast notifications, form validation errors, loading states, and live data updates all need explicit ARIA live regions.
Focus management breaks during conditional rendering
React's conditional rendering (ternary operators, short-circuit evaluation, state-based JSX) can destroy and recreate DOM elements. When a focused element is unmounted and replaced, keyboard users lose focus entirely - it jumps to the document body.
Fragment and div soup creates meaningless DOM structure
React components often wrap content in fragments or extra divs for layout purposes. At scale, this produces deeply nested DOM trees with no semantic meaning, making it nearly impossible for screen readers to understand page structure.
Single-page application routing lacks navigation announcements
React applications using React Router, TanStack Router, or custom routing solutions handle navigation client-side. Without explicit implementation, route changes don't trigger screen reader page announcements, leaving users unaware they've navigated.
JSX makes invalid HTML easy to produce
React's JSX allows HTML structures that are technically invalid - like nesting interactive elements, putting block elements inside inline elements, or duplicating IDs across component instances. These produce unpredictable behaviour in assistive technology.
How Lumi works with React
Lumi scans your React application in its fully rendered, hydrated state - not your JSX source code. Our five engines navigate through client-side routes, interact with stateful components, and test the actual DOM that assistive technology encounters. Set up monitoring to catch regressions with every deployment.
React-specific WCAG gotchas
Component libraries are not automatically accessible
Using a React component library (Material UI, Ant Design, Chakra UI) doesn't guarantee accessibility. Libraries vary in ARIA correctness, and using them incorrectly (overriding styles, skipping required props) breaks whatever accessibility they provide.
Testing JSX is not the same as testing rendered HTML
React unit tests often test component logic, not rendered accessibility. Jest snapshots capture JSX structure but don't validate ARIA correctness, focus order, or colour contrast in the actual browser environment.
React portals create DOM order mismatches
React portals (used for modals, tooltips, and popovers) render content outside the parent DOM tree. This can create mismatches between visual order and DOM order, confusing screen reader navigation and focus management.
Scan your React site for free
See how your site measures up against WCAG 2.2 and EN 301 549 - in 30 seconds, no signup required.
Frequently asked questions
Does React support accessibility?
React supports standard HTML attributes including all ARIA attributes (written in camelCase, like aria-label and role). React also provides Fragment to avoid unnecessary wrapper elements. But React doesn't enforce accessibility - it outputs whatever HTML your components produce.
What React accessibility tools should I use?
eslint-plugin-jsx-a11y catches common issues at build time, and @axe-core/react can log accessibility violations in development. These are useful but not comprehensive - they catch a subset of WCAG requirements and can't test visual issues like colour contrast or focus visibility.
How do I make React modals accessible?
Accessible React modals need focus trapping (focus stays inside the modal), an Escape key handler, proper ARIA roles (dialog or alertdialog), a label (aria-labelledby or aria-label), and focus return to the trigger element on close. Libraries like Radix Dialog and React Aria handle most of this correctly.
Does the EAA apply to React single-page applications?
Yes. The EAA applies based on the service being provided, not the technology used. React SPAs providing services to EU consumers - e-commerce, banking, media, SaaS - must meet EN 301 549 just like any other web application.
Related resources
Last reviewed: April 2026. Content is reviewed quarterly for accuracy.