Przejdź do treści

UX/UI/AX

WCAG 2.2 – co się zmieniło względem 2.1 i od kiedy obowiązuje w Polsce?

Jerzy Koenigshaus Opublikowano 9 min czytania

W skrócie: WCAG 2.2 to wersja wytycznych dostępności W3C z 5 października 2023 r. Względem WCAG 2.1 dodaje 9 kryteriów sukcesu, z czego 6 na poziomach A i AA, oraz usuwa kryterium 4.1.1 Parsowanie. Nowe kryteria dotyczą fokusu zasłanianego przez przyklejone elementy, alternatywy dla przeciągania, rozmiaru klikalnych elementów (co najmniej 24 × 24 px), stałego miejsca pomocy, ponownego wpisywania danych i logowania bez zadań pamięciowych. Polskie przepisy wciąż opierają się na WCAG 2.1. Norma EN 301 549 V4.1.1, której wymagania opierają się na WCAG 2.2, ukazała się we wrześniu 2026 r. i stanie się prawnym punktem odniesienia po przywołaniu w Dzienniku Urzędowym UE.

Spis treści
  1. 01Krótka odpowiedź
  2. 02Co nowego w WCAG 2.2? 9 kryteriów w skrócie
  3. 03Jak spełnić 6 nowych kryteriów z poziomów A i AA?
  4. 04Co usunięto: kryterium 4.1.1 Parsowanie
  5. 05Od kiedy WCAG 2.2 obowiązuje w Polsce?
  6. 06Od czego zacząć? Checklista przejścia z WCAG 2.1 na 2.2

Krótka odpowiedź

WCAG 2.2 to aktualna wersja międzynarodowych wytycznych dostępności treści internetowych. W3C opublikowało ją 5 października 2023 r., a w 2025 r. zatwierdzono ją także jako normę ISO/IEC 40500:2025. Względem WCAG 2.1 wersja 2.2 dodaje 9 kryteriów sukcesu i usuwa jedno, 4.1.1 Parsowanie. Na poziomach A i AA, do których odwołują się przepisy, doszło 6 kryteriów, a jedno ubyło, więc do spełnienia jest 55 kryteriów zamiast 50.

W Polsce przepisy wciąż opierają się na WCAG 2.1. Ustawa o dostępności cyfrowej podmiotów publicznych ma w załączniku listę kryteriów WCAG 2.1, a dla firm objętych Europejskim Aktem o Dostępności Ministerstwo Cyfryzacji wskazuje normę EN 301 549 V3.2.1, zbudowaną na WCAG 2.1 AA. Zmiana nastąpi wraz z normą EN 301 549 V4.1.1 z września 2026 r., której wymagania opierają się na WCAG 2.2. Prawnie wiążąca stanie się po przywołaniu w Dzienniku Urzędowym UE, a tej daty na razie nie ogłoszono. Zgodność z WCAG 2.2 oznacza jednocześnie zgodność z 2.1, dlatego nowy serwis lub sklep warto od razu projektować według nowszej wersji.

Co nowego w WCAG 2.2? 9 kryteriów w skrócie

