WCAG 2.2 vs WCAG 2.1: Co nowego i co musisz zaktualizować

Ponad 96% stron głównych wciąż nie spełnia podstawowych wymagań WCAG, zgodnie z analizą dostępności WebAIM z 2024 roku — i to w odniesieniu do standardu, który już wtedy miał pięć lat. 5 października 2023 r. W3C opublikowało WCAG 2.2 jako oficjalny standard sieciowy, podnosząc poprzeczkę dzięki dziewięciu nowym kryteriom sukcesu i wycofując jedno kryterium, które stało się przestarzałe. Jeśli zarządzasz stroną internetową, tworzysz produkty cyfrowe lub nadzorujesz zgodność, tej aktualizacji nie da się odkładać w nieskończoność. Regulacje w UE, Wielkiej Brytanii i w coraz większej liczbie stanów USA już zmierzają do przyjęcia WCAG 2.2 jako punktu odniesienia.

Krótka historia: od WCAG 2.1 do WCAG 2.2

Web Content Accessibility Guidelines ewoluują w sposób ciągły od czasu wydania WCAG 2.0 w grudniu 2008 r. WCAG 2.1 pojawiło się w czerwcu 2018 r., dodając 17 nowych kryteriów sukcesu ze szczególnym naciskiem na użytkowników mobilnych oraz osoby z ograniczonym widzeniem lub niepełnosprawnościami poznawczymi. Przez pięć lat stanowiło de facto punkt odniesienia dla zgodności z przepisami takimi jak ADA, Section 508 czy unijna Dyrektywa w sprawie dostępności stron internetowych.

WCAG 2.2 dokładnie kontynuuje to, na czym skończyło 2.1. W3C rozpoczęło prace nad nim z wyraźnym celem dalszego ulepszania wytycznych dostępności dla trzech głównych grup: użytkowników z niepełnosprawnościami poznawczymi lub trudnościami w uczeniu się, użytkowników z ograniczonym widzeniem oraz użytkowników z niepełnosprawnościami korzystających z urządzeń mobilnych. Ta ciągłość ma znaczenie, ponieważ oznacza, że aktualizacja ma charakter ewolucyjny, a nie rewolucyjny — ale nadal jest na tyle istotna, że wymaga podjęcia działań z Twojej strony.

Jedną z najważniejszych rzeczy do zrozumienia pod względem strukturalnym jest to, że WCAG 2.2 jest w pełni wstecznie kompatybilne z WCAG 2.1. Spełnienie WCAG 2.2 automatycznie oznacza spełnienie WCAG 2.1 oraz WCAG 2.0. Jeśli Twoja organizacja jest obecnie zgodna z WCAG 2.1 AA, musisz jedynie zająć się nowymi kryteriami wprowadzonymi w 2.2 — nie zaczynasz od zera. W3C zaleca również, że choć WCAG 2.0 i 2.1 pozostają ważnymi rekomendacjami, organizacje powinny stosować WCAG 2.2, aby zmaksymalizować przyszłą przydatność swojej pracy nad dostępnością.

WCAG 2.2 jest też powszechnie postrzegane jako ostatnie wydanie z rodziny WCAG 2.x. Kolejna główna wersja, WCAG 3.0, to zupełnie inna konstrukcja — gruntowne przemyślenie sposobu strukturyzowania wytycznych dostępności. To sprawia, że WCAG 2.2 jest definitywnym punktem końcowym linii rozwojowej sięgającej 2008 roku i tym standardem, który musisz teraz opanować.

Liczby: co faktycznie się zmieniło

Ustalmy precyzyjnie zakres zmian. WCAG 2.1 zawierało 78 kryteriów sukcesu w trzech poziomach zgodności (A, AA i AAA). WCAG 2.2 dodaje dziewięć nowych kryteriów sukcesu, jednocześnie usuwając jedno — kryterium sukcesu 4.1.1 Parsing — pozostawiając łącznie 86 aktywnych kryteriów. Z tych dziewięciu nowych, dwa są na poziomie A, cztery na poziomie AA, a trzy na poziomie AAA.

