EAA compliance for React: WCAG 2.1 AA checklist & fixes

What the EAA actually requires from a React site

React is accessibility-neutral, so under the EAA the compliance obligation is entirely about your component patterns and, critically, the fact that a client-rendered SPA ships a near-empty HTML shell until JavaScript executes. EN 301 549 conformance forces you to fix hand-rolled modals, tabs, and comboboxes that re-implement keyboard behaviour incorrectly, div-based role="button" elements missing onKeyDown handlers, and SPA route changes that never announce to assistive tech. For a pure client-side React app the requirement effectively demands correct focus management and live-region announcements that a server-rendered site would get more easily.

React underpins a very wide range of products, from small internal-facing tools to large consumer SPAs, so the fine exposure depends heavily on whether the specific app is a consumer-facing service in EU markets. A funded B2C SPA faces the full weight of national penalties, including turnover-percentage regimes for larger operators, while a small startup's app faces fixed per-breach fines. The client-render architecture adds a subtle risk: if the initial payload is inaccessible, an automated audit of the served HTML can flag the whole app as failing before any interaction is even tested.

The pragmatic React fix is to stop hand-rolling interactive widgets and adopt a vetted primitives library (Radix, React Aria, Headless UI) that ships focus trapping, Esc handling, and ARIA for free, which the component team can swap in incrementally. Add an SPA route announcer, wire eslint-plugin-jsx-a11y and @axe-core/react into development, and use the Storybook a11y addon for per-component checks. This is engineering work measured in sprints for a large app, but individual widget swaps are quick wins that remove whole classes of failures at once.

Top WCAG failures we see on React sites

Across hundreds of React scans, the same handful of issues show up over and over. None of them require ripping the theme apart — most are fixable in a few hours by someone comfortable in the platform's editor or template files.

• Custom modals without focus trap or restore

  Hand-rolled <div> modals usually skip Tab cycling and never restore focus to the trigger. Use a vetted library (Radix, React Aria, Headless UI).

  2.4.3, 2.1.2 — Level A

• Click-only ARIA roles

  role="button" on a <div> needs onKeyDown for Enter and Space. Most teams forget the keyboard half.

  2.1.1, 4.1.2 — Level A

• SPA route changes are silent

  react-router and react-navigation do not notify assistive tech when the URL changes.

  4.1.3 — Level AA

Concrete code fixes for React

Below are copy-paste fixes for the most common React issues. They assume you have access to your theme code or the platform's custom-code injection panel. If you cannot edit code directly, share these snippets with whoever maintains the site — every one of them is a ten-minute change.

import * as Dialog from '@radix-ui/react-dialog';

export function MyModal() {
  return (
    <Dialog.Root>
      <Dialog.Trigger>Open</Dialog.Trigger>
      <Dialog.Portal>
        <Dialog.Overlay />
        <Dialog.Content>
          <Dialog.Title>Title</Dialog.Title>
          <Dialog.Close>Close</Dialog.Close>
        </Dialog.Content>
      </Dialog.Portal>
    </Dialog.Root>
  );
}

Tools and plugins worth installing first

• eslint-plugin-jsx-a11y

• @axe-core/react in development

• Storybook a11y addon for per-component checks

How to scan a React site without missing anything

Automated scanners catch about 30–40% of WCAG issues; the rest need manual review. The good news is that the 30–40% includes the most expensive issues to remediate after the fact, so an automated scan is the cheapest way to get unstuck. Run one before you change a line of theme code.

• Run scans against the production bundle, not development. Hot reload can mask issues.