Detecting Accessibility Drift in CI: Design System Tests You Should Run

Tech · 5 min read

Accessibility drift happens when new tokens, components, or variants are merged without checking downstream effects. The most effective defense is a layered test strategy in CI: unit-level rendering checks, integration tests for story-driven components, and end-to-end validation on deployed preview environments. Tools like axe-core, pa11y, and Lighthouse are essential but need to be applied sensibly alongside screenshot diffing and semantic contract tests.

Start by adding axe-core scans to Storybook builds and gating merges on no new critical violations. Expand with visual regression tests that run under different accessibility states (high-contrast, large text, reduced-motion) because some regressions are purely visual. For content-driven paths, add a flow that validates alt text presence and confidence metadata in CMS pipelines. Finally, surface results to developers in familiar places: PR checks, Slack alerts, and annotated Storybook pages so remediation is tightly coupled with authoring.

The process is cultural as much as technical: democratize remediation by offering “how-to” recipes in the design system docs, and maintain a prioritized backlog for legacy components. When teams treat accessibility as part of the design system’s test suite, regressions become smaller, easier to fix, and less likely to reach production users who rely on those features.