Audyt dostępności można zacząć bez budżetu i bez specjalisty
Pełny audyt zgodności ze standardem WCAG to zadanie dla osoby, która robi to zawodowo. Nie znaczy to jednak, że zespół nie może sam sprawdzić stanu wyjściowego. Kilka prostych testów wykonywanych na własnym serwisie wychwytuje większość problemów powtarzalnych, czyli tych, które wynikają z szablonu i będą się mnożyć na każdej nowej podstronie.
Sensowna kolejność jest taka: najpierw rzeczy strukturalne w szablonie, potem treść, na końcu multimedia. Odwrotna kolejność prowadzi do poprawiania pojedynczych stron przy zachowaniu błędu w komponencie, który generuje je wszystkie.
Pięć testów, które wykonasz w kwadrans
- Nawigacja klawiaturą. Odłóż mysz i przejdź przez stronę wyłącznie tabulatorem. Sprawdź, czy widać, który element jest aktywny, czy da się otworzyć i zamknąć menu oraz czy okna modalne nie zatrzymują fokusu na stałe.
- Powiększenie tekstu. Zwiększ rozmiar strony w przeglądarce i sprawdź, czy treść się nie nachodzi i czy nic nie znika poza ekran.
- Struktura nagłówków. Przejrzyj kolejność nagłówków na podstronie. Powinna tworzyć logiczną hierarchię, bez przeskoków wynikających z doboru nagłówka pod wygląd, a nie pod znaczenie.
- Teksty alternatywne. Wyłącz ładowanie obrazów i zobacz, czy strona nadal przekazuje komplet informacji. Obrazy czysto dekoracyjne powinny mieć pusty atrybut alt, a nie opis nazwy pliku.
- Kontrast. Zweryfikuj kolory tekstu i tła. Standard wymaga na poziomie AA kontrastu co najmniej 4,5 do 1 dla zwykłego tekstu i 3 do 1 dla tekstu powiększonego.
Do tego dochodzi rzecz banalna, a często pomijana: poprawnie ustawiony atrybut języka strony. Bez niego czytniki ekranu potrafią odczytywać polską treść z angielską wymową, co czyni ją niezrozumiałą.
Formularze, czyli miejsce największych strat
Jeśli serwis ma cokolwiek załatwiać, wąskim gardłem prawie zawsze jest formularz. Warto sprawdzić trzy rzeczy. Czy każde pole ma trwale powiązaną etykietę, a nie tylko podpowiedź znikającą po kliknięciu. Czy komunikat o błędzie mówi, co konkretnie poprawić, zamiast ogólnego stwierdzenia o nieprawidłowych danych. Czy po nieudanej próbie wysyłki fokus przenosi się do miejsca błędu, a nie na początek strony.
Osobny temat to limity czasu. Sesje wygasające po krótkim okresie bezczynności bywają nieprzejściowe dla użytkowników, którzy potrzebują więcej czasu na wypełnienie pól albo korzystają z pomocy technologii wspomagających. Jeśli limit jest konieczny, powinien dać się przedłużyć.
Automatyczne walidatory: co wykryją, a czego nie
Narzędzia automatyczne dobrze radzą sobie z rzeczami mierzalnymi: brakującymi atrybutami, niewystarczającym kontrastem, pustymi etykietami, błędami w kodzie. To zwykle spory kawałek listy i warto z nich korzystać na starcie.
Nie ocenią natomiast sensu. Walidator nie powie, czy tekst alternatywny faktycznie opisuje treść zdjęcia, czy nagłówek odpowiada zawartości sekcji, czy komunikat o błędzie jest zrozumiały ani czy kolejność elementów w nawigacji klawiaturą jest logiczna. Te rzeczy sprawdza się ręcznie, a najlepiej z udziałem użytkowników.
Warto też zachować ostrożność wobec wtyczek obiecujących automatyczne uzupełnienie dostępności całego serwisu jednym skryptem. Nakładka zmieniająca kontrast czy rozmiar czcionki bywa użyteczna jako dodatek, ale nie naprawia błędnej struktury dokumentu ani niedostępnego formularza. Poprawki trzeba wprowadzać w samym serwisie.
Multimedia na koniec, bo tu leżą największe zaległości
Kiedy warstwa techniczna jest już uporządkowana, zostaje zwykle najbardziej zaniedbany obszar, czyli materiały wideo i audio. Tu nie da się nic naprawić skryptem, bo brakujących napisów ani tłumaczenia nie wygeneruje żaden komponent frontendowy. Potrzebna jest inwentaryzacja materiałów, decyzja o priorytetach i osobny etap produkcyjny.
To także moment, w którym warto oddzielić zgodność formalną od realnej użyteczności serwisu dla odbiorcy. Zanim zespół zamknie listę zadań, dobrze jest sprawdzić, jak w praktyce wygląda dostępność materiałów wideo dla osób głuchych, bo sama zgodność ze standardem na wymaganym poziomie nie oznacza jeszcze, że użytkownik załatwi sprawę.
Co zrobić z wynikami
Lista błędów bez przypisania odpowiedzialności zwykle nie przekłada się na zmiany. Praktyczne podejście polega na rozdzieleniu wyników na trzy kubełki: poprawki w szablonie, poprawki w treściach redakcyjnych i zadania produkcyjne przy multimediach. Pierwsza grupa jest jednorazowa i daje efekt na całym serwisie, druga wymaga wpisania zasad do procesu redakcyjnego, trzecia planowania budżetu.
Największy błąd to potraktowanie audytu jako projektu zamkniętego. Serwis żyje, treści przybywa, a bez utrwalonych zasad publikowania stan wraca do punktu wyjścia w ciągu kilku miesięcy.
