GitHub Action

Catch accessibility regressions before you merge

Run wcagc against pull-request preview URLs, publish a readable job summary, and fail the check only under the policy your team chooses.

Create a CI API key

Add one workflow step

Save a scoped wcagc key as WCAGC_API_KEY, list up to 20 URLs from one registered site, and choose the threshold that should block a merge.

name: Accessibility check
on: [pull_request]

jobs:
  wcagc:
    runs-on: ubuntu-latest
    steps:
      - uses: WCAG-Compliance/wcagc-ci@v1
        with:
          api-key: ${{ secrets.WCAGC_API_KEY }}
          urls: |
            https://preview.example.com/
            https://preview.example.com/checkout
          fail-on: new-critical

Choose the policy that fits the release

The Action always reports every automated finding. The fail-on setting controls only the CI verdict.

new-critical
Fail only when a critical finding is new compared with the latest successful baseline. With no baseline, it safely falls back to any-critical.
any-critical
Fail when any checked page contains at least one critical finding.
serious-or-worse
Fail when any critical or serious finding is present.
none
Report findings without failing the workflow.

A baseline is evidence, not a waiver

The service compares rule-and-page pairs with the latest successful CI check for the same site. Existing findings remain visible; only the new count changes. If a baseline is missing, new-critical uses the stricter any-critical policy.

Create GitHub Issues from findings

Connect one repository, export technical evidence, and let wcagc close or reopen the issue as remediation changes.

Connect GitHub Issues

A check developers can read

Example wcagc CI finding summary
Severity	Findings	New
Critical	1	0
Serious	3	1

The job summary links to the full report and adds bounded annotations without flooding the pull request.