WCAG 2.2: wymagania, zmiany i kogo obowiązują

Dostępność cyfrowa przestała być dobrym gestem wobec części użytkowników. Od 28 czerwca 2025 roku jest w Polsce obowiązkiem prawnym dla większości firm prywatnych, z konkretnym organem nadzoru i konkretnymi karami. Problem w tym, że sam standard WCAG 2.2, o którym mówi się najczęściej, nie jest tym samym, co ten obowiązek wymaga wprost, a to rozróżnienie zmienia, ile realnie musicie dziś zrobić i ile możecie zrobić z wyprzedzeniem. Ten artykuł rozkłada trzy rzeczy, które w rozmowach o WCAG 2.2 wciąż się ze sobą myli: sam standard techniczny, obowiązek prawny, który się do niego odwołuje, i konsekwencje jego zignorowania.

Czym jest WCAG 2.2 i dlaczego to dopiero połowa historii

WCAG, czyli Web Content Accessibility Guidelines, to zestaw wytycznych opracowanych przez World Wide Web Consortium (W3C), opisujących, jak tworzyć treści i interfejsy cyfrowe dostępne dla jak najszerszej grupy użytkowników, w tym osób z niepełnosprawnościami wzroku, słuchu, ruchu i funkcji poznawczych. Standard opiera się na czterech zasadach znanych jako POUR: treść ma być postrzegalna, funkcjonalna, zrozumiała i solidna technicznie. WCAG 2.2 to najnowsza wersja tego standardu, opublikowana przez W3C 5 października 2023 roku jako ewolucja, nie rewolucja: rozszerza WCAG 2.1, zachowując z nim pełną kompatybilność wsteczną.

Tu zaczyna się rozróżnienie, które najczęściej ginie w rozmowach o zgodności: WCAG samo w sobie nie jest ustawą. To techniczny punkt odniesienia, do którego przepisy prawne się odwołują, mówiąc, jaki poziom standardu trzeba spełnić. A w polskim prawie, jak pokażemy niżej, tym poziomem odniesienia jest dziś WCAG 2.1, nie 2.2.

Cztery zasady POUR najlepiej widać na konkretnych przykładach, nie w abstrakcji. Sklep internetowy łamie zasadę postrzegalności, kiedy zdjęcie produktu nie ma opisu alternatywnego, więc osoba niewidoma nie wie, co kupuje. Łamie zasadę funkcjonalności, kiedy proces płatności wymaga myszy, a użytkownik korzystający wyłącznie z klawiatury utyka na kroku wyboru dostawy. Łamie zasadę zrozumiałości, kiedy komunikat błędu formularza mówi tylko „coś poszło nie tak”, bez wskazania, które pole i dlaczego. Łamie zasadę solidności technicznej, kiedy komponent wygląda poprawnie wizualnie, ale czytnik ekranu w ogóle go nie odczytuje, bo kod nie ma odpowiedniej semantyki. Żadna z tych czterech sytuacji nie wymaga wyobraźni: to codzienne usterki, które audytorzy znajdują w niemal każdym produkcie, który nie był świadomie projektowany pod kątem dostępności.

Dziewięć nowych kryteriów: co faktycznie się zmienia

Nowe kryteria nie są przypadkowe. Sześć z dziewięciu dotyczy wprost trzech miejsc, w których firmy tracą klientów najboleśniej: logowania, płatności i formularzy. To nie jest zbieg okoliczności, tylko efekt tego, że W3C budowało WCAG 2.2 w odpowiedzi na realne bariery zgłaszane przez użytkowników z ograniczeniami poznawczymi, ruchowymi i przez osoby korzystające głównie z urządzeń mobilnych.

Kryterium usunięte w 2.2, 4.1.1 Poprawność kodu, dotyczyło poprawnej składni HTML. W3C uznało je za przestarzałe, bo dzisiejsze przeglądarki i technologie asystujące radzą sobie z drobnymi błędami składni znacznie lepiej niż w 2008 roku, kiedy WCAG 2.0 powstawało. To jedyny przypadek w historii standardu, w którym coś ubyło, a nie tylko przybyło.

