A Reference Manual for Automating Accessibility Testing in React/Gatsby(ii)

From various testing framework integrated with axe-core, to linting plugins and full page auditing…

Image for post
Image for post
Photo by Andriyko Podilnyk on Unsplash

In my last post, I talked about tools that integrated with existing testing libraries/frameworks, and this time I’m going to show you how to make your linting tool contribute to improving your Accessibility standards.

There are quite a few linting plugins for accessibility, but among others the one I found particularly popular is eslint-plugin-jsx-a11y.

(There is also a popular one react-a11y, which obviously is very good, but now become depreciated as axe-core came to the market)

To use eslint-plugin-jsx-a11y, you need to have eslint available as well.

npm install eslint eslint-plugin-react eslint-plugin-jsx-a11y --save-dev

In your .eslintrc file, you can configure the rules as you prefer, for example:

Fortunately for Gatsby users, they don’t need these additional effort to use eslint-plugin-jsx-a11y , since Gatsby ships with the eslint-plugin-jsx-a11y package by default.

However, noted that using a local .eslintrc file will overrid Gatsby’s default linting and disable the built-in eslint-loader So if you want to have eslint-loader pulls in your customizations, you need to enable the loader yourself either by using the Community plugin gatsby-plugin-eslint or by copying some of the default plugins setting manually into your own .eslintrc file.

The other alternative tool I’ve found about is tslint-react-a11y — a tslint tool for TypeScript users. Behind the scene, instead of using react-a11y (suggesting by its name!), it actually uses a subset of a11y related rules from a Microsoft developed tslint package: tslint-microsoft-contrib.

It’s difficult to judge how it performs comparing to the more popular jsx-a11y since I never used it personally.

But jsx-a11y has axe-core as its dependencies while I didn’t see that in tslint-microsoft-contrib (not say it’s a bad thing, just as a fact). Also while there are roughly 30 rules in jsx-a11y you can customise, in tslint-react-a11y there are about 20.

Image for post
Image for post
graph showing download volume between jsx-a11y and microsoft tslint/tslint-react-a11y

If you are keen to go for jsx-a11y in your TypeScript project, you can still use a .eslintrc file with @typescript-eslint/parser .

So the linting tools from above will help identify accessibility breaches through in-editor report, but this can be omitted in development. It would be great if we have some “enforcementto make sure all the violations that linting tool signals won’t be committed into codebase at all.

If you read my previous blogs about using Git Hooks and Husky, then you know what I’m talking about.

By installing Husky, we can easily set up npm script to create a pre-commit or pre-push hook for preventing accessibility violations from getting into the remote repository.

Alongside Husky, another tool I find really useful is Lint-Staged . It’s developed based on the assumption that we as developers don’t want to running linting check for the whole project at every commit, which damages developer experience. So with Lint-Staged, only files with configured pattern that are modified by you are tested by linter instead of the whole project.

So you packages.json will look like this when you have these 2 helpers:

Now whenever you commit, your linting will run against files you defined in the pattern.

Happy linting! 🌟✨💫

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store