Dla zdecydowanej większości organizacji dążących do zgodności na poziomie AA — poziomu przywoływanego w większości przepisów i regulacji — praktyczny wpływ oznacza sześć nowych kryteriów do wdrożenia. Trzy dodatki na poziomie AAA są uznawane za najlepszą praktykę i często rekomendowane w kontekstach administracji publicznej i ochrony zdrowia, ale nie stanowią twardego wymogu prawnego w większości jurysdykcji.

Nowe kryteria dotyczą przede wszystkim czterech obszarów problemowych, które w realnych audytach dostępności były wielokrotnie wskazywane jako niedostatecznie obsłużone przez dotychczasowy standard: widoczność fokusu klawiatury, interakcje dotykowe i wskaźnikowe, dostępność poznawcza oraz bariery w uwierzytelnianiu. To nie są teoretyczne kwestie. To bariery, które regularnie uniemożliwiają osobom z niepełnosprawnościami wykonywanie codziennych zadań, takich jak logowanie, wypełnianie formularza czy nawigacja po stronie z przyklejonym nagłówkiem.

Dziewięć nowych kryteriów sukcesu — wyjaśnienie

Poniżej znajduje się omówienie każdego nowego kryterium, tego, czego wymaga i dlaczego ma znaczenie w praktyce. Kryteria są przedstawione według poziomu zgodności, aby ułatwić priorytetyzację prac naprawczych.

Poziom A (minimum — wymagany dla wszystkich)

• 2.4.11 Focus Not Obscured (Minimum): Gdy komponent interfejsu użytkownika otrzymuje fokus klawiatury, nie może być całkowicie zasłonięty przez treści stworzone przez autora. Najczęstszymi winowajcami są tu przyklejone nagłówki, pływające banery cookie oraz widżety czatu na żywo, które nakładają się na stronę. Jeśli użytkownik naciskający Tab trafi na przycisk, który jest całkowicie przykryty przez przyklejony pasek nawigacyjny, kryterium zostaje naruszone. Zwróć uwagę, że częściowe zasłonięcie jest akceptowalne na poziomie A — element po prostu nie może być ukryty w 100%.
• 2.5.7 Dragging Movements: Każda funkcjonalność wymagająca ruchu przeciągania — na przykład przeciągnij‑i‑upuść przy przesyłaniu plików, sortowalne elementy listy czy suwaki — musi być również obsługiwana pojedynczą akcją wskaźnika (taką jak kliknięcie lub stuknięcie) bez przeciągania. Jest to kluczowe dla użytkowników z niepełnosprawnościami ruchowymi, którzy nie są w stanie wiarygodnie wykonywać kontrolowanych gestów przeciągania. Wymóg dotyczy treści stworzonych przez autora; natywne zachowania przeglądarki są wyłączone.

Poziom AA (wymagany dla standardowej zgodności)

