WCAG 2.2 – co nowego i co zmienić na stronie

WCAG 2.2 to wersja wytycznych dostępności treści internetowych (WCAG), która rozszerza WCAG 2.1. Dodaje 9 nowych kryteriów sukcesu, usuwa jedno przestarzałe i zajmuje się problemami, które wcześniejsze wersje pomijały: zasłoniętym fokusem, zbyt małymi przyciskami, przeciąganiem, ponownym wpisywaniem danych i trudnym logowaniem.

Poniżej omawiamy każde nowe kryterium z przykładem, co zmienić na stronie, i podpowiadamy, czy celować w WCAG 2.1, czy od razu w 2.2.

Kiedy opublikowano WCAG 2.2 i co się nie zmieniło

W3C opublikowało WCAG 2.2 jako rekomendację 5 października 2023 r. Pełny tekst znajdziesz w specyfikacji WCAG 2.2 na stronie W3C. To nie jest nowy standard – struktura pozostała taka sama jak w wersjach 2.0 i 2.1.

Nadal obowiązują cztery zasady: postrzegalność, funkcjonalność, zrozumiałość i solidność, oraz trzy poziomy zgodności: A, AA i AAA. W praktyce, czyli w przepisach i normach, wymaga się poziomu AA – spełnienia wszystkich kryteriów z poziomów A i AA.

Dziewięć nowych kryteriów w skrócie

Sześć nowości to poziom A lub AA, więc dotyczą każdego, kto celuje w standardowy poziom zgodności. Trzy pozostałe to AAA.

Kryteria A i AA: co zmienić na stronie

2.4.11 Focus Not Obscured (Minimum) – fokus niezasłonięty (AA)

Element, który otrzymał fokus klawiatury, nie może być całkowicie przykryty przez treść dodaną przez autora strony. Typowi winowajcy to przyklejony nagłówek, pasek z informacją o cookies, okno czatu i wyskakujące banery. Użytkownik naciska Tab i nie widzi, gdzie jest.

Prostą poprawką, opisaną też w technikach W3C, jest zarezerwowanie miejsca na elementy przyklejone przy przewijaniu:

html {
  scroll-padding-top: 5rem;    /* wysokość przyklejonego nagłówka */
  scroll-padding-bottom: 4rem; /* wysokość dolnego paska */
}

2.5.7 Dragging Movements – ruchy przeciągania (AA)

Każda funkcja obsługiwana przeciąganiem musi być dostępna także przez pojedyncze kliknięcie lub dotknięcie, chyba że przeciąganie jest niezbędne. To ważne dla osób, które nie są w stanie precyzyjnie przytrzymać i przesunąć wskaźnika.

Lista sortowana metodą „przeciągnij i upuść” potrzebuje przycisków „w górę” i „w dół” albo menu „Przenieś do…”. Suwak ceny w filtrach sklepu powinien reagować na kliknięcie ścieżki lub mieć pola do wpisania kwot, a mapa – przyciski przesuwania. Obsługa klawiaturą to osobne wymaganie (2.1.1 Keyboard – klawiatura), a 2.5.7 dotyczy wskaźnika.

2.5.8 Target Size (Minimum) – minimalny rozmiar celu (AA)

Cel, czyli obszar reagujący na kliknięcie lub dotyk, musi mieć co najmniej 24×24 piksele CSS. Mniejszy element jest w porządku, jeśli ma wystarczający odstęp: okrąg o średnicy 24 pikseli CSS wyśrodkowany na nim nie może nachodzić na inny cel ani na okrąg innego małego celu. Wyjątki obejmują m.in. linki w treści akapitu, domyślne kontrolki przeglądarki, których wyglądu nie zmieniano, oraz sytuacje, gdy ta sama funkcja jest dostępna przez inny, wystarczająco duży element.

Najczęściej poprawisz ikonę zamykania okna, ikony mediów społecznościowych, kropki karuzeli, paginację i przyciski „+/−” przy ilości produktu. Ikona może zostać mała – wystarczy powiększyć obszar klikalny:

.przycisk-ikona {
  display: inline-flex;
  min-width: 24px;
  min-height: 24px;
}

3.2.6 Consistent Help – spójna pomoc (A)

