Audyt dostępności

Audyt odpowiada na jedno pytanie: czy strona lub aplikacja spełnia wskazany standard dostępności, a jeśli nie, to gdzie. Standardem jest prawie zawsze WCAG w wersji i na poziomie ustalonych z góry, np. WCAG 2.1 AA dla polskiego podmiotu publicznego albo WCAG 2.2 AA dla nowego produktu. Bez tego wyniku nie da się z niczym porównać.

W3C opisuje metodę dla stron internetowych w WCAG-EM (Website Accessibility Conformance Evaluation Methodology). Ma ona pięć kroków: określenie zakresu oceny, poznanie strony, wybór reprezentatywnej próby stron, audyt próby i raport z wynikami. Próba ma znaczenie, bo niewiele audytów może sprawdzić każdy ekran. Obejmuje najczęściej używane strony, każdy typ strony lub szablonu, każdy pełny proces, np. rejestrację albo zakup, oraz strony z formularzami, multimediami i dokumentami. WCAG-EM dodaje do tego kilka losowo wybranych stron, żeby sprawdzić, czy próba czegoś nie pominęła. Ta sama logika dotyczy aplikacji mobilnych, tylko zamiast stron są ekrany i ścieżki.

Każdą stronę lub ekran z próby sprawdza się pod kątem każdego kryterium sukcesu na uzgodnionym poziomie. Najpierw działają narzędzia automatyczne: szybko wyłapują brakujące teksty alternatywne, puste etykiety, niski kontrast i część błędów w kodzie. Większa część pracy jest ręczna. Tester przechodzi przez interfejs tylko klawiaturą, czytnikiem ekranu na każdej platformie z zakresu, z tekstem powiększonym do 200% i z ekranem w obu orientacjach. Wiele kryteriów, np. sensowną kolejność fokusu, poprawne nazwy kontrolek i komunikaty o błędach, które mówią, jak naprawić problem, może ocenić tylko człowiek.

Audyt na końcu projektu to najdroższy sposób, żeby dowiedzieć się czegoś o dostępności. Wymagania dla zamawianej aplikacji:

• Zapisz w umowie standard, wersję i poziom oraz zakres: aplikację webową, aplikacje mobilne, generowane dokumenty, a także panel administracyjny, jeśli korzystają z niego pracownicy.
• Zaplanuj co najmniej dwa audyty: jeden na pierwszych pełnych ścieżkach, gdy komponenty można jeszcze tanio zmienić, i jeden przed odbiorem.
• Wymagaj ustaleń przypisanych do kryteriów sukcesu i konkretnych ekranów. Procent ze skanera nie jest wynikiem audytu.
• Upewnij się, że testy ręczne obejmują każdą platformę z zakresu. Aplikacje webowe i mobilne zawodzą w różny sposób.
• Traktuj ustalenia z audytu jak zadania z właścicielem i terminem retestu. Ustalenie jest zamknięte dopiero po ponownym teście, a nie po commicie.
• Zachowaj raport końcowy. Polski podmiot publiczny publikuje deklarację dostępności dla swojej strony i aplikacji mobilnej, a audyt jest dowodem, na którym się opiera.

W projekcie Centrum Komunikacji (aplikacja dla osób głuchych, słabosłyszących, niewidomych i głuchoniewidomych) lista wymagań z lipca 2025 r. zawierała audyt WCAG, a docelowym standardem był WCAG 2.1 AA. Od listopada 2025 r. nasz QA prowadził w trakcie budowy rundy testów z czytnikiem ekranu. W marcu i kwietniu 2026 r. przepracowaliśmy w warstwie frontendowej dwie listy uwag dotyczących WCAG, a nasz zespół przygotował raport WCAG w ramach oddania etapu 2, zakończonego 27 kwietnia 2026 r. Zadanie audytu z listy wymagań zamknięto w czerwcu 2026 r., a późniejsze uwagi od użytkowników wersji produkcyjnej przechodzą ten sam cykl poprawki i retestu.

W projekcie dla PSONI specyfikacja Generatora ETR wymaga WCAG 2.2 na poziomie AAA dla aplikacji, która zamienia dokumenty w tekst łatwy do czytania. Lista wymagań wiąże każdą pozycję z kryterium sukcesu, tak jak raport z audytu. Ustalenia z rund testów z czytnikiem ekranu są prowadzone osobno dla każdej platformy i testowane ponownie oddzielnie na iOS i Androidzie.