Skip to content

Audit Ci Cd

DodaTech 3 min read

title: "Audit CI/CD Integration" weight: 22 description: "Learn how to integrate accessibility audit checks into CI/CD pipelines, schedule periodic full audits, automate regression detection, and maintain compliance between manual audit cycles." date: 2026-06-28 lastmod: 2026-06-28 tags: [accessibility, auditing]


Audit CI/CD integration embeds accessibility checks into the development pipeline using axe-core CLI and Lighthouse CI for continuous monitoring between full manual audits, automatically detecting regressions and enforcing accessibility budgets on every deployment.

## What You'll Learn

You will set up automated audit checks in CI/CD, configure accessibility budgets, schedule periodic deep audits, and create a feedback loop between automated and manual auditing.

## Why It Matters

Manual audits provide depth but happen infrequently. Between audits, code changes can introduce regressions. CI/CD integration catches these regressions immediately, reducing the number of findings in the next full audit.

## Real-World Use

A team runs axe-core on every pull request and Lighthouse CI on every merge to main. Between quarterly audits, automated checks catch 92 percent of regressions within hours. The quarterly audit finds only 5 new issues instead of 50.

## CI/CD Audit Flow

```mermaid
flowchart TD
  A[Continuous Checks] --> B[Per PR: axe-core]
  A --> C[Per Merge: Lighthouse CI]
  A --> D[Daily: Pa11y Dashboard]
  A --> E[Quarterly: Full Manual Audit]
  B --> F[Block on Critical]
  C --> G[Score Threshold]
  D --> H[Trend Monitoring]
  E --> I[Deep Analysis]
  F --> J[Remediation Backlog]
  G --> J
  H --> J
  I --> J

Configuring CI/CD Audits

Set up different check types at different pipeline stages.

# GitHub Actions for continuous auditing
name: Accessibility Audit
on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 6 * * *' # Daily comprehensive scan

jobs:
  pr-check:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - run: npx axe ${{ secrets.STAGING_URL }} --exit
        continue-on-error: true

  daily-scan:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    steps:
      - run: npx axe https://example.com --save daily-report.json
      - run: node compare-with-baseline.js
// Audit threshold configuration
const auditThresholds = {
  lighthouse: {
    accessibility: 90,
    'best-practices': 85
  },
  axe: {
    maxCritical: 0,
    maxSerious: 3,
    maxModerate: 10
  }
};

// Compare against baseline
function checkRegression(current, baseline) {
  const criticalChange = current.critical - baseline.critical;
  if (criticalChange > 0) {
    console.error(`REGRESSION: ${criticalChange} new critical issues`);
    process.exit(1);
  }
}

Common Mistakes

  • Setting thresholds too low (passing everything)
  • Setting thresholds too high (blocking everything)
  • Not having a baseline to compare against
  • Ignoring scheduled scans in favor of only PR checks
  • Not notifying the right team about failures
  • Running checks on production instead of staging
  • Not updating thresholds as the site improves

Practice and Challenge

Practice 1: Create a GitHub Action for axe-core CI checks. Practice 2: Configure Lighthouse CI with a score budget. Practice 3: Set up a daily Pa11y scan with Slack notification. Practice 4: Create a baseline comparison script for regression detection. Practice 5: Design an alert escalation path for critical violations.

Challenge: Design a complete CI/CD audit strategy for a microservices architecture with 5 services. Each service should have its own accessibility checks in CI, and there should be a consolidated dashboard showing the audit status of all services. Include PR checks, daily scans, weekly trend reports, and quarterly full audit scheduling.

FAQ

Should CI checks replace manual audits?

No. CI checks catch regressions but cannot replace the depth of manual auditing. Use both.

What thresholds should I set?

Start with 0 critical violations, max 5 serious, and a Lighthouse minimum of 85. Tighten as the site improves.

How do I handle false positives in CI?

Configure rule exclusions for known false positives. Track them separately from real violations.

Should I check accessibility in staging or production?

Staging is better for blocking deployments. Production checks catch issues that slip through.

How do I handle dynamic content in CI?

Use wait commands and increase timeouts. For SPAs, ensure the JavaScript-rendered content is fully loaded before scanning.

What metrics should I track over time?

Lighthouse score, violation count by severity, pages scanned, pass/fail rate, and time to fix.

Mini Project

Build a complete CI/CD audit configuration for a sample project. Include: GitHub Actions workflow for PR checks, Lighthouse CI configuration with score budgets, daily Pa11y scan script, baseline comparison tool, Slack notification integration, and a monthly trend report generator.

What's Next

Audit Roles and Responsibilities covers the team structure for accessibility auditing.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro