6 nowych kryteriów WCAG 2.2 w EN 301 549 i koniec kryterium 4.1.1

Sześć kryteriów w jednej tabeli

2.4.11 Fokus niezasłonięty: przyklejone nagłówki i banery

Gdy element otrzymuje fokus klawiatury, nie może być w całości zasłonięty przez treść dodaną przez twórcę strony. Najczęstsi winowajcy to przyklejone nagłówki, stopki z przyciskiem czatu i banery cookie. Osoba poruszająca się klawiaturą przechodzi tabulatorem dalej, a element z fokusem chowa się pod nagłówkiem; nie wie więc, gdzie jest.

Jak testować: przejdź całą stronę klawiszem Tab przy różnych szerokościach okna i z otwartym banerem cookie. Kryterium w wersji minimum wymaga, by element był widoczny choć częściowo.

2.5.7 Ruchy przeciągania: suwaki, mapy, tablice

Funkcję, którą obsługuje się przeciąganiem, musi dać się wykonać pojedynczym wskazaniem, bez przeciągania (chyba że przeciąganie jest niezbędne). Dotyczy to suwaków ceny, zmiany kolejności elementów na liście, przesuwania mapy czy tablic zadań. Rozwiązaniem są np. przyciski „w górę / w dół”, pola do wpisania wartości albo kliknięcie punktu docelowego.

Jak testować: znajdź wszystkie miejsca z przeciąganiem i sprawdź, czy ten sam efekt da się osiągnąć jednym kliknięciem lub dotknięciem. Obsługa klawiaturą nie wystarcza: kryterium dotyczy użytkowników wskaźnika, np. myszy lub ekranu dotykowego.

2.5.8 Rozmiar celu: 24 na 24 piksele

Cel dotyku lub kliknięcia ma mieć co najmniej 24 × 24 piksele CSS. Mniejszy cel jest dopuszczalny, jeśli ma wokół siebie wystarczająco dużo wolnego miejsca: koło o średnicy 24 px wokół niego nie może nachodzić na inne cele. Są też wyjątki: linki w tekście, elementy, których wyglądu twórca nie kontroluje (np. natywne kontrolki przeglądarki), cele, dla których istnieje równoważny większy odpowiednik, oraz sytuacje, gdy dany rozmiar jest niezbędny.

Jak testować: zmierz ikony w nagłówku, przyciski zamykania, paginację i linki w stopce w narzędziach deweloperskich przeglądarki. Część narzędzi automatycznych wykrywa zbyt małe cele, ale nie zawsze poprawnie ocenia wyjątki.

3.2.6 Spójna pomoc

Jeśli na wielu stronach serwisu powtarza się mechanizm pomocy (dane kontaktowe, formularz kontaktowy, czat, strona FAQ), ma występować w tej samej kolejności względem innych treści. Kryterium nie wymaga dodania pomocy; wymaga tylko, by istniejąca pomoc nie „wędrowała” po stronie. To szczególnie ważne dla osób z niepełnosprawnościami poznawczymi.

3.3.7 Zbędne wprowadzanie danych

Informacja, którą użytkownik już podał w tym samym procesie, ma być uzupełniona automatycznie albo dostępna do wybrania. Klasyczny przykład to adres dostawy i adres do faktury w sklepie. Wyjątkami są sytuacje, gdy ponowne wpisanie jest niezbędne (np. gra pamięciowa), wymagane ze względów bezpieczeństwa (np. potwierdzenie hasła) albo gdy wcześniejsza informacja przestała być aktualna.

3.3.8 Dostępne uwierzytelnianie

Logowanie nie może wymagać testu funkcji poznawczych (zapamiętania hasła, przepisania kodu, rozwiązania zagadki), chyba że istnieje alternatywa albo mechanizm pomocy. W praktyce oznacza to: zezwalaj na wklejanie haseł i kodów, nie blokuj menedżerów haseł, oferuj logowanie linkiem lub kluczem dostępu. Kryterium dopuszcza testy rozpoznawania obiektów i treści osobistych (np. wybór własnego zdjęcia).

Jak testować: przejdź logowanie, rejestrację, reset hasła i uwierzytelnianie dwuskładnikowe. Sprawdź, czy pole hasła pozwala na wklejanie, czy menedżer haseł działa i czy CAPTCHA ma alternatywę.

4.1.1 Parsowanie: koniec kryterium

W WCAG 2.2 kryterium 4.1.1 uznano za przestarzałe, bo współczesne przeglądarki i technologie asystujące radzą sobie z błędami składni, których dotyczyło. V4.1.1 oznacza je jako „Void”. W raportach według nowej wersji normy nie wpisujemy już dla niego wyniku. Problemy, które faktycznie przeszkadzają użytkownikom (np. zduplikowane identyfikatory psujące etykiety pól), nadal wychwytują inne kryteria, np. 1.3.1 i 4.1.2.

Co wykryje automat, a co wymaga testera

Narzędzia automatyczne pomagają głównie przy 2.5.8 (pomiar celów), częściowo przy 2.4.11. Kryteria 2.5.7, 3.2.6, 3.3.7 i 3.3.8 wymagają przejścia ścieżek użytkownika przez człowieka: automat nie wie, które pola były już wypełnione ani czy logowanie opiera się na pamięci.

Chcesz sprawdzić, czy przyciski na Twojej stronie mają właściwy rozmiar? Zacznij od Accessibility CHECK. Logowanie, formularze i procesy zakupowe najlepiej zbadać w teście eksperckim Accessibility PRO.

Najczęściej zadawane pytania

Jaki minimalny rozmiar przycisku wymaga WCAG 2.2?

Na poziomie AA co najmniej 24 × 24 piksele CSS albo odpowiedni odstęp od innych celów.

Czy 4.1.1 trzeba jeszcze testować?

Nie według WCAG 2.2 i EN 301 549 V4.1.1. Według V3.2.1, która nadal jest punktem odniesienia do czasu cytowania nowej wersji, kryterium formalnie obowiązuje.

Czy nowe kryteria dotyczą plików PDF?

Tak, przez klauzulę 10, z uwzględnieniem wyjaśnień WCAG2ICT dla dokumentów.

Źródła

• ETSI EN 301 549 V4.1.1 (2026-09)
• BarrierBreak: EN 301 549 V4.1.1
• Do dodania przez redakcję: W3C „What’s New in WCAG 2.2” i dokumenty Understanding dla każdego kryterium