Audyt dostępności strony - jak sprawdzić ją samodzielnie w 30 minut

Zamówienie audytu dostępności ma sens wtedy, gdy potrzebujesz dokumentu: przed kontrolą, do przetargu, do rozmowy z klientem korporacyjnym. Znacznie częściej pytanie brzmi inaczej: czy w ogóle mam problem i jak duży. Na to pytanie odpowiesz sobie sam, w pół godziny, mając przeglądarkę i klawiaturę.

Poniżej opisuję dokładnie tę procedurę, którą przechodzę przed oddaniem projektu. Kolejność nie jest przypadkowa: zaczynamy od tego, co szybkie i automatyczne, a kończymy na testach, które wyłapują rzeczy niewidoczne dla maszyn.

Krok 1. Skan automatyczny, żeby zebrać oczywiste błędy

Otwórz stronę w Chrome, wejdź w narzędzia deweloperskie klawiszem F12 i przejdź do zakładki Lighthouse. Zaznacz kategorię Accessibility i uruchom analizę. Zajmie kilkanaście sekund.

Alternatywnie zainstaluj rozszerzenie axe DevTools albo WAVE. Są wygodniejsze przy poprawianiu, bo zamiast jednego wyniku procentowego pokazują listę konkretnych elementów i prowadzą do miejsca w kodzie.

Najważniejsze, żeby dobrze odczytać ten wynik. Narzędzia automatyczne wykrywają około jednej trzeciej problemów. Wykryją brak atrybutu alt, ale nie ocenią, czy jego treść ma sens. Wykryją zbyt niski kontrast, ale nie zauważą, że kolejność tabulacji skacze po stronie chaotycznie. Wynik 100 nie oznacza „strona dostępna”, tylko „nie znaleziono błędów tego typu, których szukam”. Traktuj to jako filtr wstępny, nie jako certyfikat.

Krok 2. Przejście całej strony klawiaturą

To najskuteczniejszy pojedynczy test w całym zestawie i zajmuje dwie minuty. Odłóż mysz. Naciskaj Tab i przechodź przez stronę od góry do dołu.

Zwróć uwagę na cztery rzeczy. Czy widzisz, gdzie aktualnie jesteś, na każdym kroku bez wyjątku. Czy kolejność jest logiczna, czyli zgodna z tym, co widać na ekranie, a nie skacząca z nagłówka do stopki i z powrotem. Czy da się rozwinąć menu, otworzyć zakładki i zamknąć okno modalne klawiszem Escape. I czy nie ma pułapki, czyli miejsca, z którego Tab już nie wyprowadza.

Jeśli fokus w ogóle nie jest widoczny, przyczyną jest prawie zawsze outline: none w arkuszu stylów, dodane po to, żeby „nie brzydziło”. To jeden z najczęstszych i najłatwiejszych do naprawienia błędów: wystarczy zdefiniować własny, wyraźny styl fokusu zamiast go usuwać.

Krok 3. Powiększenie do 200 procent

Naciśnij Ctrl i plus, na macOS Command i plus, aż przeglądarka pokaże 200 procent. WCAG wymaga, żeby przy tym powiększeniu treść pozostała czytelna i funkcjonalna.

Szukasz trzech objawów: tekstu uciętego albo nachodzącego na siebie, poziomego paska przewijania, który się pojawia, oraz elementów sterujących, które wypadły poza ekran. Strony zbudowane na sztywnych wysokościach kontenerów sypią się tu natychmiast, a strony budowane elastycznie przechodzą ten test bez żadnej dodatkowej pracy.

Krok 4. Kontrast

Najedź kursorem na tekst, kliknij prawym przyciskiem i wybierz Zbadaj. W panelu stylów przy wartości koloru Chrome pokazuje współczynnik kontrastu wraz z informacją, czy spełnia poziom AA.

Progi są dwa. 4,5:1 dla zwykłego tekstu i 3:1 dla dużego, czyli od 24 pikseli albo 19 pikseli pogrubionych. Ta sama granica 3:1 obowiązuje elementy interfejsu: obramowania pól formularza, ikony niosące znaczenie, granice przycisków.

W praktyce sprawdź trzy miejsca, w których najczęściej jest za jasno: tekst pomocniczy pod nagłówkami, etykiety i placeholdery w formularzu oraz stopkę. To tam trafia szarość dobrana „na oko”.

Krok 5. Nagłówki i opisy alternatywne

W konsoli przeglądarki wklej document.querySelectorAll('h1,h2,h3,h4') i rozwiń wynik albo po prostu użyj rozszerzenia pokazującego strukturę nagłówków. Sprawdzasz dwie rzeczy: czy jest dokładnie jeden H1 i czy poziomy nie przeskakują, czyli po H2 nie pojawia się od razu H4.

Przy obrazach interesuje Cię nie to, czy atrybut alt istnieje, tylko czy jego treść zastępuje obraz. Test jest prosty: przeczytaj sam opis, bez patrzenia na zdjęcie. Jeśli nie wiesz, co przedstawia, opis jest zły. Obrazy czysto dekoracyjne mają mieć alt="", czyli pusty, i to jest poprawne rozwiązanie, a nie brak.

Krok 6. Odsłuchanie strony czytnikiem ekranu

To test, którego najbardziej się unika i który daje najwięcej. Na macOS włącz VoiceOver skrótem Command i F5, na Windowsie zainstaluj darmowe NVDA. Nie musisz umieć obsługiwać ich biegle. Przesłuchaj jedną podstronę od góry i słuchaj, czy da się z tego zrozumieć, gdzie jesteś i co można zrobić.

