WCAG 2.1 vs 2.2: co się zmieniło i dlaczego ma to znaczenie

WCAG 2.2 to nie zastąpienie WCAG 2.1, lecz jego rozszerzenie. Dodaje dziewięć nowych kryteriów sukcesu (sześć na poziomie AA), usuwa jedno kryterium, które stały się zbędne wobec nowoczesnych przeglądarek, i zachowuje wszystko inne z 2.1 nienaruszone, więc strona już zgodna z 2.1 AA ma przed sobą krótką, konkretną lukę do zamknięcia, a nie pełny audyt od nowa.

Dlaczego istnieją dwie aktualne wersje WCAG

W3C opublikowało WCAG 2.2 w październiku 2023 roku. Ale większość ram prawnych i regulacyjnych porusza się wolniej niż organizacje ustanawiające standardy, więc wiele aktywnych obowiązków zgodności, w tym zharmonizowany standard techniczny EAA, EN 301 549, wciąż w obecnie opublikowanej wersji cytuje WCAG 2.1 AA, a nie 2.2. Dlatego obie wersje wciąż mają znaczenie w 2026 roku: 2.2 to nowszy i pełniejszy standard, ale 2.1 to często ta wersja, którą faktycznie nazywa przepis.

Takie opóźnienie jest normalne dla sposobu, w jaki standardy techniczne i przepisy prawne wchodzą ze sobą w interakcję. Przepis zwykle nazywa konkretną, datowaną wersję standardu, a nie “aktualnie obowiązującą wersję”, częściowo dla pewności prawnej, a częściowo dlatego, że aktualizacja odniesień technicznych w ustawie wymaga własnego procesu administracyjnego. EN 301 549 ma docelowo włączyć WCAG 2.2 w przyszłej wersji (v4.1.1 to wersja, która ma to zrobić), ale dopóki ta aktualizacja nie zostanie formalnie przyjęta i przywołana przez przepis, WCAG 2.1 AA pozostaje wersją, względem której faktycznie mierzona jest większość pracy nad zgodnością w UE.

Co nowego w WCAG 2.2

Nowe kryteria sukcesu skupiają się wokół kilku praktycznych tematów, zamiast być rozrzucone losowo po specyfikacji.

Widoczność fokusu otrzymuje trzy powiązane dodatki: 2.4.11 Focus Not Obscured (Minimum), które wymaga, by przynajmniej część elementu z fokusem pozostała widoczna, gdy coś w rodzaju przyklejonego nagłówka czy banera cookie mogłoby go zasłonić, oraz powiązane 2.4.12 (wersja rozszerzona, AAA) i 2.4.13 Focus Appearance (AAA), które ustalają minimalne wymogi rozmiaru i kontrastu dla wskaźników fokusu.

Uwierzytelnianie otrzymuje jeden istotny dodatek: 3.3.8 Accessible Authentication (Minimum), które wymaga, by procesy logowania nie polegały wyłącznie na teście funkcji poznawczych (jak zapamiętanie hasła czy rozwiązanie zagadki) bez alternatywy, chyba że taki test polega na przykład na rozpoznawaniu obiektów lub jest w inny sposób wspomagany.

Interakcja i cele dotykowe otrzymują dwa dodatki: 2.5.7 Dragging Movements, które wymaga alternatywy dla interakcji opartych na przeciąganiu, oraz 2.5.8 Target Size (Minimum), które ustala minimalny rozmiar 24 na 24 piksele dla klikalnych celów, chyba że mają zastosowanie wyjątki.

Pozostałe dodatki obejmują spójne mechanizmy pomocy (3.2.6 Consistent Help, wymagające, by opcja pomocy, jak link kontaktowy czy funkcja czatu, pojawiała się w tym samym względnym miejscu na wszystkich stronach, na których jest oferowana), zbędne ponowne wprowadzanie danych (3.3.7 Redundant Entry, unikanie proszenia użytkowników o ponowne wpisanie informacji, które już podali wcześniej w tym samym procesie, na przykład ponowne wpisywanie adresu dostawy podanego już na poprzednim kroku) oraz nawigację po podziale na strony (2.4.13, poziom AAA, skierowaną do treści z numeracją stron jak e-book czy długi dokument).

