Ustawa o dostępności (EAA) — czy Twoja aplikacja i sklep muszą spełniać WCAG 2.2

Zacznijmy od sprostowania, bo w internecie krąży sporo mylących nagłówków: żaden przepis nie nakazuje dziś zgodności z WCAG 2.2. Prawnie wiąże WCAG 2.1 na poziomie AA — i to już od ponad roku. Ale jeśli budujesz produkt cyfrowy, którego cykl życia sięga 2027 roku, celowanie w 2.2 jest po prostu tańsze niż robienie tego samego dwa razy. Poniżej wyjaśniamy dlaczego, i co dokładnie musisz mieć.

Ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze (Dz.U. 2024 poz. 731) — polska implementacja dyrektywy 2019/882, czyli European Accessibility Act — weszła w życie 28 czerwca 2025 r. To nie jest już „nadchodząca regulacja". To obowiązujące prawo, a 2026 rok jest pierwszym, w którym organy nadzoru realnie się rozkręcają.

Uwaga: ten artykuł opisuje wymagania na poziomie technicznym i produktowym. Kwalifikacja prawna konkretnego biznesu — czy jesteś objęty, czy łapiesz się na wyłączenie, czy możesz powołać się na klauzulę ochronną — to temat na rozmowę z prawnikiem. Nie traktuj poniższego jako opinii prawnej.

Kogo to realnie dotyczy

Ustawa obejmuje wskazane produkty (komputery, smartfony, terminale płatnicze, bankomaty, automaty biletowe, czytniki e-booków) oraz wskazane usługi konsumenckie. Z perspektywy zespołów produktowych najważniejsze są te ostatnie:

• handel elektroniczny — sklepy internetowe i aplikacje sprzedażowe skierowane do konsumentów,
• usługi bankowości detalicznej — bankowość internetowa i mobilna, onboarding, wnioski kredytowe,
• usługi transportu pasażerskiego — strony, aplikacje, sprzedaż i rezerwacja biletów, informacja o podróży,
• usługi telekomunikacyjne, dostęp do audiowizualnych usług medialnych, e-booki.

Kluczowy test dla e-commerce jest prostszy, niż się wydaje: czy sprzedajesz konsumentom przez stronę lub aplikację. Jeśli tak, jesteś w zakresie — niezależnie od tego, czy sprzedajesz buty, czy subskrypcję SaaS-a.

Wyłączenia, na które można liczyć

• Mikroprzedsiębiorcy świadczący usługi (do 9 osób i obrót do 2 mln EUR) są wyłączeni spod obowiązków. Uwaga: wyłączenie dotyczy usług. Mikrofirma obracająca produktami ma jedynie ograniczone obowiązki administracyjne, nie pełne zwolnienie.
• Nieproporcjonalne obciążenie i zasadnicza zmiana produktu/usługi — klauzule ochronne pozwalają odstąpić od części wymogów. To nie jest jednak furtka „nie chce nam się": trzeba przeprowadzić i udokumentować ocenę, a dokumentację przedstawić organowi na żądanie. Powołanie się na te klauzule bez papierów jest gorsze niż niepowoływanie się wcale.
• Okres przejściowy do 28 czerwca 2030 r. dotyczy usług świadczonych na podstawie umów zawartych przed 28 czerwca 2025 r. — to bufor na kontrakty w toku, a nie licencja na budowanie nowych, niedostępnych ekranów.

Skąd w tym wszystkim WCAG — i dlaczego 2.1, a nie 2.2

Tu jest miejsce, w którym większość artykułów w sieci się myli. Łańcuch wygląda tak:

Ustawa (EAA) mówi o wymaganiach funkcjonalnych dostępności, ale nie wymienia WCAG z nazwy. → Domniemanie zgodności przysługuje temu, kto spełnia normę zharmonizowaną, czyli taką, do której odwołano się w Dzienniku Urzędowym UE. → Tą normą dla ICT jest EN 301 549. → Wersja obecnie zharmonizowana to V3.2.1 (przywołana w Dz.Urz. UE decyzją wykonawczą 2021/1339 z sierpnia 2021 r.), a ona odsyła do WCAG 2.1 poziom AA.

WCAG 2.2 opublikowano jako rekomendację W3C 5 października 2023 r., ale nie jest jeszcze częścią zharmonizowanej wersji normy. Draft EN 301 549 V4.1.0, który wciąga WCAG 2.2 AA, trafił do przeglądu w listopadzie 2025 r.; finalna V4.1.1 jest spodziewana w Dzienniku Urzędowym mniej więcej w okolicach października 2026 r. Terminy standaryzacyjne bywają ruchome — sprawdź aktualny stan, zanim oprzesz na tym harmonogram projektu.

