Integrazione CI/CD dell'accessibilità

Il bug di accessibilità più economico è quello che non viene mai integrato. L’integrazione CI/CD dell’accessibilità sposta i test verso le prime fasi della tua pipeline di sviluppo, così le regressioni vengono individuate automaticamente a ogni pull request anziché emergere mesi dopo in un audit — o in un reclamo.

Perché integrare l’accessibilità nel CI/CD

La maggior parte dei team testa l’accessibilità a posteriori: un audit periodico produce un lungo elenco, il team lo corregge, e poi le stesse classi di problemi si insinuano di nuovo silenziosamente con le funzionalità successive. Automatizzare i controlli nella pipeline interrompe questo ciclo. Ogni modifica viene valutata mentre viene fatta, gli sviluppatori ricevono feedback mentre il codice è fresco e la conformità faticosamente conquistata è protetta dalle regressioni silenziose.

Come funziona

La funzionalità Code Analysis di QualiBooth si integra con GitHub Actions. Una volta configurato, il workflow viene eseguito automaticamente a ogni push e pull request:

1. Installa la GitHub Action di QualiBooth e aggiungi il secret QUALIBOOTH_ORG_UUID.
2. Committa il file di workflow — GitHub attiva automaticamente le scansioni di accessibilità da quel momento in poi.
3. I risultati appaiono nel dashboard Scan Runs di QualiBooth, ricercabile per repository, branch o hash di commit.
4. Ogni violazione viene localizzata a un percorso di file e un numero di riga con severità Error o Warning.
5. Quando una correzione viene integrata, la scansione successiva contrassegna il problema come risolto — i progressi sono misurabili scansione per scansione.

La scansione basata su ESLint supporta attualmente codebase React, Vue, JavaScript e TypeScript. Il supporto per framework aggiuntivi e piattaforme CI è in programma.

Cosa configuriamo

1. Integrazione GitHub Action — l’action di QualiBooth collegata al workflow del tuo repository.
2. Feedback sulle PR — controlli automatici che commentano i rilievi direttamente sulle pull request.
3. Rilevamento delle regressioni — ogni scansione viene confrontata con una baseline, così i nuovi problemi sono chiaramente separati dal backlog preesistente.
4. Baseline — un’istantanea dei problemi esistenti così applichi il gate sui nuovi problemi, non sull’intero backlog tutto in una volta.
5. Dashboard Scan Runs — ogni esecuzione registrata con branch, commit, conteggio dei problemi e tracciamento dei problemi risolti.

Dove vengono eseguiti i controlli

• Pull request — scansioni veloci dei file modificati per un rapido feedback ai revisori
• Push di branch — monitoraggio continuo così le regressioni vengono individuate prima della revisione della PR
• Controlli pre-merge — rilevare le nuove regressioni prima che raggiungano il branch principale
• Scansioni pianificate — scansioni notturne o di rilascio più complete sull’intera applicazione

Un confine onesto

I test automatici individuano in modo affidabile solo il 30–40% dei criteri di successo WCAG. Su questo siamo espliciti: l’integrazione CI/CD è il modo per evitare che i problemi automatizzabili vadano in produzione e per proteggerti dalle regressioni — ma non sostituisce il giudizio umano. La nostra guida ai test di accessibilità automatici nel CI/CD illustra dove si colloca questo confine nella pratica. Il quadro completo nasce dalla combinazione dei gate automatici con gli audit manuali svolti da persone con disabilità e gli audit ricorrenti.

A chi si rivolge

Team di ingegneria e di piattaforma che rilasciano in continuazione e vogliono che l’accessibilità sia un gate di qualità standard e automatico — proprio come i test e il linting. È una componente naturale di un più ampio programma di miglioramento dei processi di accessibilità.