Dostosowanie strony do WCAG 2.2: dziewięć poprawek krok po kroku

Tabela wyżej mówi, co się zmieniło. Ta sekcja mówi, co z tym konkretnie zrobić w kodzie i projekcie. Kolejność ma znaczenie: pierwsze cztery poprawki to zmiany kosmetyczne, wykonalne w dniach, ostatnie trzy wymagają przeprojektowania procesu logowania albo formularza, więc realnie zajmują tygodnie. Jeżeli macie ograniczony czas przed audytem, zacznijcie od góry tabeli.

Żadna z tych dziewięciu poprawek nie wymaga przebudowy architektury. To, co realnie decyduje o czasie wdrożenia, to nie trudność pojedynczej zmiany, tylko liczba miejsc w kodzie, w których ten sam wzorzec się powtarza. Jeden niedostępny przycisk poprawia się w kwadrans. Ten sam przycisk powielony w czterdziestu komponentach poprawia się tygodniami, chyba że poprawka trafi do wspólnego komponentu, o czym niżej.

Trzy warstwy obowiązku, które w Polsce łatwo pomylić jako jedną

Kiedy klienci pytają nas, czy WCAG 2.2 jest obowiązkowe, odpowiedź wymaga rozdzielenia trzech osobnych rzeczy, bo każda ma inny status prawny.

• Warstwa 1, standard techniczny. WCAG 2.2 samo w sobie to rekomendacja W3C, nie akt prawny. Nikt nie może Was formalnie ukarać za niespełnienie WCAG 2.2 jako takiego.
• Warstwa 2, sektor publiczny. Ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych obowiązuje w Polsce od 2019 roku i dotyczy urzędów, uczelni, szpitali publicznych i innych instytucji.
• Warstwa 3, sektor prywatny. Ustawa z 26 kwietnia 2024 roku o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze, wdrażająca unijny European Accessibility Act, obowiązuje od 28 czerwca 2025 roku i to ona dotyczy większości firm prywatnych.

Właśnie warstwa trzecia jest dziś najważniejsza dla firm, które nie są instytucją publiczną, i to ona zawiera nuans, który regularnie umyka w rozmowach handlowych: referencyjnym standardem, do którego odwołuje się ta ustawa, jest WCAG 2.1 na poziomie AA, nie WCAG 2.2. Formalnie rzecz biorąc, spełnienie WCAG 2.1 AA wystarcza do zgodności z prawem. WCAG 2.2 jest nowszym, dalej idącym standardem, dziś rekomendowanym, ale nie wymaganym wprost przepisem. Dlaczego mimo to warto celować od razu w 2.2, piszemy w sekcji z naszą oceną niżej.

W praktyce te trzy warstwy najczęściej mylą się w rozmowach właśnie na styku sektora prywatnego i publicznego. Weźmy sklep internetowy z odzieżą, który obsługuje też zamówienia dla urzędu jako jeden z klientów biznesowych. Sam sklep podlega wyłącznie warstwie trzeciej, czyli ustawie z 26 kwietnia 2024 roku, i musi spełniać WCAG 2.1 AA jako firma e-commerce. Ale jeżeli startuje w przetargu publicznym, zamawiający ma prawo wymagać wyższego standardu w specyfikacji, często właśnie WCAG 2.2, niezależnie od tego, co mówi ustawowe minimum. To pokazuje, dlaczego traktowanie WCAG 2.1 AA jako sufitu, a nie podłogi, bywa różnicą między dostępem do kontraktu a jego utratą.

Kogo dotyczy ustawa i kto jest z niej zwolniony

Jedno wyłączenie dotyczy wszystkich kategorii naraz: mikroprzedsiębiorcy, czyli firmy zatrudniające mniej niż 10 osób i osiągające obrót poniżej 2 milionów euro rocznie, nie muszą dostosowywać swoich produktów i usług do wymagań ustawy. Jeżeli jesteście większą firmą albo działacie w jednej z branż z tabeli wyżej, wyłączenie Was nie obejmuje, niezależnie od tego, czy klienci są konsumentami, czy innymi firmami.

