Testy i audyty
Automat znalazł 73 błędy WCAG. Od czego zacząć ich poprawianie?
Raport automatyczny pokazuje dziesiątki błędów WCAG. Jak odróżnić liczbę wystąpień od realnych problemów i ustalić kolejność poprawek?
Skaner dostępności pokazuje 73 błędy. Pierwsza reakcja jest zwykle prosta: trzeba zejść do zera. Tyle że sama liczba niewiele mówi o tym, ile naprawdę jest pracy i które problemy są najważniejsze.
Jedna źle zbudowana nawigacja może wygenerować ten sam błąd na kilkudziesięciu podstronach. Z kolei pojedynczy problem w formularzu płatności może wystąpić tylko raz, ale całkowicie zablokować użytkownikowi możliwość wykonania zadania. Dlatego po automatycznym skanie nie zaczynam od pozycji numer 1 w raporcie.
Najpierw sprawdź, co właściwie policzył automat
Lighthouse, axe, WAVE i inne narzędzia automatyczne są bardzo przydatne, ale nie wykonują pełnego audytu WCAG. W3C wprost zaznacza, że narzędzia nie są w stanie automatycznie sprawdzić wszystkich aspektów dostępności i że do oceny potrzebny jest człowiek.
Raport „73 błędy” może więc oznaczać 73 wystąpienia kilku problemów, a nie 73 niezależne bariery. Zanim cokolwiek poprawimy, warto pogrupować wyniki według przyczyny.
1. Grupuj błędy według komponentów
Jeżeli ten sam błąd pojawia się przy każdym elemencie menu, nie traktuję go jako kilkunastu osobnych zadań. To jeden problem komponentu nawigacji. Podobnie z kartami produktów, formularzami, przyciskami, akordeonami czy stopką.
W praktyce po pierwszym przeglądzie raportu tworzę raczej listę w rodzaju:
- nawigacja — brak poprawnych nazw dla przycisków rozwijających menu,
- formularze — błędne powiązanie etykiet z polami,
- karty artykułów — zbyt niski kontrast metadanych,
- modal — nieprawidłowe zarządzanie focusem,
- szablon wpisu — pominięty poziom nagłówka.
Nagle z 73 pozycji robi się pięć realnych problemów do przeanalizowania.
2. Najpierw bariery, które blokują wykonanie zadania
Nie każdy błąd ma taki sam wpływ. Jeśli użytkownik klawiatury nie może otworzyć menu, osoba korzystająca z czytnika nie wie, co oznacza przycisk, albo formularz nie przekazuje informacji o błędzie, to są problemy, którymi zajmuję się wcześniej niż drobnymi niedoskonałościami struktury.
Dobrym pytaniem jest: czy ten problem może zatrzymać użytkownika przed wykonaniem ważnej czynności?
Jeżeli odpowiedź brzmi „tak”, taki błąd powinien trafić wysoko na liście niezależnie od tego, czy automat wykrył go raz czy sto razy.
3. Naprawiaj źródło, nie każde wystąpienie osobno
W CMS-ach i aplikacjach duża część problemów pochodzi z komponentów współdzielonych. Jeśli błędna karta artykułu występuje na stronie głównej, w kategorii, wynikach wyszukiwania i archiwum, poprawka powinna trafić do komponentu albo szablonu, a nie do czterech widoków osobno.
To szczególnie ważne w WordPressie, Drupalu i innych systemach opartych na szablonach. Jeden problem w motywie może pojawić się na setkach adresów URL. Po poprawieniu źródła raport automatyczny potrafi nagle zmniejszyć się o kilkadziesiąt pozycji.
4. Nie poprawiaj automatu kosztem semantyki
Raport wskazuje problem, ale podpowiedź narzędzia nie zawsze jest gotowym rozwiązaniem. Typowy przykład to ARIA. Jeżeli skaner sygnalizuje brak nazwy dostępności, najgorszym odruchem jest dopisywanie aria-label do wszystkiego bez sprawdzenia, czym dany element naprawdę powinien być.
Czasem poprawnym rozwiązaniem jest użycie natywnego <button>, czasem prawidłowej etykiety formularza, a czasem usunięcie niepotrzebnego elementu interaktywnego. Dobra poprawka powinna rozwiązać przyczynę, nie tylko sprawić, że skaner przestanie świecić na czerwono.
5. Po automacie zrób testy, których automat nie potrafi zrobić
Po usunięciu błędów automatycznych nadal zostaje duża część pracy. Trzeba sprawdzić między innymi:
- czy całą funkcjonalność da się obsłużyć klawiaturą,
- czy focus jest widoczny i porusza się logicznie,
- czy po otwarciu i zamknięciu modala trafia we właściwe miejsce,
- czy komunikaty błędów są zrozumiałe i dostępne programowo,
- czy teksty alternatywne rzeczywiście opisują istotę obrazu,
- czy kolejność treści ma sens po powiększeniu i zmianie układu,
- czy komponenty dynamiczne przekazują zmianę stanu technologiom asystującym.
To właśnie dlatego wynik 100/100 w Lighthouse nie jest certyfikatem zgodności z WCAG. Oznacza tylko, że testy automatyczne wykonane przez to narzędzie nie wykryły problemów objętych jego zestawem reguł.
Jak ustalam kolejność prac
Przy większej liczbie błędów przydaje się prosty podział na cztery pytania:
- Wpływ: jak bardzo problem utrudnia korzystanie ze strony?
- Zasięg: ilu użytkowników i ile miejsc w serwisie może dotyczyć?
- Źródło: czy naprawa jednego komponentu usunie wiele wystąpień?
- Ryzyko regresji: czy poprawka może wpłynąć na inne funkcje?
W ten sposób powstaje kolejność oparta na rzeczywistym wpływie, a nie na numeracji w raporcie.
Przykład: 73 błędy, ale sześć poprawek
Wyobraźmy sobie raport: 32 problemy z kontrastem, 18 brakujących nazw przycisków, 12 błędów etykiet formularzy, 8 problemów z nagłówkami i 3 inne ostrzeżenia.
Po sprawdzeniu okazuje się, że 32 przypadki kontrastu pochodzą z jednego koloru w zmiennej CSS. Osiemnaście przycisków to ten sam komponent menu. Dwanaście etykiet pochodzi z jednego szablonu formularza. Osiem problemów nagłówków generuje jeden template.
Raport nadal miał 73 pozycje, ale technicznie cztery główne poprawki mogły usunąć większość z nich.
Jeśli masz raport z automatu albo audytu i nie wiesz, które poprawki zrobić najpierw, możesz opisać problem na redakcja@dostepnoscwcag.pl. Audytorzy i programiści mogą pomóc pogrupować problemy, ustalić priorytety i oszacować zakres wdrożenia.
Komentarze
Nie ma jeszcze komentarzy. Możesz być pierwszą osobą, która się wypowie.