WCAG i europejski akt o dostępności: co sprawdza build

Od 28 czerwca 2025 roku sklepy internetowe i inne usługi dla konsumentów wymienione w ustawie z 26 kwietnia 2024 roku (Dz.U. 2024 poz. 731), z wyjątkiem usług mikroprzedsiębiorców, muszą spełniać wymagania dostępności. Ustawa wdraża dyrektywę (UE) 2019/882, czyli europejski akt o dostępności (European Accessibility Act, EAA), i nie wymienia WCAG (Web Content Accessibility Guidelines) z nazwy. Opisuje własnymi słowami cztery cechy, które mają mieć strona i aplikacja, a WCAG jest standardem W3C, w którym te cechy da się sprawdzić kryterium po kryterium.

Z takiego wymagania można zrobić kontrolę, która po odpowiednim ustawieniu zatrzymuje wydanie. Obejmie ona jednak tylko część WCAG, bo narzędzie sprawdzi, czy atrybut jest, a nie czy ma sens dla osoby korzystającej z czytnika ekranu.

Kogo dotyczy europejski akt o dostępności: sklep internetowy i inne usługi

Ustawa obejmuje usługi oferowane konsumentom w sześciu obszarach (art. 3 ust. 2): usługi telekomunikacyjne, dostęp do audiowizualnych usług medialnych, usługi towarzyszące transportowi pasażerskiemu, bankowość detaliczną, rozpowszechnianie książek elektronicznych i handel elektroniczny. Dla firmy, która sprzedaje przez własną stronę, liczy się ostatni z nich. Przewoźnicy mają własny obszar: dla nich ustawa wymienia strony internetowe, usługi mobilne wraz z aplikacjami, e-bilety, informacje o podróży w czasie rzeczywistym i interaktywne terminale samoobsługowe. Produkty, na przykład terminale płatnicze, bankomaty, biletomaty i czytniki książek elektronicznych, ustawa omawia osobno (art. 3 ust. 1).

O tym, czy ustawa dotyczy konkretnej firmy, rozstrzygają dwa wyłączenia. Art. 4 pkt 1 wyłącza usługi oferowane przez mikroprzedsiębiorców, więc to, czy firma mieści się w tym pojęciu, ocenia jej prawnik na podstawie danych firmy. Art. 4 pkt 2 wyłącza z kolei strony i aplikacje w zakresie map i map interaktywnych, w tym geoportali, przeznaczonych do zastosowań nawigacyjnych, gdy dane teleadresowe i położenie podano dostępnie zgodnie z ustawą o dostępności cyfrowej podmiotów publicznych, oraz treści, których przedsiębiorca nie finansuje, nie tworzy ani nie kontroluje. Przepis mówi o usługach oferowanych konsumentom, więc sprzedaż wyłącznie innym firmom wymaga osobnej oceny prawnej.

Jaka wersja WCAG: 2.2 i poziom AA, choć ustawa żadnej nie wymienia

Ustawa o dostępności nie wskazuje wersji WCAG, bo nie wymienia WCAG w ogóle. Wymóg jednolitości stron i aplikacji mobilnych usługi opiera na czterech cechach: "postrzegalność, funkcjonalność, zrozumiałość i kompatybilność" (art. 12 ust. 2 pkt 3). To polskie odpowiedniki czterech zasad, na których zbudowano WCAG: perceivable, operable, understandable i robust. Informacje o usłudze ustawa każe podawać między innymi czcionką o odpowiednim rozmiarze i kroju, z wystarczającym kontrastem i odstępami między literami, wierszami i akapitami, a treści nietekstowe z alternatywną prezentacją (art. 12 ust. 2 pkt 1 lit. d i e).

