Co nowego w WCAG 2.2? 9 nowych kryteriów prostym językiem

Ktoś przechodzi klawiszem Tab przez Twój proces zamówienia. Fokus trafia na przycisk „Zapłać teraz”, ale przykrywa go przyklejony baner cookies, więc ta osoba nie widzi, gdzie jest. Według WCAG 2.1 taka strona mogła jeszcze przejść test. Według WCAG 2.2 już go nie przechodzi.

Właśnie takie luki zamyka aktualizacja 2.2. Poniżej każde nowe kryterium sukcesu omawiamy tak samo: co mówi, komu pomaga, jak je szybko sprawdzić i jak zwykle się je naprawia. Cztery zasady i poziomy zgodności na jednej stronie znajdziesz w naszym przeglądzie WCAG 2.2.

Czym jest WCAG 2.2?

WCAG 2.2 to aktualna wersja Wytycznych dla dostępności treści internetowych, czyli standardu W3C, do którego odsyła większość przepisów i umów dotyczących dostępności. Rekomendacją W3C stało się 5 października 2023 r. (otwiera się w nowej karcie), zostało zaktualizowane 12 grudnia 2024 r. (otwiera się w nowej karcie), a w październiku 2025 r. zatwierdzono je jako normę ISO/IEC 40500:2025 (otwiera się w nowej karcie).

WCAG składa się z testowalnych stwierdzeń zwanych kryteriami sukcesu. Każde ma swój poziom: A (minimum), AA (tego zwykle wymagają przepisy) lub AAA (najbardziej rygorystyczny). „Potrzebujemy WCAG 2.2 AA” oznacza więc wszystkie kryteria A i AA w wersji 2.2. Specyfikacja mówi, że WCAG 2.2 „opiera się na WCAG 2.1 i jest z nim wstecznie zgodne”, a zatem uzupełnia wersję 2.1, zamiast ją zastępować.

Co się zmieniło między WCAG 2.1 a 2.2?

WCAG 2.2 dodaje dziewięć kryteriów sukcesu i jedno usuwa. Sześć nowych ma poziom A lub AA, więc liczy się do zwykłego celu AA: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 i 3.3.8. Pozostałe trzy mają poziom AAA. Usunięte zostało kryterium 4.1.1 Poprawność kodu (Parsing), które W3C uznaje dziś za przestarzałe.

Kryterium 4.1.1 sprawdzało błędy w znacznikach, np. powtórzone identyfikatory. FAQ do WCAG 2 (otwiera się w nowej karcie) wyjaśnia, że te problemy obejmują dziś inne kryteria, takie jak 4.1.2 Nazwa, rola, wartość. Jest jeden haczyk: jeśli umowa nadal wymaga WCAG 2.0 lub 2.1, być może „trzeba będzie nadal testować i raportować 4.1.1”.

Fokus niezasłonięty i wygląd fokusu: czy użytkownik klawiatury widzi, gdzie jest?

Te kryteria (Focus Not Obscured i Focus Appearance) pilnują, by element z fokusem klawiatury był widoczny. Na poziomie AA (2.4.11) link lub przycisk z fokusem nie może być w całości zasłonięty przez dodane przez Ciebie treści, takie jak przyklejony nagłówek, baner cookies czy dymek czatu. Na poziomie AAA nic nie może zasłaniać żadnej jego części (2.4.12), a obrys fokusu musi być duży i wyraźnie kontrastowy (2.4.13).

• Komu pomaga: osobom widzącym, które zamiast myszy używają klawiatury, często z powodu niepełnosprawności ruchowej. Jeśli nie widzą fokusu, poruszają się na ślepo.
• Szybki test: otwórz długą stronę z widocznym banerem cookies, przyklejonym nagłówkiem i widżetem czatu, a potem wielokrotnie naciskaj Tab. Jeśli fokus całkowicie znika pod którymś z tych elementów, kryterium 2.4.11 nie jest spełnione.
• Typowa poprawka: dodaj w CSS scroll-padding równy wysokości przyklejonego nagłówka lub stopki, żeby przeglądarka przewijała element z fokusem poza ich obszar. W3C wymienia to jako technikę wystarczającą (otwiera się w nowej karcie). Baner może też przejść test, jeśli jest modalny i trzeba go najpierw zamknąć.

