One Story, Many Feedback Loops
A Storybook story can answer more than “does this component render?” This chapter follows the same rendered state into accessibility checks, visual baselines, living documentation, publication, and team review. The goal is to match each feedback loop to the question it can actually answer, then use Storybook’s setup and integration model to adopt only the loops that fit a project’s framework, risk, and maintenance capacity.
Different loops ask different questions
The story is a shared starting point, not a universal quality score. Its rendered DOM can be inspected for accessibility heuristics. Its pixels can be compared with a known baseline. Its args and metadata can populate documentation. Its indexed identity can be published for review. These uses overlap because they begin from the same state, but they measure different properties and have different failure conditions.
Accessibility checks inspect the rendered result
Storybook’s Accessibility addon runs axe-core against the rendered DOM. That is an important choice. A source-level linter can identify suspicious markup or missing attributes before a component is compiled, but the browser is the place where the final DOM, focus behavior, roles, and styles exist. The addon therefore examines the output of the same preview lifecycle that a person sees.
The addon attaches an after-render check to the story. It builds an axe context that includes the story’s document while excluding Storybook’s own internal UI, applies configured rules, runs the audit, and records the result against the story. Runs are queued because axe-core is not designed for arbitrary parallel execution. The result can contain violations, passes, or items that need manual confirmation.
The enforcement mode is configurable. off disables automated checks for a story while leaving manual inspection available. todo runs the check and presents a known problem as a warning. error turns a violation into a failing test when the test integration is configured to enforce it. This three-way distinction gives a team a way to introduce a standard without pretending that existing accessibility debt can be repaired in one change.
A sensible use of todo is narrow and temporary. A team can begin with failures visible, mark known exceptions as work to address, fix a foundational component such as a Button, and remove the exception when it passes. New stories can then inherit a stronger default. The mechanism is useful because it turns an accessibility backlog into visible story-level state rather than hiding it in a separate document.
The boundary is equally important. Automated accessibility tests are a first line of QA, not a complete assessment of inclusive design. The source notes that checks can be affected by browser environment and by asynchronous rendering. If a component has not reached its final state when axe runs, the result may miss a violation. Passing the audit does not establish that keyboard flow is understandable, content is meaningful, or people using assistive technology will have a good experience. The story provides a reproducible rendered condition; human review supplies the rest of the judgment.
Visual tests compare pixels, not intentions
Visual testing asks a different question: has the rendered appearance changed from a known baseline? The visual tests addon can send the story collection to a cloud service, capture snapshots, and compare them with previous snapshots. Each story becomes a candidate test without a separate visual-test file because the story already defines the state to render.
The first run establishes baselines.