Domniemanie spełnienia wymagań daje dopiero zgodność z normami zharmonizowanymi albo specyfikacjami technicznymi, w zakresie, który obejmują (art. 20 ust. 1), a w tym przepisie nie pada ani WCAG, ani norma EN 301 549. Konkretną wersję podaje ustawa z 4 kwietnia 2019 roku o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Jej załącznik, zatytułowany "Wytyczne dla dostępności treści internetowych 2.1", to polska nazwa WCAG 2.1 i wylicza kryteria sukcesu z poziomami (art. 5 ust. 1). Wymagania uznaje się tam za spełnione także wtedy, gdy podmiot spełnia punkty 9, 10 i 11 Polskiej Normy wdrażającej ETSI EN 301 549 V3.2.1:2021 (art. 5 ust. 3).

Aktualną wersją jest WCAG 2.2, rekomendacja W3C w wersji z 12 grudnia 2024 roku, z tymi samymi czterema zasadami i poziomami zgodności A, AA i AAA. W praktyce za cel dobrze przyjąć WCAG 2.2 na poziomie AA. Sektor publiczny ma wzorzec w wersji 2.1, a wersja 2.2 dokłada do niego kolejne kryteria, więc cel 2.2 AA obejmuje także to, czego wymaga 2.1 AA.

W handlu elektronicznym art. 18 pkt 2 stosuje te cztery cechy także do funkcji identyfikacji, bezpieczeństwa, płatności i podpisów elektronicznych oraz do usług płatniczych, które są częścią usługi. Te funkcje art. 18 pkt 2 obejmuje wprost, a resztę ścieżki od koszyka do płatności obejmują ogólne wymagania z art. 12.

Kary, wyjątek dla nieproporcjonalnego obciążenia i regulamin

Usługodawca, który nie zapewnia wymagań z art. 12-19, podlega karze do dziesięciokrotności przeciętnego miesięcznego wynagrodzenia w gospodarce narodowej za poprzedni rok, nie więcej jednak niż 10% obrotu z poprzedniego roku obrotowego (art. 73 ust. 1 pkt 2). Przeciętne wynagrodzenie ogłasza Prezes GUS w Monitorze Polskim. Karę nakłada decyzją Prezes Zarządu PFRON albo właściwy organ (ust. 3), a przy wymiarze liczą się waga naruszenia, liczba niezgodnych produktów lub usług i liczba osób, których dotyczy (ust. 4). Nad handlem elektronicznym nadzór sprawuje minister właściwy do spraw informatyzacji (art. 38 ust. 3 pkt 2).

Wymagania stosuje się tylko w takim zakresie, w jakim nie wymagają zasadniczej zmiany usługi i nie są nieproporcjonalnym obciążeniem (art. 21). Ocenę robi sam przedsiębiorca (ust. 2), porównując koszty netto z kosztami operacyjnymi, koszty z korzyścią dla użytkowników i koszty netto z przychodami netto (ust. 3). Przebieg oceny i jej ustalenia przedsiębiorca dokumentuje (ust. 5). Dokumentację przechowuje przez 5 lat od zakończenia świadczenia usługi (ust. 6). Jeśli z oceny wynika, że nie musi spełniać wymagania, niezwłocznie informuje o tym na piśmie organ nadzoru rynku (ust. 8), a ocenę powtarza nie rzadziej niż co 5 lat i przy każdej zmianie usługi (ust. 10).

Usługodawca sam ocenia też zgodność usługi (art. 32 ust. 1). W regulaminie albo równoważnym dokumencie publikuje informacje o usłudze i o tym, jak spełnia wymagania dostępności (ust. 2 pkt 1), przy niezgodności podejmuje działania naprawcze (pkt 5) i niezwłocznie informuje o niej organ nadzoru (pkt 6). Zapis w regulaminie jest więc deklaracją, którą każdy może porównać z działającą stroną.

Przepisy mają okresy przejściowe. Umowy o usługi zawarte przed wejściem ustawy w życie mogą trwać bez zmian do wygaśnięcia, nie dłużej niż do 28 czerwca 2030 roku, i do tego samego dnia można używać produktów z art. 3 ust. 1, czyli na przykład terminali, których już używano do świadczenia usługi (art. 85). Art. 85 ust. 2 mówi o produktach z art. 3 ust. 1, a nie o stronie sklepu. Ustawy nie stosuje się do nagrań opublikowanych przed jej wejściem w życie, plików dokumentów biurowych opublikowanych przed tą datą ani treści archiwalnych, których od tego czasu nie aktualizowano (art. 86).

