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

E.Y.

Jun 14, 2020·3 min read

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

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:

“jsx-a11y/label-has-associated-control”: [ 
  2,
  {
    “labelComponents”: [
      “”
    ],
    “labelAttributes”: [
      “”
    ],
      “controlComponents”: [
       “TextInput”
    ],
      “assert”: “either”,
      “depth”: 5
   }
]

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.

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 “enforcement” to 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:

{
  ...
  "scripts": {
    "lint": "./node_modules/.bin/eslint ./app/**/*.*js* --fix",
    ...
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.(js|jsx)": [
      "npm run ./node_modules/.bin/eslint --fix",
      "git add"
    ]
  },
  ...
}

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

Happy linting! 🌟✨💫