WCAG 2.2 — od czego zacząć?

WCAG 2.2 ma 86 kryteriów sukcesu. Jeśli otworzysz specyfikację i zaczniesz sprawdzać stronę od punktu 1.1.1, szybko dojdziesz do wniosku, że dostępność to projekt na kilka tygodni. W praktyce lepiej zacząć inaczej: od kilku rzeczy, które najczęściej blokują korzystanie ze strony.

Na początek nie potrzebujesz też rozbudowanego zestawu narzędzi. Klawiatura, przeglądarka i kilka prostych testów pokażą więcej, niż sugeruje wynik jednego automatycznego skanera.

Najpierw sprawdź, czy stronę da się obsłużyć bez myszy

Odłóż mysz. Naciśnij Tab i przejdź po stronie od początku do końca.

Sprawdź trzy rzeczy: czy da się dotrzeć do wszystkich linków, przycisków i pól formularzy, czy kolejność przechodzenia ma sens oraz czy zawsze widać, który element ma aktualnie fokus.

To prosty test, ale potrafi ujawnić poważne problemy: menu, którego nie da się otworzyć klawiaturą, przycisk działający tylko po kliknięciu myszą, modal bez możliwości zamknięcia albo fokus, który znika pod przyklejonym nagłówkiem.

W WCAG 2.2 temat fokusu został dodatkowo rozszerzony. Pojawiło się między innymi kryterium 2.4.11 „Focus Not Obscured (Minimum)” na poziomie AA. Chodzi o sytuacje, w których element posiada fokus, ale jest zasłonięty przez inny fragment interfejsu.

Potem zobacz strukturę strony, a nie tylko jej wygląd

Nagłówek, który wygląda jak nagłówek, powinien nim być również w HTML. Lista powinna być listą. Przycisk powinien być przyciskiem, a nie elementem <div> z dopisanym zdarzeniem kliknięcia.

To ważne, bo użytkownik czytnika ekranu nie odbiera strony tak jak osoba patrząca na monitor. Struktura HTML jest dla technologii asystujących czymś w rodzaju mapy interfejsu.

Na pierwszym przeglądzie sprawdź przede wszystkim:

• czy strona ma sensowną hierarchię nagłówków,
• czy elementy interaktywne mają właściwą semantykę,
• czy linki mają zrozumiałe nazwy,
• czy obrazki informacyjne mają sensowny tekst alternatywny,
• czy elementy dekoracyjne nie są niepotrzebnie odczytywane.

W3C w swoich „Easy Checks” wskazuje nagłówki jako jeden z podstawowych elementów pierwszego przeglądu dostępności. Użytkownicy czytników ekranu mogą przechodzić bezpośrednio między nagłówkami i w ten sposób szybko zorientować się w strukturze strony.

Formularz to dobry test całego interfejsu

Jeśli na stronie jest formularz kontaktowy, logowanie, wyszukiwarka albo zapis do newslettera, sprawdź je wcześnie. W jednym miejscu spotykają się tam etykiety, komunikaty błędów, obsługa klawiatury, fokus i informacje przekazywane użytkownikowi.

Pole z samym placeholderem „Twój e-mail” nie jest dobrym zamiennikiem etykiety. Po wpisaniu tekstu placeholder znika. Czytnik ekranu również potrzebuje poprawnie określonej nazwy pola.

Spróbuj też wysłać formularz pusty albo celowo wpisać błędne dane. Czy komunikat mówi, co jest nie tak? Czy da się go znaleźć bez patrzenia na czerwone obramowanie? Czy po błędzie użytkownik wie, gdzie powinien wrócić?

Kontrast jest ważny, ale nie zaczynaj i nie kończ na kontraście

Kontrast łatwo zmierzyć, dlatego często staje się pierwszym skojarzeniem z WCAG. Jest ważny, ale dostępna strona to znacznie więcej niż ciemny tekst na jasnym tle.

Sprawdź tekst, linki, przyciski, ikony i stany fokusu. Potem powiększ stronę do 200%. Zobacz, czy treść nadal da się czytać i czy elementy nie nachodzą na siebie. W węższym widoku zwróć uwagę na menu, formularze, tabele oraz komponenty, które przy standardowej szerokości wyglądają poprawnie.

WCAG 2.2 nie oznacza, że wszystko trzeba budować od nowa

WCAG 2.2 zostało opublikowane jako rekomendacja W3C 5 października 2023 roku. W stosunku do WCAG 2.1 dodano dziewięć kryteriów sukcesu. Jednocześnie kryterium 4.1.1 „Parsing” zostało uznane za przestarzałe i usunięte z wersji 2.2.

Nowe wymagania dotyczą między innymi widoczności fokusu, przeciągania elementów, minimalnego rozmiaru celu dotykowego, powtarzanego wprowadzania tych samych danych oraz dostępnego uwierzytelniania.

To nie znaczy, że strona zgodna wcześniej z WCAG 2.1 wymaga automatycznie przebudowy od zera. Najczęściej trzeba sprawdzić istniejące komponenty i uzupełnić konkretne braki. W3C zachęca do stosowania najnowszej wersji WCAG jako celu zgodności, nawet jeśli część formalnych wymagań nadal odwołuje się do wcześniejszych wersji.

Nie zaczynaj od wyniku 100/100

Lighthouse, axe, WAVE i inne automaty są przydatne. Potrafią szybko wychwycić część błędów technicznych i świetnie sprawdzają się podczas pracy nad stroną. Nie są jednak audytem WCAG.

Automat nie oceni dobrze wszystkiego, co wymaga zrozumienia kontekstu. Może sprawdzić, czy obraz ma atrybut alt, ale nie zawsze odpowie, czy jego treść rzeczywiście przekazuje to, co powinien wiedzieć użytkownik. Nie oceni też w pełni sensowności kolejności fokusu czy tego, czy komunikat błędu jest faktycznie zrozumiały.

W3C samo zaznacza, że proste kontrole dostępności dają jedynie wstępny obraz sytuacji. Strona może przejść takie testy i nadal zawierać poważne bariery.

Od czego więc zacząć?

Jeżeli masz istniejącą stronę, zrób najpierw jeden krótki przegląd ręczny. Przejdź ją klawiaturą. Sprawdź nagłówki. Wypełnij formularze. Powiększ widok. Obejrzyj wersję mobilną. Dopiero potem uruchom automat i porównaj jego wyniki z tym, co zauważyłeś sam.

Jeśli błędy powtarzają się na wielu podstronach, zacznij od elementów wspólnych: nagłówka, menu, stopki, formularzy i komponentów używanych w całym serwisie. Naprawienie jednego źle zbudowanego komponentu często usuwa ten sam problem w kilkudziesięciu miejscach.

Dopiero później ma sens przechodzenie przez pełną listę kryteriów WCAG i przygotowanie reprezentatywnej próbki do dokładniejszego audytu.

Jeśli po pierwszym przeglądzie widzisz, że problemów jest więcej albo nie wiesz, od czego zacząć poprawki, napisz na redakcja@dostepnoscwcag.pl. Możemy ocenić zakres prac, wskazać priorytety i przygotować wycenę audytu lub dostosowania strony.

Źródła

• W3C WAI — What’s New in WCAG 2.2
• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI — Easy Checks