Bramka w buildzie: pięć sprawdzeń i próg dla nowych naruszeń

Wymóg zapisany prozą staje się użyteczny dopiero wtedy, gdy uruchamia się go przy każdym wydaniu. Kontrola działa na zbudowanej wersji strony, czyli na HTML-u, który dostanie użytkownik, a nie na kodzie źródłowym, więc łapie też błędy wprowadzone przez szablon, system zarządzania treścią albo zewnętrzny komponent.

Tak działa kontrola accessibility w pakiecie @silesiansolutions/search-quality-kit, naszym pakiecie npm. W CI tej witryny pakiet w wersji 0.14.0 (stan na 28.10.2026) raportuje znaleziska tej kontroli przy każdym buildzie, a sposób, w jaki zamienić je w bramkę, opisuje krok 3 w sekcji "Od czego zacząć". Sprawdza pięć rzeczy: obraz bez atrybutu alt (poza obrazami z role="presentation" albo aria-hidden="true"), przycisk bez nazwy dostępnej, link bez nazwy dostępnej, brak atrybutu lang na elemencie html oraz przeskoki poziomów nagłówków, na przykład z H2 od razu do H4. Każde znalezisko ma poziom ostrzeżenia, wskazuje stronę i podpowiada poprawkę.

O tym, czy ostrzeżenie zatrzyma wydanie, decyduje ustawienie ci.failOn; domyślnie bramka zatrzymuje tylko błędy. Polecenie verify --baseline raport.json --fail-on-new stosuje poziomy z ci.failOn wyłącznie do znalezisk, których nie było w poprzednim raporcie. Dzięki temu istniejąca strona dostaje raport z zaległościami, a każda nowa zmiana musi je zostawić bez nowych naruszeń.

Taką dostępność sprawdzaną automatycznie w buildzie obejmuje nasza oferta z zakresu cyberbezpieczeństwa i zgodności. Przedmiotem tej usługi są kod, architektura i CI/CD zespołu, który wydaje oprogramowanie, więc dostaje on bramkę w pipeline'ie. Zakres usługi kończy się na tej bramce, a ocena zgodności z WCAG należy do osoby z klawiaturą i czytnikiem ekranu.

Co wykryje build, a co sprawdzi tylko człowiek

Automat wykrywa brak atrybutu, a człowiek ocenia, czy atrybut coś znaczy. Dokumentacja pakietu mówi to o własnej kontroli wprost: obejmuje podstawowe alternatywy obrazów, nazwy linków i przycisków, język dokumentu i poważne skoki nagłówków, ale nie jest audytem zgodności z WCAG. Podział wygląda tak:

Ręczny przegląd zaczyna się od ścieżki zakupu: wyszukiwanie produktu, koszyk, dane dostawy, płatność i potwierdzenie. Funkcje identyfikacji, bezpieczeństwa i płatności z tej ścieżki art. 18 pkt 2 obejmuje wprost. Przegląd składa się z dwóch sesji: jedna z samą klawiaturą, druga z czytnikiem ekranu. Powtarza się je przy każdej większej zmianie szablonu zamówienia i przy każdym nowym sposobie płatności. Build pilnuje regresji, a pierwszy punkt odniesienia daje dopiero ocena człowieka.

Od czego zacząć