Wygląd fokusu (2.4.13) wymaga wskaźnika co najmniej tak dużego jak obrys o grubości 2 pikseli CSS wokół komponentu oraz zmiany kontrastu co najmniej 3:1 między stanem z fokusem i bez niego. To poziom AAA, ale ciągły obrys o grubości 2 pikseli w wyrazistym kolorze zwykle wystarcza. Jak zmierzyć 3:1, wyjaśniamy w poradniku o kontraście kolorów.

Ruchy przeciągania i rozmiar celu: czy da się korzystać ze strony bez precyzyjnego celowania?

Te dwa kryteria poziomu AA pomagają osobom, którym trudno precyzyjnie sterować wskaźnikiem. Według 2.5.7 wszystko, co można zrobić przeciąganiem, musi też działać pojedynczymi kliknięciami lub dotknięciami. Według 2.5.8 cele muszą mieć co najmniej 24 na 24 piksele CSS albo być rozmieszczone tak, by okrąg o średnicy 24 pikseli wyśrodkowany na każdym z nich nie dotykał innego celu.

2.5.7 Ruchy przeciągania (Dragging Movements)

Pomyśl o suwaku zakresu cen w filtrach sklepu albo o liście życzeń, której kolejność zmienia się przeciąganiem. Dla osoby z drżeniem rąk albo korzystającej z myszy sterowanej ruchem głowy sekwencja „naciśnij, przytrzymaj, przesuń, puść” bywa bardzo trudna.

Szybki test: wykonaj każde zadanie wymagające przeciągania wyłącznie kliknięciami lub dotknięciami. Typowa poprawka: pozwól klikać w dowolne miejsce ścieżki suwaka, dodaj obok pola „od” i „do” albo przyciski „Wyżej” i „Niżej” przy sortowanych listach. Sama obsługa klawiaturą nie wystarcza: objaśnienia W3C (otwiera się w nowej karcie) mówią, że odpowiednik klawiaturowy „nie oznacza automatycznie spełnienia tego kryterium sukcesu”.

2.5.8 Rozmiar celu dotykowego, minimum (Target Size, Minimum)

Najczęściej problem sprawiają małe przyciski „×” w wyskakujących okienkach, ciasno ułożone numery stron, gwiazdki ocen i rzędy ikon serwisów społecznościowych. Trafienie w niewłaściwy element irytuje każdego, a dla osób z ograniczoną sprawnością rąk jest realną barierą.

• Wyjątki: linki wewnątrz zdania, cele, które mają na tej samej stronie odpowiednik o wymaganym rozmiarze, kontrolki, których wielkość ustala przeglądarka i których nie zmieniano stylami, oraz sytuacje, w których określony rozmiar jest niezbędny lub wymagany prawem.
• Szybki test: na telefonie wypróbuj każdą małą ikonę i każdy przycisk; żeby zmierzyć element, sprawdź go w narzędziach deweloperskich przeglądarki.
• Typowa poprawka: dodaj padding. Obszar klikalny rośnie, nawet jeśli ikona wygląda tak samo. Traktuj też 24 piksele jako absolutne minimum: starsze kryterium AAA 2.5.5 wymaga 44 na 44.

Spójna pomoc i zbędne wprowadzanie danych: czy każesz ludziom szukać albo się powtarzać?

Oba kryteria mają poziom A. Według 3.2.6 (Consistent Help), jeśli pomoc, np. dane kontaktowe, czat albo link do FAQ, pojawia się na kilku stronach, za każdym razem musi występować w tej samej kolejności względem reszty strony. Według 3.3.7 (Redundant Entry) w jednym procesie nie powinno się wymagać ponownego wpisywania informacji, które użytkownik już podał.