Praktyczny wniosek dla zespołu:

• Musisz dziś spełniać WCAG 2.1 AA. To jest linia obrony przed organem nadzoru.
• Powinieneś projektować pod WCAG 2.2 AA. Różnica to raptem kilka kryteriów, a przepisanie tego samego frontu drugi raz za rok kosztuje wielokrotnie więcej niż zrobienie go dobrze teraz.

Co dokładnie dokłada WCAG 2.2

WCAG 2.2 jest wstecznie zgodny z 2.1 — nie unieważnia niczego, dokłada dziewięć kryteriów (jedno, 4.1.1 Parsing, zostało za to wycofane). Te, które najczęściej realnie boleją w e-commerce:

• 2.4.11 Focus Not Obscured (AA) — element z fokusem nie może być zasłonięty przez sticky header, cookie bar czy czat. Klasyk: użytkownik klawiatury „gubi się" pod przyklejonym paskiem w koszyku.
• 2.5.7 Dragging Movements (AA) — każda operacja przeciągania musi mieć alternatywę bez przeciągania (suwaki cen, sortowanie, zmiana ilości).
• 2.5.8 Target Size (Minimum) (AA) — cele dotykowe min. 24×24 px z wyjątkami. Bije w gęste paginacje i ikonki „×" przy pozycjach koszyka.
• 3.2.6 Consistent Help (A), 3.3.7 Redundant Entry (A) — pomoc w tym samym miejscu na każdym ekranie; nie każ wpisywać drugi raz danych, które użytkownik już podał (adres dostawy vs rozliczeniowy).
• 3.3.8 Accessible Authentication (AA) — logowanie nie może wymagać testu poznawczego (przepisywania kodu z pamięci, układanki). Musi działać wklejanie i menedżer haseł. To kryterium wywraca sporo „kreatywnych" flow logowania w bankowości.

Co w praktyce sprawdza się w sklepie i aplikacji

Audyty w polskim e-commerce wracają zwykle z tym samym zestawem problemów. Kolejność mniej więcej odpowiada częstotliwości:

1. Kontrast i stany fokusu. Szary tekst na białym tle poniżej 4.5:1 i outline: none w resecie CSS. Najtańsza do naprawy, najczęściej występująca klasa błędów.
2. Formularze bez etykiet. Placeholder to nie etykieta. Błędy walidacji przekazywane wyłącznie kolorem, bez tekstu i bez aria-live. Checkout, w którym czytnik ekranu nie mówi, co poszło nie tak, to bariera nie do obejścia.
3. Nawigacja klawiaturą. Modale bez pułapki fokusu, dropdowny działające tylko na hover, niedostępne filtry produktów, brak „skip to content".
4. Nieopisane elementy interaktywne. <div onclick> zamiast <button>, ikony bez nazwy dostępnej, karuzele bez pauzy.
5. Obrazy i multimedia. Puste alt tam, gdzie niosą treść (a zdjęcie produktu niesie), brak napisów do wideo.
6. Dynamiczne aktualizacje. Dodanie do koszyka, licznik pozycji, komunikaty o dostępności — zmiany, o których czytnik ekranu nigdy się nie dowiaduje.

W aplikacjach mobilnych dochodzi warstwa natywna: etykiety dostępności dla VoiceOver i TalkBack, reakcja na systemowe powiększenie czcionki (layout musi przeżyć 200% — u nas najczęściej pękają właśnie przyciski CTA), obsługa redukcji ruchu, brak wymuszania orientacji ekranu.

Czego nie załatwi nakładka

Warto powiedzieć wprost: widżety typu „accessibility overlay" nie dają zgodności. Nakładka JS, która dokleja pływającą ikonkę i podmienia kontrasty, nie naprawi semantyki HTML, nieopisanych formularzy ani nawigacji klawiaturą — a bywa, że dokłada własne bariery. W kilku jurysdykcjach firmy z takimi nakładkami i tak zbierały pozwy. Traktuj je jako kosmetykę, nie jako compliance.

Obowiązki, o których zespoły zapominają

Zgodność techniczna to nie wszystko. Ustawa nakłada też obowiązki informacyjne i proceduralne:

