Investigate testing accessibility of reusable component styles
Categories
(Toolkit :: UI Widgets, task)
Tracking
()
People
(Reporter: mkennedy, Unassigned)
Details
We use tokens/CSS variables to style our reusable components. However, there's currently no way to ensure that their computed values won't cause issues when used in certain components or combinations. We do run light accessibility checks for components via Storybook using axe-core. But it may be worth also expanding our test coverage around color/style expectations, especially as we're making changes to the tokens to approve our palette, like in Bug 1861526.
|
Reporter | |
Comment 1•12 days ago
•
|
||
FWIW, I think this would be even more valuable if this style testing can expand across consumer usage. For instance, it would be a win if we have tests that will raise when a token update causes a consumer's component to change in a way that causes an accessibility issue.
|
|
Reporter | |
Updated•8 days ago
|
|
||
Comment 2•8 days ago
|
||
This is definitely worth chatting with the a11y team about. We already check that interactive elements have labels and are focusable when we run our a11y tests. We could add contrast checking to that, although it could be tricky with transparencies, backgrounds being set by parents, etc.
This may also be checked against all interactive elements as opposed to only our reusable components. It may make sense to move this to an a11y component as well. We'll update the bug after discussing with a11y
Description
•