This repository has been archived by the owner on Jan 8, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why the change?
ember-a11y/ember-a11y-testing#319 added the ability to specify additional helpers that will trigger an automated a11y audit. This allow us to enable automatic audits after
render
andfocus
, and generally improve the a11y coverage in our test suite.Previously, the audit did not happen automatically on
render
and as such we missed out on some very important automated a11y coverage in our component tests. This matters, because component tests are where we get to render all the edge cases and exotic states of our components, making it the ideal place to check those states for accessibility.What does it look like?
Note: the following video has audio
CleanShot.2021-11-12.at.12.15.14.mp4
How much slower does it make our test suite?
So no impact whatsoever 😃
What’s the catch?
If you watch the test suite in the browser, you’ll notice it “flashes” even more than before. This is the most price of all the extra audits.
How do I test it?
Try introducing and accessibility violation in a component and see if the suite picks up on it.