Co grozi za brak zgodności

Nadzór nad zgodnością sprawuje Prezes Zarządu PFRON, Państwowego Funduszu Rehabilitacji Osób Niepełnosprawnych. To do niego trafiają zgłoszenia o niedostępnych produktach i usługach, ma 30 dni na ich rozpatrzenie albo przekazanie do właściwego organu nadzoru rynku, jeśli sprawa dotyczy konkretnej kategorii produktu.

Źródło: Biznes.gov.pl, stan na sierpień 2026.

Nasza perspektywa: dlaczego warto celować w 2.2, choć przepis wymaga 2.1

Jak przygotować firmę, krok po kroku

Źródło: metodyka własna Quality Island, stosowana w audytach dostępności.

Krok trzeci, wpisanie poprawek w standard projektowy, jest tym, który najczęściej się pomija, a to on decyduje, czy dostępność zostaje na stałe, czy wraca po pierwszym redesignie. Jeżeli poprawiony przycisk, formularz albo modal żyje wyłącznie na jednej stronie, którą właśnie audytowaliście, następny developer, budując podobny komponent gdzie indziej w aplikacji, powieli stary, niedostępny wzorzec, bo nie ma skąd wziąć poprawnego. Jeżeli ten sam przycisk trafi do wspólnej biblioteki komponentów albo design systemu, poprawka rozchodzi się sama, za każdym razem, kiedy ktoś użyje tego komponentu, bez potrzeby ponownego audytu. To różnica między naprawianiem symptomów a naprawianiem źródła.

Skuteczne testowanie dostępności łączy dwa podejścia, i żadne z nich osobno nie wystarcza. Automatyczne narzędzia, takie jak axe, WAVE czy Lighthouse, szybko wykrywają błędy techniczne: brakujące teksty alternatywne, zbyt niski kontrast, błędy struktury nagłówków. Nie ocenią jednak, czy tekst alternatywny ma sens, czy komunikat błędu jest zrozumiały, ani czy proces zakupowy da się realnie przejść z czytnikiem ekranu. To sprawdzają wyłącznie testy manualne: obsługa klawiaturą, praca z czytnikiem ekranu, ocena kolejności fokusu i zachowania komponentów dynamicznych, takich jak modale czy dropdowny.

Dostępność, UX i konwersja: efekt uboczny, o którym warto wiedzieć

Firmy zamawiają audyt WCAG z powodu obowiązku prawnego, ale bardzo często wychodzą z niego z listą poprawek, które podnoszą też zwykłą użyteczność produktu dla wszystkich, nie tylko dla osób z niepełnosprawnościami. To nie jest efekt marketingowy, tylko konsekwencja tego, że wiele kryteriów WCAG opisuje po prostu dobrze zaprojektowany interfejs. Jasna etykieta pola formularza, logiczna kolejność nawigacji, czytelny komunikat błędu blisko pola, które go wywołało, wyraźny kontrast tekstu na przycisku, to wszystko poprawia doświadczenie każdego użytkownika, niezależnie od tego, czy korzysta z czytnika ekranu, czy po prostu robi zakupy w słoneczny dzień na telefonie z odblaskiem na ekranie.

Podobny mechanizm działa w stronę SEO. Poprawna hierarchia nagłówków, semantyczny HTML, opisowe teksty alternatywne i zrozumiałe linki to jednocześnie wymogi WCAG i podstawy techniczne, na których buduje się widoczność w wyszukiwarce. Dostępność nie zastępuje pracy nad SEO, ale w praktyce często robi część tej roboty przy okazji, o ile poprawki są robione świadomie, a nie mechanicznie, wyłącznie po to, żeby przejść kontrolę.

Ile to kosztuje i od czego zacząć

