Skip to content

CI/CD for Accessibility — Complete Guide

DodaTech Updated 2026-06-28 3 min read

In this tutorial, you will learn about CI/CD for Accessibility. We cover key concepts, practical examples, and best practices to help you master this topic.

CI/CD accessibility integration runs automated scans on every pull request and deployment, using tools like axe-core CLI, Lighthouse CI, and Pa11y with GitHub Actions or Jenkins to fail builds that introduce WCAG violations.

What You'll Learn

You will configure accessibility checks in GitHub Actions, set up Lighthouse CI for score thresholds, run Pa11y in Jenkins, and create a pipeline that catches regressions automatically.

Why It Matters

Manual testing is too slow for frequent deployments. CI/CD integration ensures that every change is automatically checked for accessibility regressions, catching issues minutes after they are introduced rather than weeks later in a manual audit.

Real-World Use

A developer adds a new component library. The PR triggers a GitHub Action that runs axe-core against the Storybook. The action finds 12 violations, posts them as a PR comment, and blocks the merge. The developer fixes the issues before the library reaches production.

CI/CD Pipeline Flow

flowchart TD
  A[Developer Push] --> B[CI Triggered]
  B --> C[Build Application]
  C --> D[axe-core Scan]
  C --> E[Lighthouse CI]
  C --> F[Pa11y Check]
  D --> G{Any Violations?}
  E --> H{Score >= Threshold?}
  F --> I{Errors < Limit?}
  G -->|Yes| J[Fail Build]
  H -->|No| J
  I -->|No| J
  G -->|No| K[Pass Build]
  H -->|Yes| K
  I -->|Yes| K
  K --> L[Deploy]

GitHub Actions Configuration

Create a workflow file that runs accessibility checks on every pull request. Use axe-core CLI for deep scanning and Lighthouse CI for score enforcement.

# .github/workflows/a11y.yml
name: Accessibility Checks
on:
  pull_request:
    branches: [main]

jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - name: Install dependencies
        run: npm ci
      - name: Build application
        run: npm run build
      - name: Run axe-core
        run: npx axe http://localhost:3000 --exit
      - name: Lighthouse CI
        run: |
          npm install -g @lhci/cli
          lhci autorun
// Custom CI script for accessibility thresholds
const { execSync } = require('child_process');

async function checkAccessibility() {
  const result = execSync('npx axe http://localhost:3000 --json');
  const violations = JSON.parse(result.toString()).violations;

  const criticalCount = violations.filter(v => v.impact === 'critical').length;
  if (criticalCount > 0) {
    console.error(`FAIL: ${criticalCount} critical violations found`);
    process.exit(1);
  }

  console.log(`PASS: ${violations.length} total violations (acceptable)`);
}

Common Mistakes

  • Running accessibility checks only on the homepage
  • Not setting baseline scores for new projects
  • Ignoring flaky tests that randomly pass or fail
  • Running checks on production instead of staging
  • Not configuring authentication for protected pages
  • Using overly permissive thresholds that pass real issues
  • Notifying the wrong team members about failures

Practice and Challenge

Practice 1: Create a GitHub Action that runs axe-core on a staging URL. Practice 2: Configure Lighthouse CI with a minimum score of 90. Practice 3: Set up Pa11y to run daily against a production URL. Practice 4: Add a Slack notification for accessibility failures. Practice 5: Create a script that fails the build only on critical violations.

Challenge: Design a complete CI/CD accessibility pipeline for a Monorepo with three micro-frontends. Each micro-frontend should have its own accessibility checks, and there should be a consolidated dashboard showing the overall accessibility health across all services.

FAQ

Which CI tools work best for accessibility?

GitHub Actions with axe-core CLI is the most common setup. Lighthouse CI adds score tracking. Pa11y works well in any CI.

How long do accessibility checks add to build time?

Scans typically add 30-90 seconds per URL. Parallelizing scans across multiple URLs keeps total time manageable.

Should I block builds on all violations?

Block on critical and serious violations. Allow moderate and minor to pass but log them for tracking.

How do I handle dynamic content in CI?

Use wait commands in Pa11y or increase timeout in axe-core CLI to allow JavaScript-rendered content to load.

Can I test authenticated pages in CI?

Yes. Use environment variables for credentials and configure the tool to log in before scanning.

What is Lighthouse CI autorun?

The autorun command starts a local server, runs Lighthouse against it, and asserts scores against a configured budget.

Mini Project

Set up a complete CI/CD accessibility pipeline in a sample project. Include a GitHub Action that runs on pull requests, performs axe-core and Lighthouse CI checks, posts results as a PR comment, and blocks merges if critical violations are found.

What's Next

Accessibility Dashboard covers building dashboards for tracking accessibility metrics over time.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro