What is @axe-core/react?
@axe-core/react is a library that integrates the axe-core accessibility testing engine with React applications. It helps developers identify and fix accessibility issues in their React components during development.
What are @axe-core/react's main functionalities?
Basic Accessibility Testing
This code demonstrates how to use @axe-core/react with Jest and Testing Library to perform basic accessibility testing on a React component. It checks for accessibility violations in the rendered output of the App component.
import React from 'react';
import ReactDOM from 'react-dom';
import { axe, toHaveNoViolations } from 'jest-axe';
import { render } from '@testing-library/react';
import App from './App';
expect.extend(toHaveNoViolations);
test('should not have any accessibility violations', async () => {
const { container } = render(<App />);
const results = await axe(container);
expect(results).toHaveNoViolations();
});
Automated Accessibility Testing in Development
This code snippet shows how to integrate @axe-core/react for automated accessibility testing during development. It sets up axe to run accessibility checks on the React component tree and logs any violations to the console.
import React from 'react';
import ReactDOM from 'react-dom';
import { axe, toHaveNoViolations } from 'jest-axe';
import { render } from '@testing-library/react';
import App from './App';
if (process.env.NODE_ENV !== 'production') {
const { axe } = require('@axe-core/react');
axe(React, ReactDOM, 1000);
}
ReactDOM.render(<App />, document.getElementById('root'));
Other packages similar to @axe-core/react
react-axe
react-axe is a similar package that integrates the axe-core accessibility testing engine with React applications. It provides real-time accessibility feedback in the browser console during development. Compared to @axe-core/react, react-axe is more focused on providing immediate feedback during development rather than being used in automated tests.
eslint-plugin-jsx-a11y
eslint-plugin-jsx-a11y is an ESLint plugin that provides static analysis of JSX to identify accessibility issues. It helps enforce best practices and accessibility standards in React components. Unlike @axe-core/react, which performs runtime accessibility testing, eslint-plugin-jsx-a11y focuses on linting and static code analysis.
pa11y
pa11y is an accessibility testing tool that can be used to test web pages and applications for accessibility issues. It can be integrated into CI/CD pipelines and used for automated testing. While @axe-core/react is specifically designed for React applications, pa11y is a more general tool that can be used with any web application.
@axe-core/react
Test your React application with the axe-core accessibility testing library. Results will show in the Chrome DevTools console.
Previous versions of this program were maintained at dequelabs/react-axe.
Usage
Install the module from NPM or elsewhere
npm install --save-dev @axe-core/react
Initialize the module
Call the exported function passing in the React and ReactDOM objects as well as a timing delay in milliseconds that will be observed between each component change and the time the analysis starts.
const React = require('react');
const ReactDOM = require('react-dom');
if (process.env.NODE_ENV !== 'production') {
const axe = require('@axe-core/react');
axe(React, ReactDOM, 1000);
}
Be sure to only run the module in your development environment (as shown in the code above) or else your application will use more resources than necessary when in production. You can use envify to do this as is shown in the example.
Once initialized, the module will output accessibility defect information to the Chrome Devtools console every time a component updates.
Deduplicating
@axe-core/react will deduplicate violations using the rule that raised the violation and the CSS selector and the failureSummary of the specific node. This will ensure that each unique issue will only be printed to the console once.
Debouncing
The third argument to the exported function is the number of milliseconds to wait for component updates to cease before performing an analysis of all the changes. The changes will be batched and analyzed from the closest common ancestor of all the components that changed within the batch. This generally leads to the first analysis for a dynamic application, analyzing the entire page (which is what you want), while subsequent updates will only analyze a portion of the page (which is probably also what you want).
Shadow DOM
With version 3.0.0, @axe-core/react now runs accessibility tests inside of open Shadow DOM. You don't have to do anything special other than run @axe-core/react on an component encapsulated with open Shadow DOM (as opposed to closed). For more information, see the axe-core repo.
Configuration
There is a fourth optional argument that is a configuration object for axe-core. Read about the object here: https://github.com/dequelabs/axe-core/blob/master/doc/API.md#api-name-axeconfigure
const config = {
rules: [
{
id: 'skip-link',
enabled: true
}
]
};
axe(React, ReactDOM, 1000, config);
Axe-core's context object can be given as a fifth optional argument to specify which element should (and which should not) be tested. Read more from the Axe-core documentation: https://github.com/dequelabs/axe-core/blob/master/doc/API.md#context-parameter
const context = {
include: [['#preview']]
};
axe(React, ReactDOM, 1000, undefined, context);
Run the example
Run a build in the example directory and start a server to see React-aXe in action in the Chrome Devtools console (opens on localhost:8888):
npm install
cd example
npm install
npm install -g http-server
npm start
Run the tests
Install dependencies in the root directory (which also installs them in the example directory) and then run the tests:
npm install
npm test
To debug tests in the Cypress application:
npm run test:debug
Compatibility
react-axe uses advanced console logging features and works best in the Chrome browser, with limited functionality in Safari and Firefox.
Advantages
I have been asked how this is different from modules like react-a11y which test the jsx.
The main difference is that react-axe tests the accessibility of the rendered DOM. This is important because many accessibility issues exist at the intersection of the DOM and the CSS and unless you have a fully rendered DOM, you will get two sorts of inaccuracies:
- False negatives because of lacking information. Example is in order to test color contrast you must know the foreground and background colors, and
- False positives because the element being evaluated is not in its final state and the information to communicate this to the testing algorithm is not available. Example is an inert piece of code that will be augmented once it becomes active.
If you have nice clean code, number 2 will be negligible but number 1 will always be a concern.