Rzeczy, które usłyszysz od razu: przyciski nazywane „link” albo „przycisk” bez treści, formularz czytany jako ciąg pól bez etykiet, menu odczytywane jako lista bez informacji, że to nawigacja, oraz karuzela, która sama się przewija i przerywa czytanie. Żaden automat tego nie zgłosi.

Komponenty, które wymagają osobnej uwagi

Sześć kroków wystarcza na typową stronę firmową. Są jednak elementy, które przechodzą wszystkie automaty, a w praktyce blokują użytkownika, i warto sprawdzić je osobno, jeśli je masz.

Okna modalne. Po otwarciu fokus ma przejść do środka okna i tam zostać, a klawisz Escape ma je zamykać i przywracać fokus do elementu, który je otworzył. Modal, z którego Tab wyprowadza w tło, jest praktycznie nieużywalny bez myszy.

Karuzele i slidery. Automatyczne przewijanie musi dać się zatrzymać, a każdy slajd ma być osiągalny sterowaniem, nie tylko gestem. Karuzela zmieniająca się co cztery sekundy przerywa czytanie czytnikiem ekranu za każdym razem.

Rozwijane menu. Jeśli działa wyłącznie na najechanie kursorem, dla klawiatury i ekranu dotykowego nie istnieje. Potrzebne jest otwieranie także klawiszem Enter albo spacją.

Filtry i wyszukiwarki z podpowiedziami. Zmiana wyników musi być zakomunikowana, inaczej osoba korzystająca z czytnika nie wie, że cokolwiek się stało. Służą do tego obszary aktualizowane na żywo.

Mapy i osadzone ramki. Każda ramka potrzebuje tytułu, a mapa alternatywy tekstowej w postaci zwykłego adresu, bo z samej mapy nie da się odczytać, gdzie jesteś.

Jak zapisać wynik, żeby się przydał

Notatka „strona ma problemy z dostępnością" jest bezużyteczna miesiąc później. Wystarczy prosta tabela z czterema kolumnami: gdzie problem występuje, na czym polega, czy blokuje wykonanie zadania i jaka jest proponowana poprawka. Jeden wiersz na znalezisko.

Ta forma ma dwie zalety. Po pierwsze, pozwala rozdzielić pracę: część pozycji trafi do arkusza stylów, część do szablonu, część do treści. Po drugie, jest punktem wyjścia do rozmowy z wykonawcą i do wyceny, bo widać zakres, a nie ogólne wrażenie.

Jeśli podlegasz ustawie, ten sam dokument jest zalążkiem dowodu, że temat został zaadresowany. Organ pyta o to, co zrobiono i kiedy, a nie o to, czy strona jest idealna.

Co zrobić z wynikami

Po tych sześciu krokach masz listę odchyleń. Uporządkuj ją nie po trudności, tylko po tym, czy blokuje wykonanie zadania. Element, przez który nie da się wysłać formularza albo dokończyć zakupu, jest ważniejszy niż zbyt jasny podpis pod zdjęciem, nawet jeśli poprawka podpisu zajmuje minutę.

Z mojego doświadczenia rozkład jest dość powtarzalny. Około połowa znalezisk to zmiany w arkuszu stylów: kontrast, styl fokusu, rozmiary elementów klikalnych. Druga połowa to szablon: etykiety pól, kolejność nagłówków, obsługa klawiatury w menu i modalach. Przebudowy serwisu wymagają naprawdę rzadkie przypadki, zwykle niestandardowe komponenty pisane bez myślenia o dostępności.

Jeśli chcesz wiedzieć, które z tych rzeczy są obowiązkiem, a które dobrą praktyką, zacznij od tekstu o WCAG na stronie firmowej, a jeśli prowadzisz sklep, sprawdź też, kogo obejmuje Europejski akt o dostępności.

Najczęstsze pytania

Czy wynik 100 w Lighthouse oznacza, że strona jest dostępna?

Nie. Lighthouse sprawdza wyłącznie te kryteria, które da się ocenić automatycznie, czyli w praktyce mniej więcej jedną trzecią wymagań WCAG. Strona z wynikiem 100 może być całkowicie nieobsługiwalna z klawiatury albo mieć opisy alternatywne w rodzaju „obrazek1”, które formalnie istnieją, a nic nie znaczą.

Ile testów wystarczy, żeby mieć sensowny obraz sytuacji?

Sześć opisanych w tym tekście: skan automatyczny, przejście klawiaturą, powiększenie do 200 procent, sprawdzenie kontrastu, przegląd nagłówków i opisów alternatywnych oraz odsłuchanie strony czytnikiem ekranu. To około 30 minut i wyłapuje zdecydowaną większość realnych problemów.

Czy do testu czytnikiem ekranu trzeba coś kupować?

Nie. Na macOS jest wbudowany VoiceOver, uruchamiany skrótem Command i F5. Na Windowsie darmowe NVDA. Nie musisz umieć ich obsługiwać biegle, wystarczy przesłuchać jedną podstronę od góry, żeby usłyszeć, czy struktura ma sens.

Kiedy samodzielny przegląd nie wystarczy?

Gdy podlegasz ustawie i musisz wykazać zgodność przed organem, gdy budujesz sklep z rozbudowaną ścieżką zakupową albo gdy strona ma komponenty niestandardowe: kalendarze, konfiguratory, mapy. Wtedy potrzebny jest pełny audyt kryterium po kryterium, bo stawką jest dokument, a nie samo wrażenie.