Scan in your CI workflow

Overview

adaguard-io/accessibility-action@v1 scans a URL against WCAG 2.2, ADA, Section 508 and EAA, then exposes the score and issue counts as step outputs. It is a step in a workflow you control, so it runs wherever you put it — after a deploy, on a schedule, on a tag, or on a pull request.

Quick Start

Add this as .github/workflows/accessibility.yml. The only required inputs are api-key and url.

name: Accessibility
on: [pull_request]

jobs:
  a11y:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write     # only needed for comment-on-pr
    steps:
      - uses: adaguard-io/accessibility-action@v1
        with:
          api-key: ${{ secrets.ADAGUARD_API_KEY }}
          url: https://staging.example.com
          min-score: 80

The URL must be publicly reachable — the scanner runs on our infrastructure, not on your runner, so localhost and private addresses are rejected. Scan a deployed preview or staging URL.

Getting an API Key

1. Create a key at Settings → API Keys. It is shown once.
2. In your repository, go to Settings → Secrets and variables → Actions and add it as a secret named ADAGUARD_API_KEY.
3. Reference it as ${{ secrets.ADAGUARD_API_KEY }} — never inline the key.

Each run spends one scan from your monthly quota, unless idempotency-key matches a scan from the last 24 hours.

Scanning Behind a Login

Capture a session once at Settings → Authenticated Targets, copy its target key, and pass it as auth-target. Use latest for your most recent session.

- uses: adaguard-io/accessibility-action@v1
  with:
    api-key: ${{ secrets.ADAGUARD_API_KEY }}
    url: https://app.example.com/dashboard
    auth-target: ${{ vars.ADAGUARD_AUTH_TARGET }}   # or "latest"
    scan-mode: crawl
    max-pages: 25

Crawling Many Pages

scan-mode is single by default, which ignores max-pages. To scan more than one page you must change both.

- uses: adaguard-io/accessibility-action@v1
  with:
    api-key: ${{ secrets.ADAGUARD_API_KEY }}
    url: https://example.com
    scan-mode: sitemap      # read sitemap.xml, then crawl
    max-pages: 100
    max-wait-minutes: 45    # a 100-page crawl takes 15-20 minutes

Budget roughly 10 seconds per page unauthenticated and 13 seconds per page authenticated, so 100 pages takes 15–20 minutes. Raise max-wait-minutes past the default 30 for large crawls, or the job gives up before the scan finishes.

Gating the Build

The step exits non-zero when the score is below min-score. Two things worth knowing before you pick a number:

• Start from your current score, not from 100. Run once with min-score: 0, then set the threshold at or just below what you actually score. A gate that has never passed gets ignored.
• A scanner error is not an accessibility regression. fail-on-scan-error is false by default so infrastructure trouble does not block your merge. Set it true if you would rather know.

Inputs

Outputs

Give the step an id, then read ${{ steps.<id>.outputs.<name> }}.

Deciding for yourself

- uses: adaguard-io/accessibility-action@v1
  id: a11y
  with:
    api-key: ${{ secrets.ADAGUARD_API_KEY }}
    url: https://example.com
    min-score: 0            # never fail on score; decide below

- name: Block only on critical issues
  if: steps.a11y.outputs.critical != '0'
  run: |
    echo "::error::${{ steps.a11y.outputs.critical }} critical issue(s)"
    echo "Report: ${{ steps.a11y.outputs.dashboard-url }}"
    exit 1

Action vs GitHub App

Both scan and report into GitHub. They differ in who decides when a scan runs.

They are not exclusive — the App for a zero-config signal on every PR, the Action for a gate you control. See the GitHub App docs.

Troubleshooting