Nowe kryteria dotyczą obsługi klawiaturą, obsługi myszą i dotykiem oraz formularzy z logowaniem. Pełna lista z poziomami zgodności:

  • 2.4.11 Fokus niezasłonięty (minimum), poziom AA: element aktywny przy nawigacji klawiaturą nie może zniknąć w całości pod przyklejonym nagłówkiem, banerem ani oknem czatu.
  • 2.4.12 Fokus niezasłonięty (rozszerzone), poziom AAA: element z fokusem nie może być zasłonięty nawet częściowo.
  • 2.4.13 Wygląd fokusu, poziom AAA: wskaźnik fokusu ma co najmniej powierzchnię obrysu elementu o grubości 2 px i kontrast 3:1 między stanem z fokusem i bez niego.
  • 2.5.7 Ruchy przeciągania, poziom AA: wszystko, co da się zrobić przeciąganiem, da się też zrobić pojedynczym kliknięciem lub dotknięciem.
  • 2.5.8 Rozmiar celu (minimum), poziom AA: klikalne elementy mają co najmniej 24 × 24 piksele CSS albo wystarczający odstęp od sąsiednich.
  • 3.2.6 Spójna pomoc, poziom A: pomoc powtarzana na wielu stronach (telefon, formularz, czat, FAQ) jest zawsze w tym samym miejscu względem reszty treści.
  • 3.3.7 Zbędne ponowne wprowadzanie, poziom A: dane podane wcześniej w tym samym procesie wypełniają się same albo można je wybrać z listy.
  • 3.3.8 Dostępne uwierzytelnianie (minimum), poziom AA: logowanie nie wymaga zadań pamięciowych, takich jak przepisywanie kodu, jeśli nie ma ułatwienia lub alternatywy.
  • 3.3.9 Dostępne uwierzytelnianie (rozszerzone), poziom AAA: jak 3.3.8, ale bez wyjątków dla rozpoznawania obiektów i treści dodanych wcześniej przez użytkownika.

Polskie nazwy kryteriów podajemy opisowo, bo WCAG 2.2 nie ma jeszcze autoryzowanego tłumaczenia na polski. Takie tłumaczenie ma WCAG 2.1, z kwietnia 2021 r.

Jak spełnić 6 nowych kryteriów z poziomów A i AA?

Kryteria z poziomów A i AA sprawdza każdy audyt zgodności, dlatego od nich warto zacząć. Poniżej opisujemy każde z nich na przykładach ze stron, sklepów i aplikacji.

Fokus niezasłonięty przez przyklejone elementy (2.4.11)

Osoba, która przechodzi po stronie klawiszem Tab, musi widzieć, gdzie jest. Według kryterium 2.4.11 element z fokusem nie może zostać całkowicie zasłonięty przez treści dodane przez autora strony. Najczęstszy problem to przyklejony nagłówek: przeglądarka przewija stronę do kolejnego linku, a ten znajduje się wtedy pod belką nawigacji. Ten sam problem powodują przyklejona stopka, baner cookies przy dolnej krawędzi ekranu i okno czatu.

W kodzie zwykle wystarczy właściwość CSS scroll-padding-top o wysokości nagłówka: przeglądarka zatrzymuje wtedy przewijanie poniżej belki. Baner cookies zaprojektowany jako okno modalne, które trzyma fokus do czasu wyboru, kryterium spełnia. Częściowe zasłonięcie mieści się w poziomie AA, a pełną widoczność fokusu wymaga dopiero kryterium 2.4.12 z poziomu AAA.

Alternatywa dla przeciągania (2.5.7)

Każdą operację wykonywaną przeciąganiem musi dać się wykonać pojedynczym kliknięciem lub dotknięciem. Przeciąganie sprawia trudność osobom z drżeniem rąk oraz tym, które sterują kursorem wzrokiem albo ruchem głowy. W sklepie typowym przykładem jest suwak zakresu cen w filtrach: wystarczy dodać obok niego pola „od" i „do". W aplikacjach dochodzą listy i tablice zadań sortowane przeciąganiem kart, które uzupełnia się menu „przenieś do" albo przyciskami „w górę" i „w dół". Do mapy przesuwanej palcem dodaje się przyciski przesuwania widoku.

Sama obsługa klawiaturą tego kryterium nie spełnia, bo dotyczy ono osób, które korzystają z myszy, rysika lub ekranu dotykowego. Wyjątki obejmują sytuacje, w których przeciąganie jest niezbędne, oraz funkcje przeglądarki, których autor strony nie zmieniał.

Klikalne elementy co najmniej 24 × 24 px (2.5.8)

Klikalny element, w wytycznych nazywany celem, musi mieć co najmniej 24 × 24 piksele CSS. Mniejszy element spełnia wymóg, jeśli ma wokół siebie wolne miejsce: okrąg o średnicy 24 px, wyśrodkowany na elemencie, nie może nachodzić na inny cel ani na okrąg sąsiedniego małego celu. Wyjątki obejmują linki w tekście ciągłym, elementy, które mają na tej samej stronie większy odpowiednik, kontrolki przeglądarki, których wyglądu autor nie zmieniał, oraz sytuacje, w których dany wygląd jest niezbędny lub wymagany przepisami, np. pinezki na mapie.

