Reduce CI a11y test time by using Storybook provided axe runner

[BPScott]

Why

A11y tests used to take ~12min. Before this PR they took ~25mins. With this PR they're back down to ~13mins.

Replacing pally with using the axe runner that is already loaded within Storybook's a11y addon serves two purposes:

• Speeds up our tests
• Our CI tests now reflect the same errors you see in Storybook's a11y panel, leading to easier debugging. As a bonus it seems to catch more issues than our previous accessibility testing.

What

Replace pa11y with running the axe runner that Storybook provides.

Bonus

This PR previously included several changes that fixed the newly raised issues. They were removed in 9a3d014. They can be addressed in separate follow-up PRs.

[github-actions]

🟢 No significant changes to src/**/*.tsx were detected.

[amrocha]

Interesting that a lot of the slowdown was due to storybook. I thought there was something weird when I tried running the tests locally and it took over 20 minutes, but was confused by the history since there didn't seem to be a smoking gun, and since the slowdown coincided with a move to Travis's free plan that was my first guess.

I like the idea of using the all components pages to test here. As long as the error reporting is accurate, I think we should go for that.

[amrocha]

We should also add timeouts to these jobs. If we had a timeout then this would never have happened in the first place.

[BPScott]

I did some pairing with @dominic earlier around a11y stuff.
The axe stuff is ace and it catches issues that pally didn't and it lining up with what storybook reports already is great, however I don't really want this to bloom into "and now we have to fix these issues" or have to add ignorelists to get green builds.

I'm thinking incremental improvements are still good. I'm gonna open a PR that disables docs (which gets us half-way to our old speed) which we can merge right away. Then have a follow up with a PR to move to axe, @dfmcphee is going to look at fixing the issues that axe raises, and once those are fixed we can merge the axe PR which gets us the rest of the way there.

[BPScott]

Have rebased this atop master so now it's a lot smaller. Changes have been split out and merged elsewhere:

Already merged:

• Storybook update - Storybook bump to 6.0.21 #3305
• Disabling storybook docs when doing the a11y tests - Disable SB docs as it drastically slows down iframe load #3292 and Only disable Storybook docs when running a11y tests #3304
• Fixing axe errors on due to poor contrast on AppProvider, Frame and TopBar pages - Use contrasting colors in theming examples #3293
• Fixing axe errors in Datepicker due to bad role configuration - [DatePicker] Update component to use HTML table structure #3303

Pending:

• Something to fix that Button with role of alert
• Something to fix whatever is up with autocomplete

[BPScott]

Had a bit of slack time so I've came back to this.

There is now a basic "here's a list of expected errors" that we can define that won't cause the build to fail.

If there's an error in the expected errors list that is triggered then it won't cause the build to fail.
If there's an error in the expected errors that is never triggered then it will cause the build to fail.

Unexpected errors are logged out. Expected errors are now. Either way it also gives you the story id so you can go look at that page in storybook to diagnose the issue.

[dfmcphee]

I reverted all the component changes here. We can follow up with fixes separately.

[BPScott]

haha it works!

On the other hand 68 existing errors, awwww maaaaan :(

The code for this is probably a bit fever-dreamy. Thoughts on how we could make the reporting better would be appreciated.

[alex-page]

This is a great first step, I think we can clean up logging and exceptions in follow ups.