• Informacja o dostępności usługi — musisz publicznie opisać, jak usługa spełnia wymagania. W praktyce: strona „Deklaracja dostępności" w stopce, utrzymywana i aktualna, nie skopiowana z cudzego serwisu.
• Procedura zgłaszania barier — konsument może zgłosić, że czegoś nie da się użyć. Masz wtedy 7 dni na odpowiedź: co i kiedy z tym zrobisz. To termin operacyjny, który trzeba wpiąć w proces obsługi klienta i backlog, a nie odkryć w dniu pierwszego zgłoszenia.
• Dokumentacja oceny zgodności — zwłaszcza jeśli powołujesz się na nieproporcjonalne obciążenie. Musi istnieć zanim przyjdzie pytanie.

Nadzór jest rozproszony między siedem organów — m.in. UKE, Urząd Transportu Kolejowego, Urząd Lotnictwa Cywilnego, Inspekcja Transportu Drogowego, urzędy morskie, Rzecznik Finansowy i resort informatyzacji — właściwy zależy od rodzaju usługi. Kara administracyjna sięga dziesięciokrotności przeciętnego miesięcznego wynagrodzenia za rok poprzedni, przy czym nie więcej niż 10% obrotu z poprzedniego roku obrotowego.

Szczerze: dla dużego sklepu sama kwota kary rzadko jest głównym ryzykiem. Bardziej boli koszt naprawy pod presją czasu — przepisywanie checkoutu w trybie awaryjnym, gdy termin narzucił organ, kosztuje wielokrotnie więcej niż zaplanowana praca. No i drugi, mniej oczywisty argument: około 12% dorosłych Polaków ma orzeczenie o niepełnosprawności, a bariery w koszyku uderzają też w użytkowników starszych, na słabym łączu i w ostrym słońcu. Niedostępny checkout to porzucony koszyk, niezależnie od tego, czy ktoś kiedykolwiek na niego poskarży.

Od czego zacząć — realny plan

Jeśli dziś nie wiesz, jak stoisz, sensowna kolejność wygląda tak:

1. Zmierz punkt wyjścia (dni, nie tygodnie). Automat (axe, Lighthouse, Pa11y w CI) wyłapie 30–40% problemów — to dużo i mało jednocześnie. Reszty nie da się wykryć skryptem: sensowność alt, logika kolejności fokusu, czy komunikat błędu faktycznie jest zrozumiały. Automat mówi „nie ma etykiety", nie mówi „etykieta jest bez sensu".

2. Zaudytuj ścieżki krytyczne ręcznie. Nie cały serwis — ścieżki, które robią przychód: wyszukiwanie → karta produktu → koszyk → checkout → płatność → konto. Klawiatura, czytnik ekranu (NVDA/VoiceOver), 200% powiększenia, tryb wysokiego kontrastu.

3. Priorytetyzuj po ryzyku i ruchu. Blokery na ścieżce zakupowej idą pierwsze. Kontrast w stopce może poczekać.

4. Napraw u źródła, nie łatkami. Jeśli używasz design systemu, poprawka w komponencie Button/Input/Modal naprawia setki ekranów naraz. To jest miejsce, gdzie dostępność robi się tania.

5. Wepnij to w proces. Testy axe w CI na pull requestach, kryteria dostępności w definition of done, dostępność w code review. Bez tego wracasz do stanu wyjściowego w ciągu dwóch kwartałów — to najczęstszy scenariusz, jaki widzimy u firm, które zrobiły jednorazowy audyt i odhaczyły temat.

6. Udokumentuj. Deklaracja dostępności, procedura zgłoszeń, ocena zgodności.

Podsumowanie

• Ustawa wdrażająca EAA obowiązuje od 28 czerwca 2025 r. — to stan faktyczny, nie plan.
• Prawnie wiąże dziś WCAG 2.1 AA przez zharmonizowaną EN 301 549 V3.2.1. WCAG 2.2 wejdzie do normy wraz z V4.1.1, spodziewaną w Dzienniku Urzędowym około października 2026 r.
• Buduj pod 2.2 AA. Nadwyżka nad wymogiem jest niewielka, a chroni przed przepisywaniem tego samego za rok.
• Poza kodem: deklaracja dostępności, procedura zgłoszeń z terminem 7 dni, dokumentacja oceny.
• Overlaye nie dają zgodności. Poprawki w design systemie i testy w CI — dają.

Robimy audyty dostępności WCAG 2.2 dla sklepów, aplikacji webowych i mobilnych. Nie zostawiamy PDF-a z listą 300 błędów — dostajesz raport uporządkowany według ryzyka i ruchu, konkretne poprawki na poziomie komponentów oraz gotowe wpięcie testów w CI, żeby regresje nie wracały. Jeśli chcesz wiedzieć, jak naprawdę stoisz przed wejściem WCAG 2.2 do normy — odezwij się do nas.