Typowe elementy do poprawy to ikona „×" zamykająca okno lub baner, przyciski „+" i „−" przy ilości produktu w koszyku, ikony mediów społecznościowych w stopce oraz numery stron w paginacji. W WCAG 2.1 rozmiar celu opisywało tylko kryterium 2.5.5 z poziomu AAA (44 × 44 px), więc na poziomie AA ten wymóg dotąd nie istniał.

Pomoc zawsze w tym samym miejscu (3.2.6)

Jeśli na wielu stronach serwisu powtarza się pomoc, musi występować w tej samej kolejności względem reszty treści. Pomocą w rozumieniu kryterium są dane kontaktowe (telefon, e-mail, godziny pracy), formularz kontaktowy albo czat z człowiekiem, strona z odpowiedziami na pytania oraz chatbot. Kryterium nie nakazuje dodawania pomocy tam, gdzie jej nie ma. Chodzi o przewidywalność: kto raz znalazł telefon w stopce, nie powinien szukać go na kolejnej podstronie w nagłówku. Problem dotyczy zwłaszcza serwisów, w których podstrony kampanii albo sklep mają osobne szablony.

Bez ponownego wpisywania tych samych danych (3.3.7)

Informacje podane wcześniej w tym samym procesie muszą uzupełniać się automatycznie albo być dostępne do wyboru. Klasyczny przykład to zamówienie w sklepie: pole wyboru „dane do faktury takie same jak adres dostawy" spełnia wymóg jednym kliknięciem. W rezerwacji biletów grupowych e-mail opiekuna grupy podany w pierwszym kroku nie powinien być wymagany ponownie przy płatności. Jak zaprojektować taką ścieżkę, opisujemy w artykule o sprzedaży biletów online dla muzeum.

Wyjątki obejmują sytuacje, w których ponowne wpisanie jest niezbędne (np. w grze pamięciowej), służy bezpieczeństwu, jak potwierdzenie nowego hasła, albo wcześniejsze dane straciły ważność. Kryterium dotyczy jednego procesu, więc nie wymaga zapamiętywania danych między wizytami.

Logowanie bez zadań pamięciowych (3.3.8)

Kryterium 3.3.8 dotyczy każdego ekranu logowania. Żaden krok uwierzytelniania nie może wymagać testu funkcji poznawczych, czyli zapamiętania, przekształcenia albo przepisania informacji, chyba że ten krok oferuje ułatwienie lub alternatywę. Testem nie jest podanie imienia, adresu e-mail ani numeru telefonu. W praktyce kryterium sprowadza się do czterech zasad:

  • pole hasła i pole kodu jednorazowego przyjmują wklejanie oraz autouzupełnianie z menedżera haseł (atrybuty autocomplete="current-password" i autocomplete="one-time-code");
  • kod z SMS-a lub e-maila da się wkleić, bo wymóg ręcznego przepisania kodu nie spełnia kryterium;
  • do CAPTCHA z przepisywaniem zniekształconych znaków trzeba dodać alternatywę, a zadanie typu „zaznacz zdjęcia z rowerem" jest dopuszczalne na poziomie AA jako rozpoznawanie obiektów;
  • alternatywą dla hasła może być link logujący wysłany e-mailem, klucz dostępu (passkey) albo logowanie kontem Google lub Apple.

Osobna sprawa to hasło maskowane, spotykane m.in. w bankowości internetowej. Prośba o wpisanie 1., 3. i 5. znaku hasła uniemożliwia wklejenie całego hasła z menedżera, dlatego według objaśnień W3C taki krok nie spełnia kryterium, jeśli nie ma innej metody logowania.

Co usunięto: kryterium 4.1.1 Parsowanie

