Audyt WCAG nie zaczyna się od narzędzia, tylko od odłożenia myszki na drugi koniec biurka. Wiem, że brzmi to jak poza, ale to jedyny sposób, żeby w ciągu pół godziny zobaczyć stronę tak, jak widzi ją część Twoich klientów. Skaner powie Ci, że gdzieś brakuje opisu obrazka. Nie powie, że klient z klawiaturą utknie w okienku z rabatem i nie dojdzie do koszyka.
Ten tekst jest instrukcją przebiegu, a nie opisem produktu. Pokazuję kolejno, co klikam, w jakiej kolejności i czego szukam na każdym etapie, a na końcu - jak zapisać jedno znalezisko, żeby dało się z niego zrobić zadanie dla programisty, a nie kolejny punkt na liście życzeń. Jeśli szukasz raczej odpowiedzi, ile taki przegląd kosztuje i jak czytać oferty, to opisałem osobno przy audycie dostępności i jego wycenie.
Zakładam poziom AA według WCAG 2.1, bo to punkt odniesienia, do którego prowadzą przepisy - kogo dokładnie obowiązują, rozkładam na części w tekście o tym, kogo dotyczy dostępność cyfrowa.
Zanim zaczniesz - wybierz ścieżki, nie podstrony
Największy błąd na starcie to otwarcie mapy strony i próba przejścia wszystkiego. Przy sklepie z tysiącem produktów to niewykonalne, a przy stronie firmowej niepotrzebne, bo trzydzieści podstron korzysta z pięciu szablonów.
Wypisuję więc ścieżki, czyli drogi, którymi ludzie faktycznie chodzą. W sklepie: strona główna, lista kategorii z filtrami, karta produktu, koszyk, checkout, logowanie i panel klienta. W firmie usługowej: główna, opis usługi, cennik, formularz kontaktowy, blog. Do tego wszystko, co jest bramą do pieniędzy albo do kontaktu - jeśli coś blokuje ludzi tam, naprawiam to pierwsze, reszta czeka.
Przy każdej ścieżce zapisuję adres i szablon, którego dotyczy. To ta sama logika, którą stosuję przy ogólnym przeglądzie strony na WordPressie: sprawdzam typy widoków, nie adresy. Dzięki temu jedna poprawka w szablonie karty produktu zamyka tysiąc pozycji naraz.
Krok 1 - automat na rozgrzewkę
Zaczynam od przebiegu automatycznego, ale traktuję go wyłącznie jako sprzątanie oczywistości. Wtyczka do przeglądarki albo wbudowany w nią audyt przelatuje kod i zwraca listę rzeczy mierzalnych maszynowo: za słaby kontrast, obrazki bez atrybutu opisu, pola bez etykiety, powtórzone identyfikatory, pomieszana kolejność nagłówków.
Robię to na każdym z wybranych szablonów, kopiuję wyniki do jednego arkusza i od razu odsiewam duplikaty. Jeśli ten sam problem wraca na sześciu widokach, to jedno zadanie w motywie, nie sześć.
I najważniejsze zastrzeżenie: jeśli automat nie znalazł nic, to nie znaczy, że strona jest dostępna. Znaczy tylko, że nie ma błędów, które maszyna umie rozpoznać. Wszystko, co decyduje o tym, czy ktoś dokończy zakup, wychodzi dopiero w kolejnych krokach.
Krok 2 - sesja z klawiaturą
To jest ta połowa godziny, która daje najwięcej. Odkładam myszkę i przechodzę całą ścieżkę używając tylko klawiszy Tab, Shift+Tab, Enter, spacji, strzałek i Escape.
Czego szukam po kolei:
- Czy w ogóle widać, gdzie jestem. Obrys wokół aktywnego elementu musi być widoczny na każdym tle. Bardzo często projektant kasuje go, bo „brzydko wygląda”, i strona staje się nie do przejścia.
- Czy kolejność ma sens. Focus powinien iść tak, jak czyta się stronę: z góry na dół, z lewej na prawo. Jeśli po menu skacze do stopki, a potem wraca do treści, coś jest nie tak z układem w kodzie.
- Czy jest skrót do treści. Pierwszy Tab na stronie powinien pokazać link „przejdź do treści”. Bez niego użytkownik klawiatury przechodzi całe menu na każdej podstronie od nowa.
- Czy da się wyjść. Okienko z rabatem, newsletterem albo zgodami zamykam Escapem. Jeśli Tab krąży w kółko po stronie pod spodem albo focus zostaje uwięziony w okienku, mam pułapkę klawiaturową - to jedno z najcięższych znalezisk, jakie można mieć.
- Czy wszystko, co klikalne, jest osiągalne. Menu rozwijane tylko po najechaniu myszką, karuzele bez strzałek, ikony zbudowane z diva zamiast przycisku - to elementy, których klawiatura po prostu nie widzi.
Zapisuję dokładnie, przy którym naciśnięciu coś się psuje. „Menu nie działa” to nie znalezisko. „Po piątym Tabie na stronie głównej focus wchodzi w podmenu Usługi, ale strzałka w dół zamyka listę zamiast przechodzić po pozycjach” - to znalezisko.
Co pomaga: przejście klawiaturą rób na świeżo, przed czytaniem raportu ze skanera. Kiedy masz w głowie listę technicznych ostrzeżeń, zaczynasz szukać ich potwierdzenia zamiast patrzeć, gdzie strona faktycznie się zacina.
Krok 3 - powiększenie, zoom i wąskie okno
Trzeci przebieg dotyczy ludzi, którzy widzą, ale słabo. To znacznie większa grupa niż osoby niewidome i najczęściej pomijana.
Ustawiam w przeglądarce powiększenie 200% i przechodzę ścieżkę jeszcze raz. Sprawdzam, czy tekst nie ucieka poza kontener, czy przyciski nie nachodzą na siebie, czy nie pojawia się poziomy pasek przewijania. Potem robię to samo przy 400% w wąskim oknie, mniej więcej szerokości telefonu. Strona powinna wtedy przełożyć się w jedną kolumnę, a nie zmusić do przewijania w bok, żeby doczytać zdanie do końca.
Dwie rzeczy wracają tu regularnie. Pierwsza to przyklejony nagłówek, który przy powiększeniu zjada połowę ekranu i zostawia użytkownikowi szczelinę na treść. Druga to tabele z cennikiem albo specyfikacją, które przy powiększeniu rozjeżdżają się w poziomie, bo nikt nie przewidział, co się z nimi stanie poza monitorem projektanta.
Przy okazji patrzę na kontrast na żywo, nie w raporcie. Otwieram stronę na telefonie i wychodzę z nim na zewnątrz. Jasnoszary tekst na białym tle, który w biurze wyglądał elegancko, w słońcu po prostu znika.
Krok 4 - audyt WCAG uchem, czyli przejście z czytnikiem ekranu
Tu zaczyna się część, której nie zastąpi żadne narzędzie, i jednocześnie ta, której najbardziej boją się osoby robiące audyt WCAG pierwszy raz. Nie trzeba być wprawnym użytkownikiem, żeby wyłapać rzeczy poważne. Wystarczy włączyć czytnik wbudowany w system (na Macu skrótem, na Windowsie darmowym programem, na telefonie w ustawieniach dostępności) i zamknąć oczy na trzy minuty.
Pierwsze, co robię, to prośba o listę nagłówków. Jeśli lista jest pusta albo składa się z jednego elementu, znaczy że nagłówki są udawane pogrubionym tekstem, a osoba niewidoma nie ma jak przeskoczyć do interesującej ją sekcji - musi przesłuchać całą stronę.
Drugie to lista linków. Jeżeli słyszę „więcej, więcej, kliknij tutaj, czytaj dalej”, to wiem, że wyrwane z kontekstu nazwy linków nic nie mówią. Trzecie to obrazki: czy opis alternatywny mówi, co jest na zdjęciu, czy to nazwa pliku i ciąg cyfr.
Najciekawsze wychodzi jednak na akcjach. Dodaję produkt do koszyka i słucham, czy cokolwiek się odezwie. W wielu sklepach potwierdzenie pojawia się jako zielony dymek w rogu i znika po trzech sekundach - wizualnie jest, dla czytnika nie istnieje. Ta sama rzecz dzieje się przy filtrach kategorii, przy przeliczaniu kosztu dostawy i przy walidacji formularza. Zmiana widoczna oczami, cisza w słuchawkach.
Krok 5 - formularze, błędy i to, co dzieje się po kliknięciu
Formularz to miejsce, gdzie dostępność i konwersja są dokładnie tym samym problemem. Dlatego ten krok robię osobno i najdokładniej.
Sprawdzam, czy każde pole ma widoczną etykietę, która zostaje na ekranie po rozpoczęciu pisania - podpowiedź szara wewnątrz pola znika w momencie, w którym staje się potrzebna. Sprawdzam, czy kliknięcie w etykietę ustawia kursor w polu, bo to najprostszy test, czy jest z nim faktycznie powiązana. Sprawdzam, czy pola adresowe pozwalają przeglądarce podpowiedzieć zapisane dane, bo dla części osób automatyczne uzupełnienie to różnica między wysłanym a porzuconym formularzem.
Potem celowo wysyłam formularz z błędami i patrzę, co się dzieje. Czy komunikat mówi, które pole i co jest nie tak, czy tylko podświetla ramkę na czerwono. Czy błąd jest przy polu, czy tylko w podsumowaniu na górze. Czy po wysłaniu focus przenosi się tam, gdzie jest problem, czy użytkownik zostaje na dole strony i sam ma się domyślić. Czy zabezpieczenie antyspamowe da się przejść bez rozpoznawania obrazków.
Ten sam przebieg robię na checkoucie, jeśli to sklep. Płatność i dostawa to najdroższe miejsce na stronie i każde zacięcie kosztuje tam realne pieniądze - piszę o tym szerzej przy skracaniu checkoutu w WooCommerce.
Co wychodzi w raporcie - anatomia jednego znaleziska
Po pięciu przebiegach mam zwykle od kilkunastu do kilkudziesięciu obserwacji. Sam ich spis nikomu nie pomoże. Pomaga dopiero forma, w której każdy punkt da się przełożyć na zadanie. Trzymam się siedmiu rubryk:
- Gdzie - adres i konkretny element, nie „sklep”
- Co się dzieje - sucha obserwacja z przebiegu
- Kogo blokuje - osoba z klawiaturą, z czytnikiem, z powiększeniem
- Które kryterium - numer i nazwa wytycznej, żeby dało się to zweryfikować
- Waga - blokada, utrudnienie albo kosmetyka
- Jak naprawić - konkret dla programisty
- Nakład - w godzinach, choćby zgrubnie
W praktyce jeden wiersz wygląda tak: karta produktu, przycisk „Dodaj do koszyka”. Po zatwierdzeniu Enterem produkt trafia do koszyka, ale czytnik ekranu milczy - potwierdzenie pokazuje się wizualnie w rogu i znika. Osoba niewidoma nie wie, czy akcja się udała, więc klika drugi i trzeci raz. Kryterium: komunikaty o stanie, poziom AA. Waga: blokada ścieżki zakupowej. Naprawa: obszar komunikatu ogłaszany przez czytnik bez przenoszenia focusu. Nakład: około godziny.
Potem układam całość w kolejność prac. Najpierw blokady na ścieżce, która zarabia. Potem rzeczy tanie i działające globalnie, czyli poprawki w szablonie. Na końcu kosmetyka. Dokument, z którego nie da się ułożyć kolejnych trzech sprintów, jest tylko opisem stanu.
Co pomaga: nagrywaj ekran podczas przebiegu klawiaturowego i z czytnikiem. Trzydziestosekundowy klip, na którym widać, jak focus wpada w pułapkę, przekonuje zarząd i programistę szybciej niż dwadzieścia stron opisu.
Jeśli chcesz zobaczyć, jak taki przebieg wygląda na Twojej stronie, podeślij mi adres. Przejdę najważniejszą ścieżkę klawiaturą i powiem, co blokuje ludzi realnie, a co jest tylko ostrzeżeniem ze skanera. Diagnoza jest bezpłatna i bez zobowiązań.
Najczęstsze pytania
Czy audyt WCAG da się zrobić samodzielnie? Pierwsze przejście tak i warto je zrobić, bo pięć opisanych wyżej kroków wyłapie większość rzeczy, które realnie blokują ludzi. Do formalnego potwierdzenia zgodności i do przygotowania dokumentów potrzebna jest już osoba, która robi to regularnie i zna kryteria z numerami.
Ile trwa taki przebieg? Dla strony firmowej z kilkoma szablonami to zwykle jeden dzień pracy na przejścia i drugi na spisanie raportu. Sklep z koszykiem, filtrami i panelem klienta to wielokrotność tego, bo każdy interaktywny element trzeba przetabować i przesłuchać osobno.
Od czego zacząć, jeśli mam czas tylko na jedną rzecz? Od przejścia klawiaturą ścieżki od strony głównej do wysłanego formularza albo złożonego zamówienia. To jedno ćwiczenie pokazuje więcej niż komplet automatycznych ostrzeżeń, bo mierzy, czy da się dokończyć to, po co ludzie przychodzą.
Czy po naprawach trzeba audyt powtórzyć? Tak, przynajmniej na tych ścieżkach, których dotyczyły zmiany. Poprawki w dostępności potrafią przesunąć kolejność focusu albo zmienić strukturę nagłówków w miejscu, którego nikt nie planował ruszać, dlatego ponowne przejście jest częścią roboty, a nie dodatkiem do niej.
Masz to u siebie i nie wiesz, od czego zacząć? Przyspieszam i naprawiam istniejące strony i sklepy - Core Web Vitals, awarie, rozbudowa o funkcje, których brakuje. Napisz, co się dzieje, a dostaniesz konkretną wycenę z terminem.