WCAG 2.2 checklist dostępności — co sprawdzić krok po kroku

WCAG 2.2 checklist przydaje się każdemu, kto odpowiada za stronę internetową lub sklep i chce sprawdzić, czy nadąża za najnowszą wersją wytycznych dostępności, zanim zrobi to zewnętrzny audytor albo, co gorsza, klient zgłaszający problem. WCAG 2.2 to najnowsza aktualizacja wytycznych W3C, która nie zastępuje poprzedniej wersji, tylko ją rozszerza — dodaje nowe kryteria sukcesu, głównie w obszarach nawigacji klawiaturą, rozmiaru elementów dotykowych i procesów logowania.

W tym artykule zebraliśmy praktyczną checklistę WCAG 2.2 — bez teorii prawniczej, za to z konkretnymi punktami do sprawdzenia na własnej stronie. Jeśli szukasz szerszego wprowadzenia do samego standardu i poziomów zgodności, zajrzyj do naszego przewodnika po dostępności WCAG — tam wyjaśniamy podstawy, na których opiera się cała lista poniżej.

Czym różni się WCAG 2.2 od WCAG 2.1

WCAG 2.2 zachowuje całą strukturę poprzedniej wersji — te same cztery zasady (postrzegalność, funkcjonalność, zrozumiałość, solidność) i te same poziomy zgodności A, AA i AAA. Zmiana polega na dodaniu nowych kryteriów sukcesu, które odpowiadają na problemy widoczne dopiero po latach praktycznego stosowania wcześniejszych wersji standardu — przede wszystkim na urządzeniach mobilnych i w interfejsach z rozbudowaną nawigacją klawiaturą. Usunięto też jedno kryterium uznane za nieaktualne wobec dzisiejszych przeglądarek, dotyczące poprawności parsowania kodu HTML.

Dla firm, które mają już wdrożoną zgodność z WCAG 2.1, dobra wiadomość jest taka, że nie trzeba zaczynać pracy od zera. Wystarczy uzupełnić istniejący proces o nowe punkty kontrolne, najlepiej w ramach najbliższej aktualizacji strony lub sklepu, a nie jako osobny, duży projekt.

WCAG 2.2 checklist — nowe kryteria sukcesu do sprawdzenia

Poniższa checklista WCAG 2.2 obejmuje kryteria dodane w tej wersji standardu. To punkty, których nie znajdziesz jeszcze w starszych audytach opartych na WCAG 2.1, więc warto sprawdzić je osobno, nawet jeśli strona przechodziła już wcześniej weryfikację dostępności.

• Widoczność elementu z fokusem (poziom AA) — element, na którym aktualnie znajduje się fokus klawiatury, nie może być całkowicie zasłonięty przez inne komponenty interfejsu, np. sticky header, baner cookies czy czat.
• Wygląd fokusu (poziom AAA, warto wdrożyć niezależnie od docelowego poziomu) — obramowanie lub inne oznaczenie fokusu musi być wystarczająco kontrastowe i wystarczająco duże, by dało się je łatwo zauważyć.
• Alternatywa dla przeciągania (poziom AA) — jeśli funkcja strony wymaga przeciągania elementu (np. suwak, sortowanie listy), musi istnieć również sposób wykonania tej samej akcji bez przeciągania, np. przyciskami.
• Minimalny rozmiar celu dotykowego (poziom AA) — przyciski, linki i inne elementy klikalne na urządzeniach dotykowych powinny mieć odpowiednio duży obszar reagowania na dotyk, z odpowiednim odstępem od sąsiednich elementów.
• Spójna pomoc (poziom A) — jeśli na kilku podstronach umieszczony jest ten sam mechanizm pomocy (np. link do kontaktu, chat, numer telefonu), powinien znajdować się w tym samym, przewidywalnym miejscu w kolejności nawigacji.
• Brak powtarzania wpisanych danych (poziom A) — w wieloetapowych formularzach użytkownik nie powinien być zmuszany do ponownego wpisywania informacji, które podał wcześniej w tym samym procesie (np. adresu przy przejściu z koszyka do płatności).
• Dostępne uwierzytelnianie (poziom AA) — logowanie nie może opierać się wyłącznie na zadaniach wymagających zapamiętywania, przepisywania lub rozwiązywania (np. captcha bez alternatywy), jeśli istnieje prostszy, równie bezpieczny sposób weryfikacji.

Warto potraktować tę listę jako uzupełnienie, a nie zamiennik pełnej checklisty poziomu AA — reszta kryteriów z WCAG 2.1, dotycząca kontrastu, tekstów alternatywnych, struktury nagłówków czy obsługi formularzy, obowiązuje w niezmienionej formie.

Jak wykorzystać checklistę WCAG 2.2 w praktyce

Sama lista kryteriów niewiele daje bez ustalonego sposobu ich sprawdzania. W praktyce sprawdza się podejście etapowe, które można wdrożyć samodzielnie, zanim zleci się pełny audyt:

1. Przejdź przez najważniejsze ścieżki użytkownika (logowanie, formularz kontaktowy, proces zakupowy) wyłącznie za pomocą klawiatury i sprawdź, czy fokus jest zawsze widoczny i niczym nie zasłonięty.
2. Na urządzeniu mobilnym sprawdź rozmiar i odstępy przycisków w menu, filtrach i formularzach — szczególnie tam, gdzie elementy są gęsto rozmieszczone.
3. Zweryfikuj, czy jakakolwiek funkcja strony wymaga przeciągania elementu, i jeśli tak, sprawdź, czy istnieje alternatywa działająca na kliknięcie lub dotyk.
4. Przejrzyj proces logowania i rejestracji pod kątem dostępnego uwierzytelniania — zwłaszcza jeśli korzystasz z captcha lub pytań weryfikacyjnych.
5. Sprawdź, czy link lub przycisk pomocy pojawia się w tym samym miejscu na wszystkich podstronach, na których występuje.

