Automated Accessibility Testing for React
Accessibility is important to the Chan Zuckerberg Initiative (CZI), because we envision a country where every student enters adulthood prepared to reach their full potential. This vision isn’t possible if students or teachers are excluded because of a disability.
To support equity and inclusion, we recently started to test our React components for accessibility. Doing so provides faster feedback to engineers, and helps prevent many accessibility problems from getting to our users.
To test for accessibility, we
- Write React component examples in component story format.
- Use axe-storybook-testing to test these stories for accessibility.
- Run the tests in our continuous integration pipeline, just like any other in our test suite.
Write stories for components
When writing “normal” unit tests with something like React Testing Library, you provide an example of a component for the test. These are the “units” of unit testing.
// Coffee.test.jsxit('is amazing', () => {
// The example, or "unit"
render(<Coffee type="espresso" />); // Assertion, which uses the example
expect(await screen.findByText('delicious')).toBeInTheDocument();
});
We need the same kind of examples to test for accessibility. Component story format is a convenient way to do just that. You can write stories for each component, covering the various states you want to test.
// Coffee.stories.jsxexport default {
title: 'Coffee',
component: Coffee,
};// Same example
export const Espresso = () => <Coffee type="espresso" />;// A different example
export const PourOver = () => <Coffee type="pourover" />;
To make sure these work with the tools in the next sections, we enforce best practices with an eslint plugin.
Also, these stories can be used for more than accessibility testing. You can re-use them in unit tests, use them for visual regression testing, and see them in Storybook.
Run axe-storybook-testing on stories
To check stories for accessibility, we need a way to render each story, analyze them for accessibility, and report the results.
Enter axe-storybook-testing. It’s a command-line interface that
- Builds stories into an HTML file
- Opens the generated HTML file in a browser of your choice
- Runs Deque’s axe-core on each story, which detects accessibility problems
- Prints information about any issues it finds
- Returns an exit code indicating whether there were any failures
Axe-storybook-testing lets us easily test stories for accessibility on your laptop or development machine. Because the tests run in a real browser, you get the benefit of all axe-core checks, including the color contrast one. Color contrast checks can’t be done in jsdom, which is why we don’t use jest-axe.
The final step is to run as part of a CI pipeline, to prevent accessibility failures from being introduced in the first place.
Run the tests on CI
Like any test, you can run these accessibility tests on CI. Someone’s work with test failures can’t be merged, and engineers get feedback about issues before they’re shipped to your users.
Not every accessibility problem can be detected with automated tools. For example, axe-storybook-testing can’t tell if your tab order is correct, so there will always be a need for manual accessibility testing.
But we may as well catch the many issues that can be detected automatically, and provide useful, fast feedback to engineers.
If you want to test your React components for accessibility, try out axe-storybook-testing in your projects. And feel free to open an issue if you run into any problems.
Interested in helping to build tools to empower teachers and prepare students for life beyond school? Check out our careers page.
