Best Accessibility Tools for React and Next.js

React and Next.js faults rarely start in a browser. They start in JSX: a div with an onClick and no keyboard handler, an image with no alt prop, a custom button that looks like a button and behaves like nothing a keyboard can reach. The best accessibility tools for React and Next.js catch those faults at the stage where they are cheapest to fix, in the editor, in a component test, or on a rendered page. This guide orders six tools by stage, and names what each stage still misses.

The order that works

Lint first, while you type. Test components next, while the component is still small. Test rendered pages next, after routing, layout, and real content join the component. Scan live pages last, after build, when sticky headers and client side state can hide focus or shrink targets. A team that only scans live pages will keep fixing the same JSX fault in many places. A team that only lints will miss faults that only show up when a component renders with real props.

Shortlist by stage:

• eslint-plugin-jsx-a11y, for static JSX rules in the editor and in pull request checks.
• Storybook addon-a11y, for axe checks on a component in isolation, with vision simulations.
• jest-axe with React Testing Library, for automated axe checks on rendered component output in a test run.
• @axe-core/react, for axe findings logged in the browser console while you develop.
• axe DevTools, for element level findings on a rendered Next.js page, with a WCAG 2.2 AA filter.
• Axeazy, for a homepage scan that leads to pull request fixes for a repo based site.

Lint stage

eslint-plugin-jsx-a11y

This plugin is a static checker for accessibility rules on JSX elements. It flags patterns such as an image with no alt prop, a click handler on a non interactive element, an anchor with no valid href, and ARIA props that do not match a valid role. It offers recommended and strict rule sets, so a team can start with the recommended set and turn on stricter rules once the easy faults are clear. The plugin runs in the editor and in a lint step, which means a fault shows up before code review, not after release.

Its limit is stated in its own docs: static analysis cannot determine values placed in props before runtime. If an alt prop comes from a variable that is empty at runtime, lint will not catch it. The docs advise pairing the plugin with @axe-core/react, which checks the rendered DOM. Treat lint as a first net, not a final check.

In Next.js, the same rules apply to pages and components, with one common snag. Link components wrap anchors, and an anchor rule can flag a Link pattern that looks odd in JSX but renders fine. Read the rule detail, fix the real fault, and only disable a rule for a single line when the rendered output is already correct and you can say why.

Component stage

Storybook addon-a11y

Storybook runs axe-core on a selected story, so you can check a button, a card, a modal, or a form field in isolation, in each state you care about: default, error, disabled, and hover. The addon panel lists violations, passes, and incomplete checks, and it adds a toolbar control to simulate vision differences. That simulation helps a developer see why a light grey label on a white card fails a contrast check, without needing a separate design review.

Storybook docs state the default rule set covers WCAG 2.0 and 2.1 A and AA plus best practices, and that the runOnly option can check against WCAG 2.2 AA. Set runOnly in your Storybook config if WCAG 2.2 AA is your target, or component passes will miss newer criteria such as target size. A component that passes alone can still fail on a live page, where layout and sticky elements change focus and spacing, so keep a page level check in the stack.

jest-axe with React Testing Library

Jest-axe adds a toHaveNoViolations matcher powered by axe-core. Render a component with React Testing Library, pass the container to axe, and assert no violations. The pattern fits a test run: a new component ships with a test, and that test fails when a label, name, or ARIA fault slips in. It also fits refactoring, since a test that passed before a change and fails after it points straight at the change.

Keep component tests small. A full page test with landmark rules can fail for reasons that have nothing to do with the component under test, such as a missing main landmark in a test wrapper. Test the component, disable or scope rules that belong to a page, and leave page level landmark and heading checks to a page scan. When a test fails, read the axe help text and the WCAG criterion it names, fix the JSX, and re-run only that test before you move on.

Rendered page stage

@axe-core/react

This package runs axe-core on a rendered React tree during development and logs findings to the browser console. It catches faults that lint misses, such as an alt prop that renders empty, a label that renders without a matching control, or a dynamic list that renders duplicate names. It is a development aid, not a production tool. Run it in development builds only, and remove it from production builds, since console logging on a live site helps no visitor.

