CI/CD Accessibility Testing

Modern development teams deploy multiple times per day. Each deployment can introduce accessibility regressions — a new component without ARIA attributes, a CSS change that breaks contrast ratios, a form refactor that drops label associations. Without automated accessibility checks in the CI/CD pipeline, these regressions reach production undetected.

CI/CD accessibility testing applies the same "shift-left" principle used for security and performance: catch issues early, when they are cheapest to fix. A contrast failure caught during a pull request review takes 5 minutes to fix. The same failure caught after an ADA demand letter costs $5,000-$25,000 in settlements plus remediation time. With over 10,000 ADA lawsuits annually, prevention is far cheaper than reaction.

The most practical CI/CD accessibility setup uses axe-core integrated into your existing test framework:

• @axe-core/playwright — inject axe-core into Playwright E2E tests; scan rendered pages during your existing test runs
• @axe-core/puppeteer — similar integration for Puppeteer-based test suites
• jest-axe — test React components for accessibility in Jest unit tests
• cypress-axe — add axe-core scanning to Cypress E2E test suites
• pa11y-ci — standalone CLI tool that scans a list of URLs in CI and fails on violations

A typical CI pipeline adds an accessibility stage after unit tests and before deployment:

lint → unit tests → accessibility check → build → deploy → CompliScan monitoring

Configure your pipeline to fail on critical violations (Level A) and warn on moderate violations (Level AA). This prevents the worst accessibility issues from reaching production while allowing teams to address less severe issues in a planned sprint.

CI/CD tests and CompliScan serve different stages of the deployment lifecycle:

• CI/CD (pre-deploy) — fast axe-core checks on rendered components or pages in the test environment; catches regressions before they ship
• CompliScan (post-deploy) — comprehensive scanning on the production URL with AI fix suggestions; catches issues that CI tests miss (real CDN assets, third-party scripts, production-only content)

This layered approach is critical because CI/CD tests run against test environments that may differ from production. Third-party scripts (analytics, chat widgets, cookie banners) are often absent in CI but present in production — and they are a major source of accessibility issues. CompliScan's scheduled monitoring catches these production-only violations.

CompliScan's upcoming API will enable tighter CI/CD integration: trigger a scan as a post-deploy hook and fail the pipeline if the production accessibility score drops below a threshold.

Implement these patterns for effective CI/CD accessibility testing:

• Start with a baseline — run a CompliScan scan to establish your current violation count; set CI thresholds based on reality, not perfection
• Ratchet down violations — configure CI to fail if the violation count increases from the baseline; gradually lower the threshold as you fix issues
• Test critical user flows — focus CI accessibility tests on high-impact pages: homepage, signup/login, core product pages, checkout/conversion flows
• Include component tests — use jest-axe to test UI components in isolation; catch accessibility issues before they are assembled into pages
• Monitor production — CompliScan's Shield plan at $49/month monitors live production URLs weekly; Shield Pro at $149/month runs daily scans for fast feedback

The goal is not zero violations in CI (that is unrealistic initially) but never adding new violations and steadily reducing existing ones. CompliScan's compliance score tracking makes this progress visible to the entire team.