Integracja dostępności z CI/CD

Najtańszy błąd dostępności to taki, który nigdy nie zostaje scalony. Integracja dostępności z CI/CD przesuwa testowanie w lewo, do Twojego potoku rozwoju, aby regresje były wychwytywane automatycznie przy każdym pull requeście, zamiast ujawniać się miesiące później w audycie — lub w skardze.

Dlaczego integrować dostępność z CI/CD

Większość zespołów testuje dostępność po fakcie: okresowy audyt tworzy długą listę, zespół ją naprawia, a potem te same klasy problemów po cichu wracają wraz z kolejnymi funkcjami. Automatyzacja kontroli w potoku przerywa ten cykl. Każda zmiana jest oceniana w chwili jej wprowadzenia, deweloperzy otrzymują informację zwrotną, gdy kod jest świeży, a Twoja ciężko wypracowana zgodność jest chroniona przed cichą regresją.

Jak to działa

Funkcja Code Analysis QualiBooth integruje się z GitHub Actions. Po skonfigurowaniu workflow uruchamia się automatycznie przy każdym push i pull requeście:

1. Zainstaluj QualiBooth GitHub Action i dodaj swój sekret QUALIBOOTH_ORG_UUID.
2. Commituj plik workflow — GitHub od tego momentu automatycznie wyzwala skany dostępności.
3. Wyniki pojawiają się w dashboardzie Scan Runs QualiBooth, przeszukiwalnym według repozytorium, gałęzi lub skrótu commita.
4. Każde naruszenie jest wskazywane do ścieżki pliku i numeru linii z ważnością Error lub Warning.
5. Po wprowadzeniu poprawki kolejny skan oznacza problem jako Naprawiony — postęp jest mierzalny z uruchomienia na uruchomienie.

Skanowanie oparte na ESLint obsługuje obecnie bazy kodu React, Vue, JavaScript i TypeScript. Obsługa dodatkowych frameworków i platform CI jest w planach.

Co konfigurujemy

1. Integracja z GitHub Actions — action QualiBooth wpięta w workflow Twojego repozytorium.
2. Informacja zwrotna w PR — automatyczne kontrole, które komentują wyniki bezpośrednio w pull requestach.
3. Wykrywanie regresji — każde skanowanie jest porównywane z linią bazową, dzięki czemu nowe problemy są wyraźnie oddzielone od istniejących zaległości.
4. Punkty odniesienia — migawka istniejących problemów, abyś blokował na nowych problemach, a nie na całym backlogu naraz.
5. Dashboard Scan Runs — każde wykonanie zarejestrowane z gałęzią, commitem, liczbami problemów i śledzeniem naprawionych problemów.

Gdzie działają kontrole

• Pull requesty — szybkie skany zmienionych plików dla błyskawicznej informacji zwrotnej dla recenzenta
• Wypchnięcia do gałęzi — ciągłe monitorowanie, aby regresje były wychwytywane przed przeglądem PR
• Sprawdzenia przed scaleniem — wykrywanie nowych regresji, zanim dotrą do gałęzi main
• Zaplanowane przeglądy — pełniejsze skany nocne lub przy wydaniu w całej aplikacji

Uczciwa granica

Testowanie automatyczne wiarygodnie wykrywa tylko 30–40% kryteriów sukcesu WCAG. Mówimy o tym wprost: integracja CI/CD to sposób, by nie dopuścić do wdrożenia problemów, które da się zautomatyzować, oraz by chronić się przed regresją — ale nie zastępuje ludzkiego osądu. Nasz przewodnik po automatycznym testowaniu dostępności w CI/CD opisuje, gdzie ta granica leży w praktyce. Pełny obraz powstaje z połączenia automatycznych bramek z audytami ręcznymi prowadzonymi przez osoby z niepełnosprawnościami i audytami cyklicznymi.

Dla kogo

Zespoły inżynierii i platformowe, które wdrażają w sposób ciągły i chcą, by dostępność była standardową, automatyczną bramką jakości — tak jak testy i lintowanie. To naturalny element szerszego programu usprawnienia procesu dostępności.