Taka wstępna weryfikacja nie zastąpi pełnego audytu, ale pozwala wychwycić część problemów wcześnie, bez angażowania zewnętrznych zasobów. Jeśli zależy Ci na pełnym obrazie zgodności, w tym elementach, które trudno ocenić bez odpowiednich narzędzi i doświadczenia, opisujemy cały proces w artykule jak przebiega audyt dostępności.

WCAG 2.2 a przepisy — dlaczego checklista ma znaczenie prawne

Aktualizacja standardu ma znaczenie nie tylko techniczne, ale i prawne. Regulacje dotyczące dostępności cyfrowej, zarówno w sektorze publicznym, jak i coraz szerzej w sektorze prywatnym, odwołują się do aktualnych wersji WCAG jako punktu odniesienia. Europejski akt o dostępności, który obejmuje między innymi e-commerce, bankowość elektroniczną i sprzedaż biletów, opisujemy szerzej w artykule o europejskim akcie o dostępności — tam znajdziesz informacje o tym, kogo dokładnie dotyczą nowe obowiązki i jakie mogą być konsekwencje ich niespełnienia.

Z perspektywy praktycznej oznacza to, że firmy planujące audyt dostępności lub przygotowujące się do niego powinny od razu uwzględniać wymagania WCAG 2.2, a nie tylko starszą wersję 2.1. Zmniejsza to ryzyko, że wdrożone poprawki okażą się niekompletne już kilka miesięcy po zakończeniu projektu.

Najczęstsze błędy przy wdrażaniu checklisty WCAG 2.2

Z naszych obserwacji przy pracach nad dostępnością wynika, że nowe kryteria WCAG 2.2 najczęściej gubią się na styku projektowania i wdrożenia, a nie na etapie samej koncepcji. Do typowych błędów należą:

• projektowanie stanu fokusu wyłącznie dla desktopu, bez sprawdzenia, jak zachowuje się on przy powiększonym widoku lub przy otwartym menu mobilnym,
• traktowanie rozmiaru celu dotykowego jako kwestii wyłącznie wizualnej, bez uwzględnienia realnych odstępów między przyciskami w gęstych układach, np. w filtrach sklepu,
• wdrażanie zabezpieczeń logowania (captcha, pytania kontrolne) bez konsultacji z zespołem odpowiedzialnym za dostępność,
• brak jednolitego miejsca dla linku pomocy lub kontaktu między różnymi szablonami strony, zwłaszcza po migracjach lub redesignach częściowych.

Większość z tych problemów da się wyeliminować już na etapie projektowania makiet i komponentów, zanim trafią one do developmentu — poprawki wprowadzone po wdrożeniu są zwykle droższe i bardziej czasochłonne niż te uwzględnione od początku.

Najczęstsze pytania

Czy WCAG 2.2 zastępuje WCAG 2.1?

Nie. WCAG 2.2 rozszerza wcześniejszą wersję o nowe kryteria sukcesu, zachowując całą dotychczasową strukturę i poziomy zgodności. Strona zgodna z WCAG 2.1 nie traci tej zgodności, ale powinna zostać uzupełniona o punkty dodane w wersji 2.2.

Ile nowych kryteriów wprowadza WCAG 2.2?

WCAG 2.2 dodaje nowe kryteria sukcesu na poziomach A, AA i AAA, dotyczące między innymi widoczności fokusu, rozmiaru elementów dotykowych, alternatywy dla przeciągania oraz dostępnego uwierzytelniania. Jedno starsze kryterium, dotyczące poprawności parsowania kodu, zostało usunięte jako nieaktualne.

Czy checklista WCAG 2.2 wystarczy zamiast pełnego audytu?

Checklista pozwala szybko zweryfikować najbardziej charakterystyczne nowe wymagania, ale nie zastępuje pełnego audytu. Część kryteriów, także tych z WCAG 2.1, wymaga oceny kontekstowej i testów z technologiami wspomagającymi, których nie da się w pełni przeprowadzić samodzielnie bez odpowiedniego doświadczenia.

Od czego zacząć, jeśli strona nie była wcześniej sprawdzana pod kątem WCAG 2.2?

Najlepiej zacząć od przejścia checklisty z tego artykułu na najważniejszych ścieżkach użytkownika, a następnie zlecić pełny audyt, który pokaże pełny obraz zgodności i pozwoli ustalić priorytety wdrożenia poprawek.

Czy nowe kryteria WCAG 2.2 dotyczą tylko dużych serwisów?

Nie, dotyczą każdej strony i aplikacji internetowej niezależnie od jej wielkości. Elementy takie jak rozmiar przycisków dotykowych czy widoczność fokusu wpływają na wygodę korzystania ze strony dla wszystkich użytkowników, nie tylko w kontekście formalnej zgodności z przepisami.

Jeśli chcesz sprawdzić, jak Twoja strona wypada wobec pełnej checklisty WCAG 2.2, a nie tylko wybranych punktów, skorzystaj z naszej oferty audytów WCAG 2.1, w ramach której uwzględniamy również nowe kryteria wprowadzone w wersji 2.2 i przygotowujemy raport z jasnymi priorytetami wdrożenia.