Spójna pomoc nie zobowiązuje do oferowania pomocy w ogóle. Mówi tylko, że jeśli numer telefonu jest w nagłówku stron produktów, nie powinien w procesie zamówienia przeskakiwać do stopki, czyli tam, gdzie ludzie najbardziej go potrzebują. Najwięcej zyskują osoby z trudnościami z pamięcią lub koncentracją. Zwykle wystarczy wspólny szablon zamiast ręcznego umieszczania pomocy na każdej stronie.

Kryterium zbędnego wprowadzania danych dotyczy formularzy wieloetapowych. Formularz rezerwacji, który pyta o e-mail w kroku 1 i ponownie w kroku 3, nie spełnia go, podobnie jak zamówienie, w którym trzeba przepisać identyczny adres rozliczeniowy. Uzupełnij pole automatycznie albo pozwól je wybrać, np. polem wyboru „Adres rozliczeniowy taki sam jak adres dostawy”. Wyjątki: ponowne wpisanie jest niezbędne, wymagają go względy bezpieczeństwa albo wcześniejsze informacje straciły ważność.

Dostępne uwierzytelnianie: czy da się zalogować bez testu pamięci?

Kryterium sukcesu 3.3.8 (poziom AA, Accessible Authentication) mówi, że żaden krok logowania nie może opierać się na teście funkcji poznawczych, takim jak zapamiętanie hasła, przepisanie zniekształconych znaków czy rozwiązanie łamigłówki, chyba że udostępniasz alternatywę albo mechanizm pomocniczy. W praktyce: pozwól menedżerom haseł wypełniać pola, nie blokuj wklejania i zaproponuj metodę, która nie zależy od pamięci.

WCAG definiuje test funkcji poznawczych jako „zadanie, które wymaga od użytkownika zapamiętania, przekształcenia lub przepisania informacji”. Wpisanie imienia, adresu e-mail czy numeru telefonu się nie liczy, bo to dane osobiste, wszędzie takie same. Krok logowania spełnia wymagania poziomu AA, jeśli oferuje co najmniej jedną z tych możliwości:

• Alternatywną metodę bez testu funkcji poznawczych, np. klucz dostępu (passkey) albo link wysyłany e-mailem.
• Mechanizm pomocniczy, np. obsługę menedżerów haseł albo kopiowanie i wklejanie, dzięki któremu nie trzeba przepisywać kodu jednorazowego.
• Rozpoznawanie obiektów, np. „zaznacz zdjęcia z rowerem”.
• Treści osobiste, np. wskazanie zdjęcia, które użytkownik sam przesłał.

Wersja AAA, czyli 3.3.9, pomija dwie ostatnie możliwości, więc obrazkowa CAPTCHA może przejść test na poziomie AA, ale nie AAA. Typowe błędy: pola hasła blokujące wklejanie lub menedżery haseł, pola kodu jednorazowego, które psują się po wklejeniu, i tekstowa CAPTCHA bez alternatywy. Najwięcej zyskują osoby z dysleksją lub zaburzeniami pamięci, ale problem zna każdy, kto po długim dniu nie mógł się zalogować.

Czy WCAG 2.2 jest wymagane prawem?

Zależy, gdzie działasz i kim jesteś. Przepisy rzadko wskazują wersję WCAG wprost, a wiele z nich nadal odsyła do WCAG 2.1 AA. Ponieważ WCAG 2.2 jest wstecznie zgodne, spełnienie 2.2 AA oznacza spełnienie 2.1 AA, z wyjątkiem usuniętego 4.1.1. Celując w 2.2, spełniasz wymagania obu wersji. Jeśli umowa wskazuje konkretną wersję, trzymaj się umowy.

