GitHub Action

Individua le regressioni di accessibilità prima del merge

Esegui wcagc sugli URL di anteprima delle pull request, pubblica un riepilogo leggibile del job e fai fallire il controllo solo secondo la policy scelta dal tuo team.

Crea una chiave API per la CI

Aggiungi un solo passaggio al workflow

Salva una chiave ci:check come WCAGC_API_KEY, elenca fino a 5 URL con Free o 20 con i piani a pagamento, provenienti da un solo sito verificato, e scegli la soglia che deve bloccare un 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

Inizia con i controlli CI gratuiti

Le organizzazioni Free ricevono 30 controlli CI al mese. Ogni controllo può coprire fino a 5 URL di un dominio verificato. Scrivi il SARIF nel workflow e caricalo in un passaggio GitHub separato quando ti servono risultati persistenti di code scanning.

Vedi la scheda su GitHub Marketplace

permissions:
  contents: read
  security-events: write

steps:
  - uses: WCAG-Compliance/wcagc-ci@v1
    with:
      api-key: ${{ secrets.WCAGC_API_KEY }}
      urls: https://preview.example.com
      sarif-file: results/wcagc.sarif
  - uses: github/codeql-action/upload-sarif@v3
    if: always()
    with:
      sarif_file: results/wcagc.sarif

Scegli la policy adatta al rilascio

L’Action riporta sempre ogni problema rilevato in automatico. L’impostazione fail-on controlla solo l’esito della CI.

new-critical
Fallisce solo quando un problema critico è nuovo rispetto all’ultima baseline riuscita. Senza baseline, ripiega in sicurezza su any-critical.
any-critical
Fallisce quando una qualsiasi pagina controllata contiene almeno un problema critico.
serious-or-worse
Fallisce quando è presente un qualsiasi problema critico o grave.
none
Riporta i problemi rilevati senza far fallire il workflow.

Una baseline è un’evidenza, non una deroga

Il servizio confronta le coppie regola-pagina con l’ultimo controllo CI riuscito per lo stesso sito. I problemi esistenti restano visibili; cambia solo il conteggio dei nuovi. Se manca una baseline, new-critical usa la policy più severa any-critical.

Crea GitHub Issues dai problemi rilevati

Collega un repository, esporta le evidenze tecniche e lascia che wcagc chiuda o riapra la issue man mano che la correzione cambia.

Collega GitHub Issues

Un controllo che gli sviluppatori possono leggere

Esempio di riepilogo dei problemi rilevati dalla CI di wcagc
Gravità	Problemi rilevati	Nuovi
Critical	1	0
Serious	3	1

Il riepilogo del job rimanda al report completo e aggiunge annotazioni limitate, senza inondare la pull request.