• 2.4.12 Focus Not Obscured (Enhanced): Bardziej rygorystyczna wersja 2.4.11. Na poziomie AA żadna część wskaźnika fokusu nie może być zasłonięta przez treści stworzone przez autora, gdy element otrzymuje fokus klawiatury. Zamyka to lukę w wersji na poziomie A i wymaga, aby elementy z fokusem były w pełni widoczne — nie tylko częściowo.
• 2.5.8 Target Size (Minimum): Obszar klikalny lub dotykowy elementów interaktywnych musi mieć co najmniej 24×24 piksele CSS, z określonymi wyjątkami dla linków w tekście ciągłym, elementów kontrolowanych przez user‑agenta oraz przypadków, w których w pobliżu istnieje równoważny cel 24×24. To istotna zmiana względem WCAG 2.1, gdzie rozmiar celu 44×44 piksele był jedynie rekomendowany na poziomie AAA. Teraz minimalny poziom jest egzekwowalny na poziomie AA. Zauważ, że choć 24×24 px to minimum, kryterium AAA (2.5.5) nadal rekomenduje 44×44 px i pozostaje to złotym standardem projektowania przyjaznego dotykowi.
• 3.2.6 Consistent Help: Jeśli strona internetowa udostępnia jakiekolwiek mechanizmy pomocy — dane kontaktowe do człowieka, narzędzia samoobsługowe, zautomatyzowany czat lub formularz kontaktowy — i mechanizmy te pojawiają się na wielu stronach, muszą znajdować się w tym samym względnym położeniu na tych stronach. Użytkownicy potrzebujący pomocy, zwłaszcza osoby z niepełnosprawnościami poznawczymi, powinni zawsze móc znaleźć ją w tym samym miejscu, bez szukania.
• 3.3.7 Redundant Entry: Informacje, które użytkownik wprowadził już na wcześniejszym etapie tego samego procesu, muszą być dla niego albo automatycznie uzupełniane, albo dostępne do wyboru, tak aby nie musiał wpisywać ich ponownie. Pomyśl o wieloetapowych procesach zakupowych, które proszą o adres rozliczeniowy, a następnie ponownie o adres dostawy — użytkownikom należy zaoferować możliwość skopiowania tego, co już wprowadzili. Dopuszczalne są wyjątki, gdy ponowne wprowadzenie informacji jest niezbędne ze względów bezpieczeństwa (np. potwierdzenie hasła) lub gdy wcześniej wprowadzone dane nie są już aktualne.
• 3.3.8 Accessible Authentication (Minimum): Testy funkcji poznawczych — takie jak rozwiązywanie zagadki, zapamiętywanie hasła czy przepisywanie znaków z obrazkowego CAPTCHA — nie mogą być wymagane jako jedyny sposób uwierzytelniania. Musi być dostępna alternatywna metoda lub mechanizm wspierający użytkownika (np. możliwość użycia menedżera haseł lub zezwolenie na kopiowanie‑wklejanie do pola hasła). To kryterium nie zakazuje całkowicie CAPTCHA, ale wymaga, aby nigdy nie były jedyną opcją dla użytkowników, którzy nie są w stanie ich rozwiązać.

Poziom AAA (rozszerzony — zalecany, ale nie obowiązkowy dla większości)

• 2.4.13 Focus Appearance: Gdy wskaźnik fokusu klawiatury jest widoczny, musi spełniać określone minimalne wymagania dotyczące rozmiaru i kontrastu: obszar fokusu musi być co najmniej tak duży jak obwód o grubości 2 pikseli CSS wokół elementu, a stosunek kontrastu między stanem z fokusem i bez fokusu musi wynosić co najmniej 3:1. To kryterium pierwotnie planowano dla poziomu AA, ale przeniesiono je na AAA ze względu na złożoność. Oznacza to, że dla zgodności wyłącznie na poziomie AA nadal nie ma normatywnie zdefiniowanego minimalnego rozmiaru wskaźnika fokusu — wymagane jest jedynie, aby był widoczny.
• 2.5.9 Dragging Movements (Enhanced): Chwila — w tym wydaniu nie ma 2.5.9. Rozszerzenie dotyczące przeciągania na poziomie AAA zostało ujęte w 3.3.9 poniżej.
• 3.3.9 Accessible Authentication (Enhanced): Bardziej rygorystyczna wersja 3.3.8. Na poziomie AAA zabronione są również testy rozpoznawania obiektów i treści osobistych (takie jak „kliknij wszystkie sygnalizatory świetlne” lub „wybierz zdjęcia ze swojego konta”), a nie tylko wyjątki dopuszczone na poziomie AA. Pozostają tylko dwa wyjątki zamiast czterech.

Co zostało usunięte: 4.1.1 Parsing

WCAG 2.2 usuwa jedno kryterium sukcesu obowiązujące od WCAG 2.0: 4.1.1 Parsing. Kryterium to pierwotnie wymagało, aby HTML był poprawnie zbudowany, z kompletnymi znacznikami otwierającymi i zamykającymi, prawidłowym zagnieżdżeniem i bez zduplikowanych atrybutów. Celem było zapewnienie, że przeglądarki i technologie asystujące mogą wiarygodnie przetwarzać kod i poprawnie prezentować treść użytkownikom.