Wśród wszystkich usług QA w naszej ofercie audyt dostępności WCAG ma najniższy próg wejścia, od 2 700 zł za stronę do 10 podstron, bo to jedyna usługa w portfolio, za którą stoi konkretny, już obowiązujący termin prawny, a nie tylko dobra praktyka.

Jeżeli zespół ma dopiero zacząć rozumieć WCAG 2.2 od podstaw, zanim zamówicie audyt, dwie ścieżki edukacyjne odpowiadają na różne potrzeby: stacjonarne szkolenie Testowanie dostępności WCAG 2.2 dla testerów i zespołów QA, z terminami 30 września i 14 października, oraz kurs online Wdrażanie i testowanie dostępności cyfrowej WCAG skierowany do managerów IT, product ownerów i liderów technologicznych, którzy potrzebują zrozumieć temat od strony strategii i governance, nie tylko wykonania.

Najczęściej zadawane pytania o WCAG 2.2

Czy WCAG 2.2 jest w Polsce obowiązkowe prawnie?

Nie wprost. Ustawa z 26 kwietnia 2024 roku, obowiązująca od 28 czerwca 2025 roku, odwołuje się formalnie do WCAG 2.1 na poziomie AA. WCAG 2.2 jest nowszym i bardziej wymagającym standardem, dziś rekomendowanym jako dobra praktyka wyprzedzająca przyszłe zaostrzenie przepisów, ale nie wskazanym wprost jako minimum ustawowe.

Czym różni się WCAG 2.2 od WCAG 2.1?

WCAG 2.2 dodaje dziewięć nowych kryteriów sukcesu i usuwa jedno, 4.1.1 Poprawność kodu, uznane za przestarzałe. Nowe kryteria koncentrują się na widoczności fokusu, rozmiarze elementów klikalnych, alternatywach dla przeciągania, spójnej pomocy i dostępnym uwierzytelnianiu, czyli obszarach szczególnie ważnych dla osób z ograniczeniami poznawczymi i ruchowymi oraz dla użytkowników mobilnych.

Kto nadzoruje zgodność z ustawą i jakie grożą kary?

Nadzór sprawuje Prezes Zarządu PFRON. Firma, która nie poprawi naruszenia w ciągu 120 dni od jego wykrycia, naraża się na karę finansową do dziesięciokrotności przeciętnego wynagrodzenia, dziś około 80 do 90 tysięcy złotych, nie więcej jednak niż 10% rocznego obrotu, oraz na wykluczenie z zamówień publicznych.

Czy moja firma jest zwolniona z obowiązku?

Tak, jeżeli jesteście mikroprzedsiębiorcą: firmą zatrudniającą mniej niż 10 osób i osiągającą roczny obrót poniżej 2 milionów euro. Powyżej tych progów wyłączenie nie obowiązuje, niezależnie od branży.

Czy automatyczne narzędzia wystarczą do sprawdzenia zgodności?

Nie. Automatyczne narzędzia wykrywają część błędów technicznych, ale nie ocenią sensu opisu alternatywnego, logiczności kolejności fokusu ani tego, czy proces zakupowy realnie da się przejść z czytnikiem ekranu. Rzetelny audyt zawsze łączy testy automatyczne z manualnymi.

Ile kosztuje audyt dostępności WCAG?

Audyt strony internetowej do 10 podstron zaczyna się od 2 700 zł. Pełny cennik, w tym audyt aplikacji mobilnej i dokumentów PDF, jest w sekcji cen wyżej.

Powiązane na blogu Quality Island

• Testowanie dostępności, jak, kiedy, narzędzia i tipy
• Testy dostępności Accessibility test, czym są i dlaczego są ważne
• 7 obszarów dostępności, które musisz przetestować

Pełna lista źródeł

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2
• W3C, What’s New in WCAG 2.2
• Biznes.gov.pl, Kto ma obowiązek zapewniać dostępność produktów i usług
• ELI, Ustawa z dnia 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze
• Gov.pl, Dostępność cyfrowa