Dostępność w CI/CD: pięć punktów kontroli, zanim kod trafi na produkcję

Level Access opublikował przewodnik po włączaniu testów dostępności do pipeline’u CI/CD. Sedno przekazu: dostępność ma być sprawdzana na każdym etapie wytwarzania, a nie po premierze — bo wtedy koszt naprawy jest nawet 30 razy wyższy (dane NIST).

Artykuł proponuje pięć punktów kontroli:

• IDE, przed commitem — lintery i pluginy łapią błędy, zanim wejdą do repozytorium: ikonowy przycisk bez etykiety, kontrast poniżej progu, ARIA na elemencie, który już ma semantykę. Koszt naprawy: zero.
• Pull request, delta scan — skaner sprawdza tylko zmiany z danego PR i komentuje wprost w code review. Nie zalewa starymi błędami z legacy codebase.
• Quality gate przed mergem — krytyczne naruszenia blokują scalenie, niższe rangi tylko ostrzegają. Autorzy radzą zacząć od trybu ostrzegawczego i zaostrzać stopniowo.
• Build i testy integracyjne — pełny skan renderowanej strony, łącznie ze stanami po interakcji: otwarty modal, zalogowany panel, rozbudowany formularz.
• Pre-deployment na staging — ostatnia siatka bezpieczeństwa: widżety firm trzecich, szablony CMS, konfiguracja, której nie widać we wcześniejszych etapach.

Przewodnik przypomina też, czego automatyzacja nie złapie: czy tekst alternatywny ma sens, czy porządek fokusu jest logiczny, czy widżet działa z czytnikiem ekranu, czy komunikaty błędów są zrozumiałe. Zielony pipeline nie oznacza dostępnej strony — potrzebna jest jeszcze ekspercka ocena i testy z użytkownikami technologii asystujących.

Wątek wart uwagi w kontekście ostatnich wpisów: dedykowane narzędzia, jak Level CI, wspierają MCP — podpowiedzi dostępności trafiają wprost do edytorów z AI, podobnie jak Axe Monitor od Deque. MCP robi się wspólnym standardem dla dostępności w procesie wytwarzania.

Warto przeczytać w całości: Accessibility Testing in CI/CD: What It Is, How It Works, and Why It Matters (Level Access)