Add automated accessibility testing

[timroes]

It would be great to have automated tests for accessibility. I would suggest using either aXe or pa11y which are both open source and integrate well in the build pipeline.

Though automated a11y tests are not the ultimate solution not to make any a11y mistakes, since there is a lot of issues they cannot check, whether or not accessibility is done right, they would help finding a lot of common issues, like missing alternative texts or input fields that aren't correctly labeled.

Finding that issues in an automated manner, would help us keeping the basic compliance we are currently introducing, since we would otherwise need to check every new feature and PR if it introduces new accessibility issues.

[bhavyarm]

For automation post 6.3.0:

• Tim/Bhavya to ping Spencer on adding aXe packages into our test framework on Kibana/X-pack-Kibana
• Bhavya and Tim work on a functional test together to add the aXe hook
• Bhavya to work with Liza/Lee/Spencer to get the hookup into build system.

cc @AlonaNadler

[rayafratkina]

Is there any plan around this?

[bhavyarm]

@rayafratkina I met with Dima last week and started discussing this again. The first step looks like - I need to write a linter rule to catch labels because the existing a11y rules are not working on EUI components. Planning to do that next week after GA is out of the door and then seeing how I can start plugging in testing in functional tests. But we did figure out that part of the testing will always have to manual. Thanks!

[bhavyarm]

@rayafratkina I am going to take a shot at adding a11y rules to EUI repo. Its going to be an experiment to see if we can catch more issues at the source.

[bhavyarm]

Closing this in favor of this: #43016