Usunięcie nie budzi kontrowersji — odzwierciedla rzeczywistą zmianę w krajobrazie technicznym. Od 2008 r. przeglądarki stały się wyjątkowo dobre w łagodnym obsługiwaniu niepoprawnego HTML, stosując spójny, znormalizowany algorytm korekcji błędów. Technologie asystujące, takie jak czytniki ekranu, polegają teraz na Document Object Model (DOM) przeglądarki, a nie na surowym kodzie HTML. W3C uznało, że kryterium nie zapewnia już istotnych korzyści w zakresie dostępności w nowoczesnym środowisku. Problemy z dostępnością, które dawniej wychwytywało 4.1.1, są nadal objęte bardziej szczegółowymi kryteriami, takimi jak 1.3.1 (Info and Relationships) i 4.1.2 (Name, Role, Value).

Praktyczne implikacje dla Twojego zespołu: jeśli Twoje narzędzia testów automatycznych zgłaszały naruszenia 4.1.1 Parsing, nie są one już problemem w kontekście WCAG 2.2. Możesz zaobserwować spadek liczby zgłaszanych naruszeń wyłącznie z powodu aktualizacji wersji, a nie dlatego, że cokolwiek zostało naprawione. Niemniej pisanie poprawnego, dobrze ustrukturyzowanego HTML pozostaje silnie rekomendowaną praktyką — po prostu nie jest już samo w sobie wymogiem zgodności.

Konsekwencje regulacyjne i prawne

Zrozumienie nowych kryteriów to jedno. Zrozumienie, co oznaczają dla Twojej ekspozycji prawnej, to drugie. Krótko mówiąc: WCAG 2.2 staje się obowiązującym standardem w wielu jurysdykcjach, a tempo zmian jest szybsze, niż wiele organizacji sobie uświadamia.

W Wielkiej Brytanii podmioty sektora publicznego są już zobowiązane do spełniania WCAG 2.2 na poziomie AA na mocy Public Sector Bodies Accessibility Regulations. W Unii Europejskiej norma EN 301 549 — standard techniczny stanowiący podstawę European Accessibility Act — jest w trakcie przyjmowania WCAG 2.2 jako punktu odniesienia. Sam EAA ma termin egzekwowania w czerwcu 2025 r. dla większości organizacji prywatnych oferujących produkty i usługi w UE. Kilka stanów USA, w tym Kolorado, wyraziło również zamiar zaktualizowania swoich stanowych przepisów dotyczących dostępności z WCAG 2.1 do WCAG 2.2.

W Stanach Zjednoczonych ADA Title II obecnie odwołuje się do WCAG 2.1 AA jako standardu technicznego dla stron internetowych władz stanowych i lokalnych. Jednak sądy w USA coraz częściej przywołują WCAG 2.2 w sprawach dotyczących dostępności, a kierunek jest jasny. Czekanie na formalny federalny nakaz przed podjęciem działań to strategia zgodności, która wiąże się z rosnącym ryzykiem prawnym, szczególnie dla organizacji z branży e‑commerce, usług finansowych i ochrony zdrowia, które są atrakcyjnymi celami pozwów dotyczących dostępności.

Nawet jeśli Twoja organizacja nie jest jeszcze prawnie zobowiązana do spełniania WCAG 2.2, spełnienie nowych kryteriów sukcesu raczej wcześniej niż później zapewni Ci wyprzedzenie wobec zmieniających się regulacji — a co ważniejsze, wyprzedzenie rzeczywistych barier dostępności, z którymi mierzą się dziś Twoi użytkownicy.

Jak przeprowadzić audyt i zaktualizować swoją stronę

Jeśli jesteś już zgodny z WCAG 2.1 AA, ścieżka aktualizacji do WCAG 2.2 jest do opanowania. Oto praktyczne ramy podejścia do tego procesu.

