Barrierefreiheitsregressionen vor dem Merge erkennen
Prüfen Sie Pull-Request-Preview-URLs mit wcagc, veröffentlichen Sie eine lesbare Zusammenfassung und lassen Sie CI nur nach der gewählten Richtlinie fehlschlagen.
CI-API-Schlüssel erstellenEin Schritt im Workflow
Speichern Sie einen berechtigten wcagc-Schlüssel als WCAGC_API_KEY, listen Sie bis zu 20 URLs einer registrierten Website auf und wählen Sie die Blockierschwelle.
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-criticalPassende Richtlinie für den Release wählen
Die Action meldet immer alle automatisierten Befunde. fail-on steuert nur das CI-Ergebnis.
new-criticalNur bei einem neuen kritischen Befund gegenüber der letzten erfolgreichen Baseline fehlschlagen. Ohne Baseline gilt sicherheitshalber any-critical.
any-criticalFehlschlagen, sobald eine geprüfte Seite einen kritischen Befund enthält.
serious-or-worseBei jedem kritischen oder schwerwiegenden Befund fehlschlagen.
noneBefunde melden, ohne den Workflow fehlschlagen zu lassen.
Eine Baseline ist ein Nachweis, kein Freibrief
Der Dienst vergleicht Regel-und-Seiten-Paare mit der letzten erfolgreichen CI-Prüfung derselben Website. Bestehende Befunde bleiben sichtbar; nur die Anzahl neuer Befunde ändert sich. Fehlt die Baseline, nutzt new-critical die strengere Richtlinie any-critical.
GitHub Issues aus Befunden erstellen
Verbinden Sie ein Repository, exportieren Sie technische Nachweise und lassen Sie wcagc das Issue schließen oder wieder öffnen.
GitHub Issues verbindenEine verständliche Prüfung für Entwickler
| Schweregrad | Befunde | Neu |
|---|---|---|
| Critical | 1 | 0 |
| Serious | 3 | 1 |
Die Job-Zusammenfassung verlinkt den vollständigen Bericht und begrenzt Annotationen, damit der Pull Request übersichtlich bleibt.