Use it when a component looks right in Storybook and wrong on a real page. Open the page, read the console findings in order of impact, and fix the rendered output, not just the JSX source. A fault that comes from a prop, a data fetch, or a conditional render will only show up here, after real data arrives.

Axe DevTools

Axe DevTools scans a rendered page in the browser and reports the failing element, the rule, and the criterion. Its settings let you filter by WCAG 2.2 AA, which makes it the reporting tool for a Next.js page after build. Use it on routes that matter: home, search results, product detail, cart, checkout, and account pages. Check each route on mobile and desktop views, since target size and focus behaviour differ by view.

In Next.js, pay close attention to client side routing. A page change that does not move focus, does not announce a new heading, or leaves focus on a removed element can pass a static scan and still confuse a keyboard user and a screen reader user. Tab through a route change by hand after the scan, and confirm focus lands in a sensible place on the new view.

Live site stage

Axeazy for repo based sites

React and Next.js sites with a GitHub repository fit the Axeazy fix flow directly. Axeazy scans with 98 automated checks from axe-core rules covering WCAG 2.0 A and AA, 2.1 AA, 2.2 AA, and best practices, across 14 fix categories that include alt text, form labels, link names, button names, ARIA labels, keyboard tab order, iframe titles, table headers, landmarks, and heading structure. Fixes arrive as a real pull request with a visible code diff that the owner or developer reviews and merges. Nothing is applied without that review.

That review step matters for React code. A fix to a shared component can affect many routes, so a diff that a developer can read, comment on, and test before merge beats a silent change. Colour contrast is handled with care in this flow: the scan detects it and calculates a correct colour, but a visible colour change is never applied without owner approval. Read the fix detail on the methodology page before you set up a scan, so the team knows which fix types come as a diff and which need a human decision.

A practical stack for a small React team

Start with jsx-a11y in the editor and in pull request checks. Add Storybook checks for shared components, with runOnly set to WCAG 2.2 AA. Add jest-axe tests for form fields, modals, menus, and any component with custom interaction. Run @axe-core/react in development for pages with real data. Scan rendered routes with axe DevTools before release, with the filter set to WCAG 2.2 AA. Then run a live homepage scan for the record, and keep the pull request flow for fixes that touch shared code.

Add two manual habits to that stack. Tab through every new flow from the top, and check focus after each route change. Open each new form with a screen reader or with the browser accessibility pane, and confirm each control has a clear name and each error message names the field it belongs to. Those habits catch the faults that every tool in this list can miss: a label that is technically present and practically unclear.

Related reading: How to Choose an Accessibility Tool: 10 Criteria and Best Accessibility Tools for Small Business, and Best Accessibility Tools for Ecommerce Sites. For a quick self test on focus, try the focus quiz.

FAQ

Do I need both jsx-a11y and axe DevTools?

Yes, for most React projects. Jsx-a11y catches JSX patterns before render, and axe DevTools catches rendered output after props, data, and layout join the component. One checks source, the other checks the page a visitor meets. Use both, and keep the rules in sync where you can.

Can Storybook replace a page scan?

No. Storybook checks a component in isolation, with test data and a test layout. A live Next.js page adds routing, sticky headers, real content length, and client side state. Keep Storybook for components, and scan rendered routes before release.

Should @axe-core/react run in production?

No. It is a development aid that logs findings to the console. Run it in development builds, fix the findings, and keep production builds clean. A production console log helps no visitor and can leak detail about page structure.

What breaks most often in Next.js accessibility work?

Focus after route change, and small targets on mobile views. A route change that leaves focus behind, and an icon button that shrinks below 24 by 24 CSS pixels, both pass a quick glance and fail a keyboard or touch pass. Check both by hand on every new route.

Last checked: October 31, 2026

Sources

• eslint-plugin-jsx-a11y overview
• Accessibility tests in Storybook docs
• jest-axe guide
• Axe DevTools extension settings from Deque
• WCAG 2.2 from W3C
• Axeazy methodology page

For repo based React and Next.js sites, start with Axeazy's free scan.