WCAG 2.2 usuwa kryterium 4.1.1 Parsowanie, które wymagało poprawnej składni kodu HTML, m.in. unikalnych identyfikatorów i poprawnie zagnieżdżonych znaczników. Czytniki ekranu nie analizują już samodzielnie kodu HTML, tylko korzystają z danych przygotowanych przez przeglądarkę. Problemy, którym kryterium zapobiegało, zniknęły więc albo są objęte innymi kryteriami. W3C dopisało też do WCAG 2.1 uwagę, że dla treści w HTML kryterium 4.1.1 uznaje się za zawsze spełnione.

Błędy w kodzie nadal mogą utrudniać korzystanie ze strony. Zdublowany identyfikator, który psuje powiązanie etykiety z polem formularza, audyt wykaże w kryteriach 1.3.1 albo 4.1.2.

Od kiedy WCAG 2.2 obowiązuje w Polsce?

Formalnie jeszcze nie obowiązuje. Polskie przepisy opierają się dziś na WCAG 2.1 na poziomie AA, a WCAG 2.2 stanie się punktem odniesienia prawnego po przywołaniu nowej normy EN 301 549 w Dzienniku Urzędowym UE. Stan na wrzesień 2026 r.:

  • Podmioty publiczne: ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych wymienia w załączniku kryteria WCAG 2.1 (49 kryteriów z poziomów A i AA, bo ustawa nie obejmuje multimediów na żywo) oraz odwołuje się do normy EN 301 549 V3.2.1. Lista kryteriów jest częścią samej ustawy, więc przejście na WCAG 2.2 wymaga jej nowelizacji. W wykazie prac legislacyjnych Ministerstwa Cyfryzacji nie znaleźliśmy takiego projektu.
  • Firmy objęte Europejskim Aktem o Dostępności: polska ustawa z 26 kwietnia 2024 r. nie podaje wersji WCAG. Zgodność z wymaganiami domniemywa się, gdy usługa spełnia normy zharmonizowane, a Ministerstwo Cyfryzacji wskazuje jako obowiązującą normę EN 301 549 V3.2.1 z 2021 r. Gdy Komisja Europejska przywoła wersję V4.1.1 w Dzienniku Urzędowym UE, punktem odniesienia dla firm stanie się WCAG 2.2, bez zmiany polskiej ustawy.
  • Norma EN 301 549: w wersji V4.1.1, przyjętej 24 sierpnia 2026 r. i opublikowanej we wrześniu 2026 r., wymagania dla stron, dokumentów i oprogramowania opierają się na WCAG 2.2 zamiast na WCAG 2.1. Oficjalnej daty przywołania w Dzienniku Urzędowym UE nie podano. Krajowe wydania normy mają ukazać się do 31 maja 2027 r.
  • Projekty z funduszy UE: standardy dostępności dla polityki spójności 2021–2027 wymagają WCAG 2.1 na poziomie AA. Projekt zmian wytycznych ze stycznia 2026 r. tego wymogu nie zmienia.
  • Norma ISO: od 2025 r. WCAG 2.2 jest też normą międzynarodową ISO/IEC 40500:2025.

Jeśli budujesz nowy serwis, projektuj go według WCAG 2.2 AA. Spełnisz wymagania WCAG 2.1, które obowiązują dziś, i nie wrócisz do poprawek, gdy nowa norma zacznie obowiązywać. Jeśli masz serwis zgodny z WCAG 2.1, zaplanuj przegląd 6 nowych kryteriów przy najbliższym audycie albo redesignie.

Na horyzoncie jest też WCAG 3.0, ale to wciąż wersja robocza. Ostatni szkic W3C pochodzi z 10 września 2026 r., a według W3C do ukończenia zostało jeszcze kilka lat. WCAG 2 pozostanie w użyciu przez kolejne lata po publikacji nowej wersji.