Dwa kolejne dodatki na poziomie AA zamykają listę: 2.4.11 ma odpowiednik rozszerzony na poziomie AAA, a pełna lista na poziomie AA, którą faktycznie trzeba sprawdzić w większości programów zgodności, to sześć nowych kryteriów: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry oraz Accessible Authentication (Minimum).

Co zostało usunięte

WCAG 2.2 usunęło 4.1.1 Parsing, stary wymóg dotyczący poprawnie sformułowanego HTML (bez duplikatów identyfikatorów, poprawnie zagnieżdżonych znaczników i tak dalej). Nowoczesne przeglądarki i technologie wspomagające na tyle dobrze radzą sobie z niepoprawnym HTML, że kryterium przestało wnosić realną wartość, więc zostało wycofane, zamiast być przeniesione dalej.

Które nowe kryteria mają w praktyce największe znaczenie

Nie wszystkie dziewięć dodatków ma równą wagę dla typowej strony firmowej. Focus Not Obscured (2.4.11) jest chyba najbardziej powszechnie istotne, ponieważ przyklejone paski nawigacji, banery zgody na cookie i widżety czatu zasłaniające wskaźnik fokusu klawiatury to niezwykle częsty, rzeczywisty problem, a nie przypadek brzegowy. Target Size (2.5.8) ma duże znaczenie dla stron mocno mobilnych z małymi celami dotykowymi. Accessible Authentication (3.3.8) ma największe znaczenie dla wszystkiego z procesem logowania, zwłaszcza jeśli ten proces używa CAPTCHA lub wyzwań opartych na pamięci bez alternatywnej ścieżki.

Redundant Entry (3.3.7) zwykle ma największe znaczenie dla procesów wieloetapowych: proces zakupowy, który prosi o adres dostawy, a potem prosi o ten sam adres ponownie na etapie płatności, bez oferowania ponownego użycia wcześniejszego wpisu, to dość częsty wzorzec, w który wprost celuje to kryterium. Dragging Movements (2.5.7) ma nieproporcjonalnie duże znaczenie dla stron z niestandardowymi elementami interaktywnymi jak suwaki zdjęć, sortowalne listy czy interfejsy mapowe, ponieważ interakcja wyłącznie oparta na przeciąganiu była historycznie powszechna w tych komponentach, bez większej refleksji nad alternatywą bez przeciągania.

Czy trzeba powtórzyć audyt

Jeśli strona już jest zgodna z WCAG 2.1 AA, przejście na 2.2 nie oznacza zaczynania od nowa. Ponieważ 2.2 jest wstecznie kompatybilne, praktyczna praca polega na sprawdzeniu strony konkretnie względem dziewięciu nowych kryteriów, a nie ponownym testowaniu wszystkiego, co już zostało zweryfikowane pod 2.1. Narzędzia testowe zbudowane wokół silnika axe-core, jak te od Deque, zaktualizowały swoje zestawy reguł, by objąć dodatki 2.2, co czyni to znacznie szybszym sprawdzeniem niż pełny audyt. Dostawcy oferujący bieżący monitoring, jak platforma AudioEye z ludzkim przeglądem w pętli, mogą też oznaczyć miejsca, w których wcześniej przechodząca testy strona ma teraz luki względem nowszych kryteriów.

Praktyczna kolejność działań: najpierw uruchom skan automatyczny z zestawem reguł uwzględniającym 2.2, by wychwycić to, co da się wykryć mechanicznie, jak małe cele dotykowe czy brak spójności linku pomocy, a następnie przeprowadź skupione przejście ręczne dla kryteriów wymagających ludzkiej oceny, zwłaszcza Focus Not Obscured i Accessible Authentication, ponieważ oba zależą od tego, jak prawdziwy użytkownik doświadcza strony, a nie od czegoś, co statyczny skan może w pełni ocenić.

