Closed tgvrssanthosh closed 1 year ago
This change looks good. I'd like to cut a new major 6.0.0 release before merging this change so that it's disassociated from the TypeScript-related work rolled up into v6. Then we can roll this out as 6.1.0.
this is fine to do in app code and even to provide an opt in to have it be done for you, but as is, the change in this pr breaks any app that uses animation/transition events tests that were passing just fine without it now fail
I would propose that a different way to handle running a11y tests after animation is to hook into the events associated with them animation(start/end) or alternatively reduce the timing to 0 so events still fire but I can imagine even that breaking people's tests that are timing dependant (intentionally or otherwise)
Copying the proposal that is added in #505
With animations and transitions in place, the a11y tests can non-deterministically fail.
For eg., lets say we have a disabled button and on certain action (click of another button) we enable the button. Lets say we have a transition property set on the button to transition the background-color of the button.
Now, lets say the disabled button contrast ratio doesn't meet the AA guidelines. The a11y tests will continue to pass since the axe-core doesn't run the tests on disabled elements. In the example that i mentioned above, when the axe-core tests run as soon as the button gets enabled, it can lead to a11y violation error since the background transition might not have completed yet.
In this PR, we are disabling animation and transition so that the transitions/animations will not affect any of the axe tests