GitHub Action

Détectez les régressions d’accessibilité avant la fusion

Contrôlez les URL de prévisualisation des pull requests avec wcagc, publiez un résumé lisible et faites échouer la CI uniquement selon la règle choisie.

Créer une clé API pour la CI

Une étape dans le workflow

Enregistrez une clé wcagc limitée comme WCAGC_API_KEY, listez jusqu’à 20 URL d’un même site enregistré et choisissez le seuil de blocage.

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

Choisissez la règle adaptée à la version

L’Action signale toujours tous les constats automatisés. fail-on ne contrôle que le verdict CI.

new-critical
Échouer seulement pour un constat critique nouveau par rapport à la dernière référence réussie. Sans référence, any-critical s’applique par sécurité.
any-critical
Échouer si une page contrôlée contient au moins un constat critique.
serious-or-worse
Échouer en présence d’un constat critique ou sérieux.
none
Signaler les constats sans faire échouer le workflow.

Une référence est une preuve, pas une dérogation

Le service compare les paires règle-page au dernier contrôle CI réussi du même site. Les constats existants restent visibles ; seul le nombre de nouveautés change. Sans référence, new-critical utilise la règle plus stricte any-critical.

Créer des GitHub Issues depuis les constats

Connectez un dépôt, exportez les preuves techniques et laissez wcagc fermer ou rouvrir le ticket selon la remédiation.

Connecter GitHub Issues

Un contrôle lisible par les développeurs

Exemple de résumé des constats CI wcagc
Sévérité	Constats	Nouveaux
Critical	1	0
Serious	3	1

Le résumé du job renvoie au rapport complet et limite les annotations pour ne pas saturer la pull request.