Jeśli na wielu podstronach oferujesz pomoc – dane kontaktowe, formularz, czat, link do FAQ – umieszczaj ją w tej samej kolejności względem reszty treści. Kryterium nie wymaga dodawania pomocy, tylko tego, żeby istniejąca pomoc nie zmieniała miejsca.

Przykład błędu: link „Pomoc” jest w nagłówku każdej podstrony, ale w procesie zamówienia przenosi się do stopki. Osoba, która nauczyła się, gdzie szukać wsparcia, nagle go nie znajduje.

3.3.7 Redundant Entry – ponowne wprowadzanie danych (A)

Informacji, którą użytkownik podał już w tym samym procesie, nie wolno kazać wpisywać drugi raz. Trzeba ją uzupełnić automatycznie albo dać do wybrania. Wyjątki: gdy ponowne wpisanie jest niezbędne, wymagane ze względów bezpieczeństwa albo wcześniejsze dane przestały być aktualne.

Klasyczny przykład to zamówienie w sklepie: zamiast drugiego kompletu pól na adres do faktury dodaj pole wyboru „Adres do faktury taki sam jak adres dostawy”.

3.3.8 Accessible Authentication (Minimum) – dostępne uwierzytelnianie (AA)

Żaden krok logowania nie może wymagać testu funkcji poznawczych – zapamiętania hasła, przepisania kodu, rozwiązania zagadki – chyba że istnieje alternatywna metoda albo mechanizm, który pomaga go przejść, np. obsługa menedżera haseł i wklejania. Na poziomie AA dopuszczalne są też testy polegające na rozpoznawaniu obiektów (np. „wskaż zdjęcia z rowerem”) lub treści dodanych wcześniej przez samego użytkownika.

W praktyce: nie blokuj wklejania w polach hasła i kodu jednorazowego, stosuj właściwe wartości atrybutu autocomplete, a gdy kod jest podzielony na kilka pól, obsłuż wklejenie całości. Warto też dać alternatywę, np. logowanie linkiem wysłanym e-mailem lub kluczem dostępu (passkey).

<!-- Źle: blokada wklejania -->
<input type="password" id="haslo" onpaste="return false">

<!-- Dobrze: działa menedżer haseł i wklejanie -->
<label for="haslo">Hasło</label>
<input type="password" id="haslo" autocomplete="current-password">

<label for="kod">Kod z SMS-a</label>
<input id="kod" inputmode="numeric" autocomplete="one-time-code">

Nowe kryteria na poziomie AAA

Poziomu AAA zwykle się nie wymaga, ale te trzy kryteria pokazują, dokąd zmierzają dobre praktyki:

• 2.4.12 Focus Not Obscured (Enhanced) – fokus niezasłonięty, wersja rozszerzona: element z fokusem nie może być zasłonięty nawet częściowo.
• 2.4.13 Focus Appearance – wygląd fokusu: wskaźnik fokusu musi mieć co najmniej taką powierzchnię jak obramowanie elementu o grubości 2 pikseli CSS i kontrast co najmniej 3:1 między stanem z fokusem i bez niego.
• 3.3.9 Accessible Authentication (Enhanced) – dostępne uwierzytelnianie, wersja rozszerzona: jak 3.3.8, ale bez wyjątków dla rozpoznawania obiektów i treści użytkownika.

Na poziomie AA wskaźnik fokusu i tak podlega kryterium 1.4.11 Non-text Contrast – kontrast elementów nietekstowych (co najmniej 3:1). Szczegóły znajdziesz w artykule o kontraście kolorów WCAG.

Usunięte kryterium 4.1.1 Parsing

W WCAG 2.2 kryterium 4.1.1 Parsing – parsowanie (poziom A) oznaczono jako przestarzałe i usunięto. Wymagało m.in. poprawnego zagnieżdżania znaczników, braku zduplikowanych atrybutów i unikalnych identyfikatorów. Technologie asystujące nie analizują już samodzielnie kodu HTML, lecz korzystają z danych od przeglądarki, a realne problemy użytkowników obejmują inne kryteria.

Nie znaczy to, że błędy w kodzie przestały mieć znaczenie. Zduplikowany id, na który wskazuje <label for> albo aria-labelledby, nadal może odebrać polu nazwę – tylko ocenia się to w ramach kryteriów 1.3.1 Info and Relationships – informacje i relacje lub 4.1.2 Name, Role, Value – nazwa, rola, wartość.

