Dostępność sprawdzana tylko raz w roku podczas jednorazowego ręcznego przeglądu prawie zawsze szybko ulega erozji — każda niewielka aktualizacja kodu może zepsuć coś, co zostało już naprawione. Rozwiązanie: wbuduj testy dostępności w sam proces programowania (CI/CD) jako zautomatyzowany krok, aby problemy zostały wykryte, zanim trafią do produkcji. W tym artykule wyjaśniono, jak to zrobić.
W skrócie — o czym mowa w tym artykule
Dlaczego jednorazowe sprawdzenie nie wystarczy
Zespół programistów, który dostarcza aktualizacje co tydzień, a czasem codziennie, nie może polegać na corocznym audycie dostępności w celu utrzymania stałej zgodności. Nowy komponent dodany bez zastanowienia się nad dostępnością lub zmiana CSS, która przypadkowo obniża kontrast, może zepsuć już poprawioną dostępność — i nikt tego nie zauważy, dopóki użytkownik lub skarga tego nie ujawni. Ta sama zasada dotyczy również dokumentów — zobacz nasz przewodnik na tematmapowanie typowych błędów.
Co mogą wychwycić zautomatyzowane narzędzia w potoku CI/CD
Narzędzia takie jak axe-core, Pa11y lub Lighthouse CI mogą działać automatycznie przy każdym żądaniu ściągnięcia lub przed każdym wdrożeniem — w ciągu kilku sekund sprawdzają takie rzeczy, jak: kontrast kolorów, nieprawidłowe lub zduplikowane tagi ARIA, brakujący tekst alternatywny, brakujące etykiety formularzy i nieprawidłowa kolejność nagłówków. Jeśli sprawdzenie się nie powiedzie, połączenie żądania ściągnięcia zostanie automatycznie zablokowane — podobnie jak w przypadku zwykłego przeglądu kodu lub nieudanego testu jednostkowego.
💡 Praktyczna wskazówka
Rozpocznij w „trybie ostrzegawczym” (bez blokowania) na kilka tygodni, aby zobaczyć, ile problemów już istnieje w bazie kodu, i dopiero po wstępnym oczyszczeniu zamień kontrolę w blokadę wdrażania — w ten sposób zespół nie „utknie” w obliczu setek błędów pierwszego dnia.
Gdzie nadal potrzebne jest ręczne testowanie
Podobnie jak w przypadku testowania dokumentów, zautomatyzowane narzędzia w potoku CI/CD wychwytują jasne problemy strukturalne, ale nie są w stanie ocenić rzeczywistego doświadczenia użytkownika: czy nawigacja za pomocą klawiatury ma sens, czy czytnik ekranu „opowiada spójną historię” na stronie lub czy niestandardowy komponent (taki jak karuzela lub modal) jest rzeczywiście użyteczny w rzeczywistym świecie. Dlatego warto połączyć bieżące automatyczne kontrole z okresowym audytem ręcznym – na przykład kwartalnym.
Jak to wdrożyć w praktyce
- Wybierz narzędzie testowe, które pasuje do Twojego stosu technologii (rdzeń axe dla większości projektów JavaScript, Lighthouse CI dla projektów opartych na przeglądarce).
- Uruchom go jako krok w potoku CI — zwykle jako akcję GitHub, zadanie CI GitLab lub równoważny krok w dowolnym narzędziu CI/CD, którego używasz.
- Ustaw wyraźny próg awarii (na przykład: brak problemów na poziomie „krytycznym” na rdzeń osi), zanim kontrola stanie się blokerem.
- Zabezpiecz także swoje pliki PDF: jeśli Twoja organizacja generuje dokumenty automatycznie (faktury, raporty), rozważ dodanie również automatycznego skanowania w ramach procesu publikowania.
Chcesz dodać do swojego procesu automatyczne testowanie plików PDF?
Nasze narzędzie skanuje pliki PDF i przyznaje każdemu dokumentowi ocenę dostępności — możesz go uruchomić w ramach okresowej kontroli wraz z procesem CI/CD.
Przeskanuj swoją witrynę za darmo ←Po zeskanowaniu możesz także udostępnić znalezione dokumenty bezpośrednio i bezpłatnie za pośrednictwemAccessiDoc.