1. Ustal, czy usługa mieści się w wyliczeniu z art. 3 ust. 2 i czy firma jest mikroprzedsiębiorcą; to pytanie do prawnika, bo od odpowiedzi zależy zakres pozostałych prac.
2. Przyjmij za cel WCAG 2.2 na poziomie AA i zapisz to w wymaganiach projektu, żeby zespół nie musiał zgadywać.
3. Włącz kontrolę dostępności w CI z raportem bazowym, ustaw ci.failOn na ["error", "warning"], bo znaleziska tej kontroli mają poziom ostrzeżenia, i uruchamiaj verify --baseline raport.json --fail-on-new. Poziom warning obejmuje też ostrzeżenia innych kontroli, więc na istniejącej stronie raport bazowy jest warunkiem koniecznym.
4. Przejdź ręcznie ścieżkę zakupu z klawiaturą i czytnikiem ekranu, popraw znalezione błędy i powtarzaj przegląd przy zmianach w zamówieniu.
5. Opublikuj w regulaminie informację z art. 32 ust. 2 pkt 1. Jeśli korzystasz z wyjątku z art. 21, udokumentuj ocenę i zawiadom organ nadzoru rynku (art. 21 ust. 5-8).

Najczęściej zadawane pytania

Co to jest WCAG?

WCAG (Web Content Accessibility Guidelines) to standard W3C opisujący wymagania dostępności treści internetowych. Opiera się na czterech zasadach, czyli postrzegalności, funkcjonalności, zrozumiałości i kompatybilności (perceivable, operable, understandable, robust), a jego kryteria mają poziomy zgodności A, AA i AAA. Aktualną wersją jest WCAG 2.2, rekomendacja W3C w wersji z 12 grudnia 2024 roku.

Czy WCAG jest obowiązkowe dla sklepu internetowego?

Ustawa o dostępności nie wymienia WCAG z nazwy, więc obowiązują wymagania z art. 12-19, w tym cztery cechy z art. 12 ust. 2 pkt 3. Domniemanie spełnienia wymagań daje zgodność z normami zharmonizowanymi (art. 20 ust. 1). WCAG służy jako praktyczny punkt odniesienia, bo ustawa o dostępności cyfrowej podmiotów publicznych wpisuje do załącznika jego wersję 2.1.

Którą wersję i jaki poziom WCAG przyjąć?

WCAG 2.2 na poziomie AA. Wersja 2.2 jest aktualną rekomendacją W3C i dokłada kryteria do wersji 2.1, której używa sektor publiczny, a poziom AA jest tym, do którego zwykle się dąży. Ustawa tego nie wymaga, to wybór praktyczny.

Czy wystarczy automatyczny test dostępności?

Nie. Test w buildzie wykrywa brak atrybutów i nazw, ale nie sprawdza kontrastu, obsługi klawiaturą, kolejności fokusu, sensowności opisów obrazów, napisów ani zrozumiałości błędów formularza. Te rzeczy ocenia człowiek z klawiaturą i czytnikiem ekranu.

Czy strona firmowa bez sklepu podlega ustawie?

Zwykle nie, jeśli strona tylko prezentuje ofertę, i tak, jeśli konsument zawiera na niej umowę. Według art. 5 pkt 32 usługi handlu elektronicznego to usługi świadczone na odległość przez strony internetowe i urządzenia mobilne, drogą elektroniczną, na indywidualne żądanie konsumenta, w celu zawarcia umowy. Sama prezentacja oferty tej definicji nie spełnia. Konkretny przypadek ocenia prawnik, bo wyłączenie mikroprzedsiębiorców z art. 4 pkt 1 może zmienić wynik.

Źródła

1. 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, Dz.U. 2024 poz. 731, art. 3, 4, 5, 12, 18, 20, 21 ust. 1-3, 5, 6, 8 i 10, art. 32, 38, 73, 85, 86 i 88 (odczyt 28.10.2026)
2. Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (tekst jednolity), Dz.U. 2023 poz. 1440, art. 5 ust. 1 i 3 oraz załącznik (odczyt 28.10.2026)
3. Dyrektywa Parlamentu Europejskiego i Rady (UE) 2019/882 z dnia 17 kwietnia 2019 r. w sprawie wymogów dostępności produktów i usług, akt wdrażany ustawą z 26 kwietnia 2024 r. (odczyt 28.10.2026)
4. W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", rekomendacja W3C w wersji z 12.12.2024, cztery zasady i poziomy zgodności A, AA i AAA (odczyt 28.10.2026)