This is a tracking issue for the Unified a11y tests project. Its purpose is to keep track of the overall status of the project and tasks and plan everything around it.
⚠️ Problem
Accessibility (a11y) is increasingly required in modern UIs. This is already enforced for many government services around the world, and is also becoming mandated for private services as well, e.g. European accessibility act which goes into law in June 2025.
Today, Storybook’s accessibility addon addon-a11y is one of the most popular addons not bundled with Storybook at 1.6M weekly npm dl’s. It provides a way to interactively test and debug a11y violations in stories
The biggest a11y product gap today is that you have to manually click on each story to see the a11y violations for that specific story. There is no way to do this across all stories in batch.
If we can solve this problem in the context of our Unified UI Testing project, it will go a long way towards improving support for A11y workflows in Storybook AND make our unified testing UI that much more compelling.
🏁 Goals
As a Storybook user, I want to be able to run a11y tests across all the stories in my Storybook, so that I can see the full a11y status of my project.
🚩 Milestones
## Finalize API's - Deadline: 13th Nov
- [x] Finalize Reporting API specification - Event name and payload conventions | capabilities
- [x] Finalize afterEach specification
- [x] Investigate discrepancy cases and how to deal with them
## A11y Implementations - Deadline: 6th Dec
- [ ] Register a11y Sub Test Provider (Batch run and single story run)
- [ ] Change a11y reporting mechanism - Use Reporting API
- [x] Implement Vitest report proxy of a11y test results
- [ ] Implement parameter-based options to control a11y behaviour in UI and Vitest
- [ ] Handle discrepancy between Vitest run and Browser run
## After QA
- [ ] Blog post. “Component testing for Accessibility” highlighting the new test behavior, filtering, and debugging workflow.
## Nice to have
- [ ] A11y addon improvements. Rework addon experience per Accessibility addon V2 design
- [ ] Investigate: Optimize accessibility testing to manage inherited violations in Storybook components
- [ ] https://github.com/storybookjs/storybook/pull/29552
- [ ] Improve accessibility of our own Storybook components
🚩 Out of scope
Create a unified API to replace Status API, Testing Module API and Reporting API.
🧑🤝🧑 Who: @kasperpeulen and @valentinpalkovic
This is a tracking issue for the Unified a11y tests project. Its purpose is to keep track of the overall status of the project and tasks and plan everything around it.
⚠️ Problem
Accessibility (a11y) is increasingly required in modern UIs. This is already enforced for many government services around the world, and is also becoming mandated for private services as well, e.g. European accessibility act which goes into law in June 2025.
Today, Storybook’s accessibility addon addon-a11y is one of the most popular addons not bundled with Storybook at 1.6M weekly npm dl’s. It provides a way to interactively test and debug a11y violations in stories
The biggest a11y product gap today is that you have to manually click on each story to see the a11y violations for that specific story. There is no way to do this across all stories in batch.
If we can solve this problem in the context of our Unified UI Testing project, it will go a long way towards improving support for A11y workflows in Storybook AND make our unified testing UI that much more compelling.
🏁 Goals
🚩 Milestones
🚩 Out of scope