Define technical strategy to implement automatic a11y checks in GitLab application

As a Product Accessibility Working Group, we want to create a strategy for including automated accessibility checks into our CI/CD process.

We have already discussed the following:

• For gitlab.com, we will be using axe-core-gem. Here's the proof of concept, with working example and documentation: !104195 (merged)
• The most beneficial and sustainable place for the tests will be in feature specs. This will allow us to cover the whole page/view rather than components in isolation. It will also take away the burden from engineers to include tests for every newly created component, which are created more often then the views.
• Another advantage of writing the automated a11y test in the existing test files is that can reuse the existing "bootstrap code" that creates the database fixtures required to run a fixture.
• We want to group the tests. We could do this by defining a tag for all a11y tests. We can exclude the tests with the a11y tag from the jobs that run feature specs and create a separate a11y job that target those tests.
• We want to create a Danger bot warning for not including axe in feature specs. The warning serves just as a nudge for the author to think about adding the axe spec. This warning should appear only if the feature spec is modified in the MR. The idea is similar to the warning we get when we modify files which have disabled eslint rules on them.
• We are aiming for WCAG 2.1 AA compliance.

In this epic we want to discuss and document the strategy for implementing the test cases, as well as the instructions on how to contribute to the efforts of the working group.