Od czego zacząć? Checklista przejścia z WCAG 2.1 na 2.2

  1. Fokus: przejdź serwis klawiszem Tab i sprawdź, czy aktywny element nie znika pod nagłówkiem, banerem cookies ani czatem.
  2. Rozmiar celów: zmierz małe klikalne elementy, takie jak ikony zamykania, przyciski ilości, paginacja i ikony w stopce. Każdy ma mieć 24 × 24 px albo odstęp od sąsiednich.
  3. Przeciąganie: wypisz suwaki, listy sortowane przeciąganiem i mapy, a potem dodaj do nich alternatywę kliknięciem.
  4. Pomoc: sprawdź, czy kontakt, czat i FAQ są na każdej podstronie w tym samym miejscu.
  5. Formularze: przejdź formularze wieloetapowe i usuń pytania o dane podane wcześniej.
  6. Logowanie: zaloguj się menedżerem haseł i wklej kod jednorazowy. Jeśli któraś z tych czynności się nie udaje, popraw pola.

Zgodność ze wszystkimi 55 kryteriami sprawdzisz w audycie WCAG. Co obejmuje i ile kosztuje, opisujemy w artykule Audyt WCAG – ile kosztuje i co obejmuje?. Wolisz od razu porozmawiać o swoim serwisie? Napisz do nas.

Powiązane artykuły

UX/UI/AX · 28 września 2026

Audyt WCAG – ile kosztuje i co obejmuje?

Audyt WCAG sprawdza, czy strona, sklep lub aplikacja spełnia wytyczne dostępności na poziomie AA. Wyjaśniamy, co obejmuje, ile kosztuje w Polsce, ile trwa i po czym poznać rzetelną ofertę.

Częste pytania

Od kiedy WCAG 2.2 obowiązuje w Polsce?

Formalnie jeszcze nie obowiązuje. Polskie przepisy opierają się na WCAG 2.1 na poziomie AA. Wymagania normy EN 301 549 V4.1.1 z września 2026 r. opierają się na WCAG 2.2, ale prawnym punktem odniesienia stanie się ona dopiero po przywołaniu w Dzienniku Urzędowym UE. Daty przywołania na razie nie ogłoszono.

Czy strona zgodna z WCAG 2.2 jest zgodna z WCAG 2.1?

Tak. WCAG 2.2 jest wstecznie zgodna, więc treść spełniająca wersję 2.2 spełnia też 2.1 i 2.0. W drugą stronę ta zasada nie działa, bo strona zgodna z WCAG 2.1 może nie spełniać 6 nowych kryteriów z poziomów A i AA.

Ile kryteriów trzeba spełnić na poziomie AA w WCAG 2.2?

55, czyli 31 kryteriów z poziomu A i 24 z poziomu AA. W WCAG 2.1 było ich 50. Różnica wynika z 6 nowych kryteriów i usunięcia kryterium 4.1.1 Parsowanie.

Czy WCAG 2.2 ma polskie tłumaczenie?

Autoryzowanego tłumaczenia W3C na razie nie ma. Autoryzowane polskie tłumaczenie ma WCAG 2.1, z kwietnia 2021 r. Przy WCAG 2.2 korzystaj z oryginału na stronie W3C, a kryteria podawaj z numerami, np. 2.5.8, żeby nie było wątpliwości, o które chodzi.

Czy hasło maskowane spełnia WCAG 2.2?

Na poziomie AA nie, jeśli nie ma innej metody logowania. Prośba o wpisanie wybranych znaków hasła uniemożliwia wklejenie go z menedżera haseł. Według objaśnień W3C do kryterium 3.3.8 to przepisywanie informacji, czyli test funkcji poznawczych.

Kiedy pojawi się WCAG 3.0?

Nie wcześniej niż za kilka lat. WCAG 3.0 jest wersją roboczą, ostatni szkic W3C pochodzi z 10 września 2026 r. Według W3C WCAG 2 pozostanie w użyciu jeszcze kilka lat po ukończeniu wersji 3.0.

Chcesz wiedzieć, gdzie Twój produkt traci użytkowników?

Audyt UX kończy się priorytetyzowaną listą poprawek z uzasadnieniami. Zakres i wycenę przygotowujemy w kilka dni.

Napisz do nas