Run a11y tests in separate job
What does this MR do and why?
Context
We recently introduced automated accessibility tests using the axe-core gem in the GitLab application: https://docs.gitlab.com/ee/development/fe_guide/accessibility.html#automated-accessibility-testing-with-axe. Also, as part of a larger effort to make the GitLab application more accessible, the product accessibility working group was formed: https://about.gitlab.com/company/team/structure/working-groups/product-accessibility/.
This merge request tags feature specs that run the axe-core accessibility check and run those tests in a separate CI job. The advantages of using a separate job are:
- We need to generate a test coverage report focused on A11Y tests.
- It's easier to identify a11y check failures.
- By marking the job as "allow_failure", we can separate the task of adding the axe accessibility checks from the task of fixing the issues reported by the tool.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
- Check in the MR's pipeline that the a11y jobs ran successfully.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.