Accessibility Testing in GitHub Actions

A11y Pulse plugs into GitHub Actions through the public REST API. After each deploy, a workflow step can trigger a rescan, poll for completion, and either post the results to a pull request comment or fail the job if the accessibility score drops below a threshold. Because the scan runs in A11y Pulse infrastructure rather than inside the runner, you get the full daily-scan engine — real Chrome, hydrated DOM, axe-core — without burning CI minutes on browser startup.

A minimal workflow looks like this:

name: Accessibility scan
on:
  deployment_status:
    types: [success]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger A11y Pulse scan
        env:
          A11Y_PULSE_API_KEY: ${{ secrets.A11Y_PULSE_API_KEY }}
        run: |
          curl -X POST \
            -H "Authorization: Bearer $A11Y_PULSE_API_KEY" \
            -H "Content-Type: application/json" \
            https://api.a11ypulse.com/v1/sites/<site-id>/scans

From there you can poll for the result, parse the issue list, and gate the deploy or notify the team. The same approach works for GitLab CI, CircleCI, Buildkite, and any other runner that can make HTTP requests. If you’d rather not run a scan on every deploy, A11y Pulse already runs a daily scan on its own schedule, so GitHub Actions is most useful as an on-demand “scan now” trigger for high-risk releases.

For full endpoint documentation, including authentication, scan polling, and the issue payload shape, see the A11y Pulse API reference.