Add automated a11y testing

[james-nash]

Is your feature request related to a problem? Please describe.
We should add some a11y testing to our UI components (after all, Inclusive is one of Gravity's principles!).

Such tests could flag common pitfalls like:

• missing alt attributes on images
• missing associations beween <label> elements and their associated inputs
• empty links and buttons
• incorrect use of aria-* attributes
• insufficient color contrast
• etc.

This should help us ensure that our UI components individually are designed and built correctly and won't prevent downstream consumers from assembling accessible UIs from them.

Describe the solution you'd like

1. Evaluate available a11y testing tools and pick an appropriate one.
   • aXe and Pa11y are obvious candidates to consider, but there may be more.
2. Set it up, so that every UI component in our pattern library gets tested (and ones we add in future automatically get tested too).
   • Tools like aXe and Pa11y tend to operate on HTML and/or hosted pages (which they then access via a headless browsers), so we can probably set this up within packages./gravity-ui-nunjucks/ and have the tools access the per-component pages that Fractal already generates for us. Note though that we want to specifically test our component HTML, not Fractal's pattern library UI. The "preview" pages it creates (e.g. http://localhost:3000/components/preview/superseded ) look appropriate. So, if we could get our chosen tool to iterate over all the preview pages, that would be ideal.
3. Add an NPM script to the package.json to make it easy to run the tests. Perhaps test:a11y, so we can invoke them by doing npm run test:a11y.
   • It probably makes sense to also add a test script, which for now would just run the a11y tests. In time, if we add other kinds of tests, they can be appended. That way npm run test will run all tests, where as npm run test:a11y will only run the a11y tests
   • I think doing this will also ensure that our Travis CI will execute these tests. It already run's the root package's test script, which calls lerna run test and that in turn will run the test script for all sub-packages that have one. Maybe verify this is indeed working as expected and, if not, do whatever's needed to fix it. The CI should be running the a11y tests.
4. Update docs as needed
   • Update the README.md with instructions on how to run the tests.
   • If you think it's worthwhile to provide additional details or intructions, then add to or update the docs as needed

At this point, I'd say the work is done.

If the tests highlight lots of errors (and thus cause CI builds to fail), we may need to temporarily disable the a11y tests on CI builds and raise new Github issues to get the a11y bugs fixed. On the other hand, if there's only a few bugs and they're trivial to fix, then it might be easier to just fix them as part of this work.

[james-nash]

Closing this as it got done in PR #364

[buildit-dev]

🎉 This issue has been resolved in version 3.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