WCAG 2.1 czy WCAG 2.2? Zgodność wsteczna, normy i prawo

WCAG 2.2 jest zgodne wstecz. Strona spełniająca WCAG 2.2 co do zasady spełnia też WCAG 2.1 i 2.0 – wyjątkiem jest tylko usunięte kryterium 4.1.1.

Od 28 czerwca 2025 r. stosuje się przepisy wdrażające Europejski Akt o Dostępności (w Polsce ustawa z dnia 26 kwietnia 2024 r., Dz.U. 2024 poz. 731). Technicznym punktem odniesienia jest zharmonizowana norma EN 301 549, której wersja 3.2.1 odwołuje się do WCAG 2.1 na poziomie AA. Kogo dotyczą przepisy, wyjaśniamy w artykule o Europejskim Akcie o Dostępności.

W praktyce punktem wyjścia jest więc WCAG 2.1 AA, ale rozsądniej od razu celować w WCAG 2.2 AA. Spełniasz wtedy oba zestawy wymagań, a nowe kryteria dotyczą rzeczy, które realnie przeszkadzają użytkownikom: logowania, formularzy i obsługi na ekranach dotykowych. Ta część artykułu ma charakter informacyjny i nie jest poradą prawną.

Od czego zacząć wdrożenie

1. Uporządkuj podstawy. WCAG 2.2 obejmuje wszystko, co było w 2.1, więc zacznij od typowych błędów: kontrastu, tekstów alternatywnych, etykiet pól i nazw przycisków. Szybkim punktem startu jest bezpłatny skan wstępny na stronie głównej, a szerszy obraz da automatyczny test WCAG wielu podstron.
2. Przejdź stronę klawiaturą i sprawdź, czy fokus nie chowa się pod przyklejonymi elementami. Pomoże Ci poradnik jak sprawdzić stronę pod kątem WCAG.
3. Zmierz małe elementy klikalne w szablonie i bibliotece komponentów.
4. Wypisz interakcje oparte na przeciąganiu – suwaki, sortowanie, mapy – i dodaj alternatywę.
5. Przejrzyj formularze wieloetapowe pod kątem danych wpisywanych dwa razy.
6. Przetestuj logowanie i rejestrację: wklejanie, menedżer haseł, CAPTCHA, kody jednorazowe.
7. Ustal stałe miejsce pomocy w szablonach i zapisz cel „WCAG 2.2 AA” w wymaganiach dla projektantów i wykonawców.

Większość nowych kryteriów wymaga oceny człowieka: automat nie stwierdzi, czy pomoc jest w stałym miejscu ani czy logowanie obejdzie się bez przepisywania kodu. Przy większych serwisach połącz więc test automatyczny z audytem WCAG wykonanym przez eksperta.

Najczęstsze pytania

Czy WCAG 2.1 przestało obowiązywać po publikacji WCAG 2.2?

Nie. WCAG 2.0 i 2.1 pozostają rekomendacjami W3C, ale W3C zaleca korzystanie z najnowszej wersji przy tworzeniu i aktualizacji stron. Ponieważ WCAG 2.2 jest zgodne wstecz, wdrażając je, spełniasz też wymagania WCAG 2.1.

Czy WCAG 2.2 zmienia progi kontrastu?

Nie. Wymagania dla tekstu (4,5:1, a dla dużego tekstu 3:1) i dla elementów nietekstowych (3:1) są takie same jak w WCAG 2.1. Nowe jest kryterium AAA 2.4.13 Focus Appearance, które dotyczy wyglądu wskaźnika fokusu.

Czy trzeba spełniać kryteria AAA z WCAG 2.2?

Zwykle nie. Przepisy i normy odwołują się do poziomu AA, a samo W3C nie zaleca wymagania poziomu AAA dla całych serwisów, bo nie dla każdej treści da się go osiągnąć. Kryteria AAA warto wdrażać tam, gdzie to możliwe.

Czy raport z testu automatycznego potwierdzi zgodność z WCAG 2.2?

Nie. Test automatyczny wykrywa tylko część problemów, a kryteria takie jak spójna pomoc czy dostępne logowanie wymagają oceny człowieka. Raport automatyczny pomaga znaleźć błędy, ale nie jest certyfikatem ani potwierdzeniem zgodności.