CI/CD Integration

Continuous Accessibility plugs The Accessible Org audit engine straight into your CI pipeline. When a developer opens a pull request, we crawl the changed pages against WCAG 2.1 AA, post a summary comment, and gate the merge based on the severity thresholds you set. The marketing landing page lives at cicd.theaccessible.org.

No new dashboards. No separate accounts. The check passes or it fails — just like your linter, just like your tests.

What you get on every PR

• Pull request audits. Every PR runs a full WCAG 2.1 AA scan of the changed pages.
• Blocking failures. Configure severity thresholds. New critical violations fail the check and block the merge.
• Existing-debt separation. Legacy issues are tracked separately so they do not stall delivery while you work them down.
• Trend tracking. Every build is scored against your ACR baseline; watch your conformance level rise (or fall) over time.

Supported platforms

• GitHub Actions (officially supported action)
• GitLab CI (CLI runner)
• CircleCI (CLI runner)
• Jenkins (CLI runner)
• Any CI system that can run a shell command

Prerequisites

• An Accessible Org API key. Generate one at pdf.theaccessible.org/settings → API Keys → Create Key.
• A staging or preview URL your CI can reach. The action audits a live URL, so your pipeline needs to deploy the change somewhere reachable before the audit step runs.

GitHub Actions setup

Drop the workflow below into .github/workflows/accessibility.yml in your repository.

# .github/workflows/accessibility.yml
name: Accessibility Audit
on: [pull_request]

jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: theaccessible-org/audit-action@v1
with:
api-key: ${{ secrets.ACCESSIBLE_API_KEY }}
target: https://staging.example.com
fail-on: critical

Then:

1. Open your repository's Settings → Secrets and variables → Actions.
2. Add a new repository secret named ACCESSIBLE_API_KEY. Paste the API key from your account page.
3. Commit the workflow file.
4. Open your next pull request. The audit runs automatically and posts a summary comment.

Workflow inputs

Input	Required	Default	Description
api-key	yes	—	Your Accessible Org API key (use a GitHub secret).
target	yes	—	The URL to audit. Often a per-PR preview URL produced by your deploy step.
fail-on	no	critical	Severity threshold. One of critical, serious, moderate, minor, any.
wcag-level	no	AA	WCAG conformance level: A, AA, or AAA.
comment	no	true	Whether to post a results comment back to the pull request.

Reading the results

The action posts a markdown comment that shows:

• The conformance score (e.g. 94 / 100 — WCAG 2.1 AA).
• A table of new violations introduced by this PR, with severity, WCAG criterion, and a one-line fix hint.
• A separate table of pre-existing violations (informational only).
• A link to the full audit report.

The check turns red if any violation at or above your fail-on threshold is in the new column. Pre-existing violations never fail the check.

GitLab / CircleCI / Jenkins

Use the CLI directly. It works the same way the GitHub Action does internally.

# GitLab CI example
accessibility-audit:
image: node:20
script:
- npx @theaccessible-org/audit-cli@latest \
--target https://staging.example.com \
--fail-on critical
variables:
ACCESSIBLE_API_KEY: $ACCESSIBLE_API_KEY

The CLI exits non-zero on failure, posts a comment via your provider's PR API if a token is available, and prints a summary table to stdout.

How the audit decides what to scan

The action scans the target URL you give it. If you want to scan multiple pages, pass a comma-separated list:

target: https://staging.example.com,https://staging.example.com/pricing,https://staging.example.com/contact

For full-site audits triggered by a single commit (typically nightly, not per-PR), use the audit dashboard directly — it crawls and produces a longer-running report.

Setting the right fail-on threshold

We recommend starting with fail-on: critical for new repositories. That blocks merges that introduce ADA-litigation-grade issues without stalling delivery on minor stylistic problems.

After a few weeks, tighten to fail-on: serious once your team is comfortable. Save fail-on: any for repositories where accessibility is the whole point.

Troubleshooting

The check is green but I expected it to be red.

The action only fails on new violations introduced by the PR. Pre-existing violations on the page are reported but do not fail the check. Use the audit dashboard to work down the legacy backlog.

The action times out.

Default timeout is 5 minutes. For larger pages or full crawls, raise it with timeout: 10m. If you are auditing a preview URL that is slow to come online, add a wait-for-url step before the audit.

The PR comment is missing.

Make sure the action has pull-requests: write permission. In GitHub Actions:

permissions:
contents: read
pull-requests: write

Where to go from here

• The API reference documents the underlying scan and conformance endpoints — useful if you want to wire the audit into a custom pipeline.
• The MCP server guide describes the same toolset exposed to AI agents instead of CI runners.
• For interactive auditing while developing, point your local agent at the MCP server and ask it to scan your dev URL before you push.