Częste miejsca, w których strony zawodzą wobec nowych kryteriów

Kilka wzorców pojawia się wielokrotnie, gdy strony są sprawdzane pod kątem 2.2 po raz pierwszy. Przyklejone nagłówki i pływające widżety czatu zasłaniające pierścień fokusu klawiatury w trakcie przechodzenia po stronie klawiszem Tab to prawdopodobnie najczęstsza nowa usterka, właśnie dlatego, że to tak powszechny współczesny wzorzec projektowy. Procesy logowania i rejestracji polegające na CAPTCHA bez alternatywnej metody weryfikacji wprost zawodzą wobec Accessible Authentication. Strony e-commerce z interakcjami opartymi na przeciąganiu, jak koszyk zmieniany przez przeciąganie czy karuzela zdjęć obsługiwana wyłącznie przeciąganiem, zawodzą wobec Dragging Movements, jeśli nie ma przycisku ani alternatywy dotykowej. A ikony nawigacji mobilnej czy przyciski zamknięcia znacznie mniejsze niż minimum 24 pikseli to częsta usterka Target Size, zwłaszcza na stronach projektowanych głównie pod komputer i później adaptowanych do mobile.

Którą wersję warto obrać za cel

Jeśli obowiązujący firmę przepis lub umowa wprost nazywa WCAG 2.1 AA, spełnienie go pozostaje bazowym wymogiem prawnym, a zgodność z 2.2 można traktować jako przyszłościowe usprawnienie, a nie natychmiastowy obowiązek. Jeśli jest większa swoboda, albo buduje się coś nowego, dążenie od razu do 2.2 AA to bardziej przyszłościowy wybór, ponieważ jest ścisłym nadzbiorem 2.1 AA minus jedno zbędne kryterium. W obu przypadkach nasza checklista WCAG 2.1 AA to przydatny punkt odniesienia, jeśli audyt względem bazowego poziomu jeszcze nie został przeprowadzony.

Dla większości firm praktyczna odpowiedź brzmi “oba, po kolei”: traktować WCAG 2.1 AA jako podłogę, za którą firma jest dziś prawnie odpowiedzialna, i nakładać dodatki WCAG 2.2 jako bliski w czasie projekt usprawniający, a nie osobną inicjatywę. Ponieważ oba standardy w niemal całości się pokrywają, niewiele jest powodów, by dzielić je na osobne audyty czy osobne zaangażowania dostawców. Jedno przejście testowe obejmujące pełen zestaw kryteriów 2.2 automatycznie obejmuje też 2.1 AA, co często jest bardziej efektywnym podejściem, nawet jeśli bezpośredni obowiązek prawny dotyczy tylko starszej wersji.

Nadążanie za przyszłymi wersjami WCAG

Historia wersji WCAG sugeruje, że ten wzorzec się powtórzy. 2.0 było bazą przez lata, 2.1 dodało uwagi dotyczące mobile i słabowzroczności, a 2.2 dodało kryteria omówione powyżej; WCAG 3.0 jest w opracowaniu, z zasadniczo inną strukturą, choć wciąż pozostaje roboczą wersją, a nie gotowym standardem, a przyjęcie do przepisów zwykle opóźnia się względem publikacji o znaczącą różnicę czasu, niezależnie od wersji. Praktyczny wniosek dla firmy nie polega na gonieniu za każdą nową wersją roboczą, tylko na wbudowaniu okresowego ponownego sprawdzenia w proces dostępności (raz w roku to rozsądne dla większości stron), by w chwili, gdy nowa wersja faktycznie stanie się istotna, czy to przez zaktualizowany przepis, czy prawdziwe najlepsze praktyki, nie zaczynać od zera, by dowiedzieć się, na czym się stoi.