• Unia Europejska: na gruncie Europejskiego aktu w sprawie dostępności domniemanie zgodności daje spełnienie normy zharmonizowanej EN 301 549. Według AccessibleEU (otwiera się w nowej karcie) wersja 4.1.1, opublikowana we wrześniu 2026 r., przyjmuje WCAG 2.2, ale nie jest jeszcze prawnym punktem odniesienia; dopóki nie zostanie powołana w Dzienniku Urzędowym UE, obowiązuje v3.2.1 (oparta na WCAG 2.1 AA). Kogo obejmuje akt, wyjaśniamy w artykule o Europejskim akcie w sprawie dostępności.
• Wielka Brytania: wytyczne rządowe (otwiera się w nowej karcie) mówią, że strony i aplikacje sektora publicznego muszą spełniać WCAG 2.2 AA. Dotyczą one podmiotów publicznych, a nie prywatnych firm.
• Stany Zjednoczone: rozporządzenie Departamentu Sprawiedliwości dla władz stanowych i lokalnych opiera się na WCAG 2.1 AA, a terminy jego stosowania przesunięto w kwietniu 2026 r. (otwiera się w nowej karcie) na 26 kwietnia 2027 r. i 26 kwietnia 2028 r. W przypadku firm prywatnych wytyczne Departamentu z 2022 r. (otwiera się w nowej karcie) mówią, że ADA obejmuje ich strony internetowe, ale nie wskazują konkretnej normy technicznej.

A co z WCAG 3?

WCAG 3 to projekt, więc nikt nie może jeszcze być z nim zgodny. W3C opublikowało zaktualizowane wersje robocze we wrześniu 2026 r. i zapowiada, że WCAG 3 raczej nie stanie się ukończonym standardem „jeszcze przez kilka lat”. WCAG 2 nie zostanie wycofane przez kolejne lata po tym terminie, więc to właśnie pod wersję 2.2 warto dziś pracować.

Jak sprawdzić nowe kryteria w 15 minut?

Większość błędów w sześciu nowych kryteriach A i AA wychwycisz w około 15 minut, mając klawiaturę, telefon i własną stronę logowania. To nie zastąpi pełnego audytu ani testów z udziałem osób z niepełnosprawnościami, ale pokaże, od czego zacząć, i da programiście konkretną listę zadań.

1. Przejdź klawiszem Tab przez stronę główną, stronę produktu i proces zamówienia przy wszystkich widocznych banerach. Czy zawsze widzisz fokus? (2.4.11)
2. Wykonaj każde zadanie z suwakiem lub przeciąganiem wyłącznie kliknięciami lub dotknięciami. (2.5.7)
3. Na telefonie wypróbuj każdy przycisk zamykania, numer strony i małą ikonę. (2.5.8)
4. Porównaj, gdzie pojawiają się pomoc i dane kontaktowe na trzech typach stron. (3.2.6)
5. Przejdź przez zakup lub rezerwację i zanotuj każde pytanie, na które odpowiadasz dwa razy. (3.3.7)
6. Zaloguj się za pomocą menedżera haseł, a potem wklej hasło i kod jednorazowy. Czy każda CAPTCHA ma alternatywę? (3.3.8)

Resztę WCAG obejmuje nasz poradnik jak sprawdzić dostępność strony internetowej, z bezpłatnymi narzędziami i testami ręcznymi, a lista kontrolna dostępności strony zamienia najczęstsze błędy w listę zadań. Wszystko, czego nie da się jeszcze naprawić, powinno trafić do deklaracji dostępności.

Uwaga o widżetach, także naszym: żadnego z tych kryteriów nie da się spełnić panelem po stronie odwiedzającego. Duży kursor ułatwia trafianie w małe cele, ale nie sprawia, że mają one 24 piksele szerokości, a podświetlenie fokusu nie odsuwa przyklejonego banera. Każde nowe kryterium dotyczy tego, jak zbudowane są Twoje strony, więc poprawki trzeba wprowadzić w szablonach i kodzie.