Zacznij od ukierunkowanego audytu sześciu nowych kryteriów poziomu AA. To właśnie one mają znaczenie prawne dla większości organizacji. Skup się szczególnie na 2.4.11 i 2.4.12 (focus obscured), 2.5.8 (target size), 3.2.6 (consistent help), 3.3.7 (redundant entry) oraz 3.3.8 (accessible authentication). Doświadczony inżynier ds. dostępności może zazwyczaj ręcznie przeaudytować te kryteria w ciągu kilku godzin dla strony o umiarkowanej złożoności.

Najpierw przeaudytuj swoje elementy przyklejone/pozycjonowane na stałe. Kryteria dotyczące zasłoniętego fokusu (2.4.11 i 2.4.12) są naruszane przez jedne z najczęstszych wzorców UI w sieci — przyklejone nagłówki, pływające przyciski akcji, paski zgody na cookies i widżety czatu. Przejdź przez całą stronę, używając wyłącznie klawisza Tab, i obserwuj, czy jakikolwiek element z fokusem kiedykolwiek znika pod stałą warstwą. Poprawka w CSS jest zazwyczaj prosta:

/* Zapobiegaj zasłanianiu elementów z fokusem przez przyklejony nagłówek */
:focus {
  scroll-margin-top: 80px; /* dopasuj do wysokości przyklejonego nagłówka */
}

Przeaudytuj rozmiar celu dotykowego każdego elementu interaktywnego. To często szybkie zwycięstwo zarówno pod kątem zgodności, jak i doświadczenia użytkownika. Przyciski, linki, kontrolki formularzy i ikony muszą mieć minimum 24×24 piksele CSS. Wiele systemów projektowych już przekracza ten próg, ale małe przyciski ikon — ikony zamykania, przyciski udostępniania w mediach społecznościowych i linki akcji w tekście — często stanowią problem. Sprawdź swoje komponenty i dodaj padding lub dostosuj wymiary tam, gdzie to konieczne.

Dokładnie przeanalizuj swoje przepływy uwierzytelniania. SC 3.3.8 (Accessible Authentication) ma realną „siłę rażenia”. Jeśli używasz CAPTCHA, którego nie można ominąć lub rozwiązać inną metodą, prawdopodobnie nie jesteś zgodny. Oceń, czy Twoje procesy logowania, rejestracji i uwierzytelniania dwuskładnikowego pozwalają menedżerom haseł na autouzupełnianie, umożliwiają kopiowanie‑wklejanie, oferują alternatywną metodę weryfikacji (np. magic link lub jednorazowy kod) lub zapewniają inne udogodnienia dla użytkowników, którzy nie mogą wykonać zadania poznawczego.

Przeaudytuj wieloetapowe formularze pod kątem redundantnego wprowadzania danych. Zmapuj wszystkie procesy składające się z wielu kroków — zakupy, onboarding, wnioski — i zidentyfikuj każde miejsce, w którym użytkownik proszony jest o podanie informacji, które już wcześniej przekazał. Dodaj logikę automatycznego uzupełniania lub przełącznik „tak jak powyżej”, gdzie to możliwe. Zazwyczaj jest to zmiana po stronie back‑endu lub zarządzania stanem formularza, a nie złożona przebudowa architektury.

Zweryfikuj, że mechanizmy pomocy są rozmieszczone w sposób spójny. Jeśli masz widżet czatu, link do pomocy lub numer telefonu pojawiający się w stopce lub pasku bocznym na wielu stronach, sprawdź, czy jego względne położenie się nie zmienia. Zwykle jest to kwestia szablonu lub układu, a nie problem każdej strony z osobna — napraw to w bibliotece komponentów lub szablonie CMS, a zmiana rozpropaguje się wszędzie.

Używaj narzędzi automatycznych do wstępnego wykrywania, ale na tym nie poprzestawaj. Automatyczne skanery potrafią wykryć około 40% problemów WCAG 2.2 — są przydatne do wychwytywania naruszeń rozmiaru celu i oczywistych problemów z zarządzaniem fokusem, ale nie są w stanie ocenić, czy CAPTCHA jest jedyną opcją uwierzytelniania ani czy mechanizm pomocy jest rozmieszczony spójnie. Testy manualne, w tym nawigacja wyłącznie klawiaturą i testy z użyciem czytników ekranu, pozostają niezbędne. Testy z udziałem rzeczywistych użytkowników z niepełnosprawnościami ujawnią problemy, których żadne narzędzie automatyczne nigdy nie wykryje.

WCAG 2.2 a widżety nakładkowe: co warto wiedzieć

Widżety i SDK nakładek dostępności — narzędzia takie jak Accsible — mogą realnie pomóc w wykrywaniu i naprawianiu niektórych kategorii problemów z dostępnością, szczególnie dla użytkowników potrzebujących dostosowań w czasie rzeczywistym, takich jak zwiększenie rozmiaru czcionki, zmiana kontrastu czy ulepszenia nawigacji klawiaturą. Warto jednak trzeźwo ocenić, co nakładki mogą, a czego nie mogą zrobić w kontekście zgodności z WCAG 2.2.

Nakładki mogą pomóc w rozwiązaniu niektórych problemów z widocznością fokusu, zapewnić alternatywne tryby nawigacji i zaoferować dostosowanie po stronie użytkownika, które kompensuje pewne braki na poziomie projektu. Stanowią użyteczną warstwę stosu dostępności, zwłaszcza dla zespołów, które muszą szybko poprawić doświadczenie użytkownika, podczas gdy trwają długoterminowe prace naprawcze. Nie zastępują jednak naprawy kodu u podstaw. Nowe kryteria WCAG 2.2 — szczególnie dotyczące uwierzytelniania (3.3.8), redundantnego wprowadzania danych (3.3.7) i ruchów przeciągania (2.5.7) — wymagają zmian strukturalnych w sposobie budowy aplikacji, a nie tylko w sposobie jej prezentacji.

Najskuteczniejsze podejście łączy dobrze wdrożoną nakładkę zapewniającą elastyczność po stronie użytkownika z właściwymi poprawkami w kodzie dla nowych kryteriów 2.2. Traktuj SDK nakładki jako mnożnik siły: rozszerza Twój zasięg, poprawia doświadczenie większej liczby użytkowników i wypełnia luki — ale fundament nadal musi być solidny.

Kluczowe wnioski

• WCAG 2.2 dodaje dziewięć nowych kryteriów sukcesu i usuwa jedną przestarzałą regułę (4.1.1 Parsing). Jest w pełni wstecznie kompatybilne z 2.1, więc Twoja dotychczasowa praca nad zgodnością nie idzie na marne — musisz jedynie dołożyć to, co nowe.
• Dla zgodności na poziomie AA skup się na sześciu konkretnych nowych kryteriach: Focus Not Obscured (2.4.11 i 2.4.12), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7) oraz Accessible Authentication (3.3.8). To one są prawnie istotne dla większości organizacji.
• Tempo przyjmowania regulacyjnego przyspiesza. Sektor publiczny w Wielkiej Brytanii już egzekwuje WCAG 2.2, UE przechodzi na ten standard w ramach European Accessibility Act, a sądy w USA coraz częściej się do niego odwołują. Nie czekaj na formalny nakaz w swojej jurysdykcji, zanim podejmiesz działania.
• Narzędzia automatyczne wykrywają tylko około 40% problemów WCAG 2.2 — testy manualne, przejścia po stronie z użyciem wyłącznie klawiatury oraz testy z udziałem rzeczywistych użytkowników są niezbędne do osiągnięcia rzeczywistej zgodności, zwłaszcza w odniesieniu do nowych kryteriów dotyczących uwierzytelniania i dostępności poznawczej.
• Najczęstsze szybkie wygrane to naprawa przyklejonych nagłówków zasłaniających elementy z fokusem, powiększenie małych celów dotykowych oraz audyt przepływów logowania/uwierzytelniania pod kątem zależności od CAPTCHA. Zmiany te często wymagają niewielkiego nakładu pracy, a mają duży wpływ — to dobre miejsce na rozpoczęcie sprintu naprawczego WCAG 2.2.