Najważniejsze wnioski
- PAD obowiązuje od 28 czerwca 2025 r. i obejmuje wskazane w ustawie produkty oraz usługi, w tym usługi handlu elektronicznego.
- W przypadku e-commerce trzeba ocenić całą ścieżkę użytkownika: wyszukiwanie, produkt, koszyk, formularze, płatność, dokumenty i kontakt po zakupie.
- PAD, norma EN 301 549 i wytyczne WCAG to trzy różne elementy: ustawa określa obowiązki, norma opisuje wymagania techniczne, a WCAG pomaga oceniać dostępność treści i interfejsów internetowych.
- Widget dostępności może być szybkim pierwszym krokiem wspierającym użytkownika, ale nie zastępuje audytu, testów z użytkownikami ani napraw źródłowych.
- Mikroprzedsiębiorca może korzystać z wyłączenia dla usług, jednak powinien najpierw ustalić swoją rolę i zakres działalności, zwłaszcza gdy wprowadza, importuje lub dystrybuuje produkty.
Dla zarządzającego
PAD warto potraktować jako element jakości usługi i zarządzania ryzykiem, a nie jednorazowy projekt IT. Zarząd powinien wyznaczyć właściciela procesu, potwierdzić zakres działalności objętej ustawą oraz zapewnić budżet na audyt, poprawki i testy regresji.
Dla sprzedaży
Dostępna ścieżka zakupu ogranicza sytuacje, w których klient nie może samodzielnie wysłać formularza, użyć koszyka lub dokończyć płatności. Zespół sprzedaży i obsługi klienta powinien zgłaszać bariery powtarzające się w kontakcie z użytkownikami oraz znać dostępne kanały pomocy.
Polski Akt o Dostępności (PAD) to ustawa, która od 28 czerwca 2025 r. określa wymagania dostępności dla wybranych produktów i usług, w tym usług handlu elektronicznego. Dla właściciela sklepu lub platformy najważniejsze pytanie nie brzmi jednak „czy zainstalować widget?”, lecz: „czy moja usługa pozwala użytkownikowi samodzielnie znaleźć ofertę, wypełnić formularz, zapłacić i otrzymać potrzebne informacje?”.
Ten materiał ma charakter informacyjny, a nie indywidualną poradę prawną. Stan prawny opisany w artykule oparto na tekście ustawy i materiałach urzędowych dostępnych na dzień publikacji. Przed podjęciem decyzji dotyczącej konkretnej firmy, produktu, umowy lub wyłączenia warto zweryfikować aktualne brzmienie przepisów oraz własny model działalności.
Najważniejsze wnioski
- PAD nie jest nazwą WCAG ani normy EN 301 549. To ustawa wdrażająca do polskiego prawa część wymagań Europejskiego Aktu o Dostępności.
- W e-commerce analiza powinna objąć cały proces zawarcia umowy, a nie tylko stronę główną sklepu.
- Wyłączenie dla mikroprzedsiębiorcy dotyczy usług i nie powinno być interpretowane automatycznie jako zwolnienie z każdego obowiązku związanego z produktami.
- Największe ryzyko praktyczne to bariery w formularzach, logowaniu, koszyku, płatnościach, dokumentach oraz komunikatach błędów.
- WCAGbot może szybko dodać funkcje wspierające dostępność, ale nie usuwa wszystkich barier i nie zastępuje audytu ani napraw źródłowych.
Czym jest Polski Akt o Dostępności i czego nie należy z nim mylić?
PAD to potoczna nazwa ustawy z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Ustawa wdraża dyrektywę (UE) 2019/882, czyli Europejski Akt o Dostępności.
W rozmowach o dostępności łatwo połączyć trzy różne pojęcia w jedno. W praktyce warto rozdzielić ich funkcję:
| Pojęcie | Rola | Znaczenie dla e-commerce |
|---|---|---|
| Polski Akt o Dostępności | Ustawa określająca zakres obowiązków i mechanizmy prawne. | Pomaga ustalić, czy dana usługa lub produkt może być objęty wymaganiami. |
| EN 301 549 | Europejska norma techniczna dotycząca dostępności ICT. | Stanowi ważny punkt odniesienia dla wymagań technicznych produktów i usług cyfrowych. |
| WCAG | Wytyczne W3C dla treści i interfejsów internetowych. | Pomagają testować między innymi kontrast, strukturę, klawiaturę, formularze i komunikaty. |
| Widget dostępności | Narzędzie dające użytkownikowi dodatkowe ustawienia interfejsu. | Może ułatwić korzystanie ze strony, ale nie zastąpi poprawnego kodu, treści i procesu zakupowego. |
Jeżeli potrzebujesz technicznego omówienia normy, przeczytaj poradnik EN 301 549 w e-commerce: wdrożenie krok po kroku. Z kolei praktykę poziomu AA omawia artykuł Poziom AA WCAG: praktyczny poradnik wdrożenia.
Dostępność nie zaczyna się w ustawieniach interfejsu. Zaczyna się tam, gdzie użytkownik ma wykonać zadanie bez proszenia kogoś o pomoc.
Kogo może dotyczyć PAD?
Ustawa obejmuje wskazane w niej produkty i usługi. Wśród usług znajdują się między innymi usługi łączności elektronicznej, bankowość detaliczna, wybrane cyfrowe elementy transportu pasażerskiego, e-booki oraz handel elektroniczny. W przypadku sklepu internetowego znaczenie ma to, czy firma oferuje usługę na odległość, drogą elektroniczną i na indywidualne żądanie konsumenta w celu zawarcia umowy.
Nie oznacza to, że każda strona firmowa jest automatycznie objęta PAD. Strona informacyjna bez procesu zawarcia umowy może wymagać odrębnej oceny. Również sklep B2B, platforma pośrednicząca, system rezerwacyjny albo strona z płatnym dostępem mogą wymagać analizy ich faktycznej funkcji, odbiorcy i modelu sprzedaży.
WCAGbot Accessibility Path: od zakresu PAD do stałej kontroli
Czy mikroprzedsiębiorca jest wyłączony z PAD?
Ustawa przewiduje wyłączenie dla usług oferowanych lub świadczonych przez mikroprzedsiębiorcę. Nie należy jednak skracać tej zasady do hasła „mikrofirma nie musi nic robić”. Po pierwsze, trzeba potwierdzić, czy firma spełnia definicję mikroprzedsiębiorcy. Po drugie, wyłączenie dotyczy usług, a nie automatycznie produktów wprowadzanych do obrotu, importowanych lub dystrybuowanych.
Praktyczny punkt startowy: opisz rolę firmy osobno dla każdego obszaru. Inaczej wygląda sytuacja podmiotu prowadzącego sklep, inaczej producenta urządzenia, a jeszcze inaczej dystrybutora terminali lub importera produktu.
Szerzej o zastosowaniu przepisów do sklepów przeczytasz w materiale Polski Akt o Dostępności w e-commerce: wdrożenie oraz w artykule Polski Akt o Dostępności: sklep internetowy i PAD.
Co sprawdzić w sklepie internetowym przed wdrożeniem?
Najczęstszy błąd polega na ocenie pojedynczej podstrony zamiast całej ścieżki klienta. Użytkownik nie kupuje produktu na stronie głównej. Musi zwykle wyszukać ofertę, zrozumieć informacje, wybrać wariant, uzupełnić dane, potwierdzić zgodę, wybrać dostawę i płatność, a następnie odebrać komunikaty po zakupie.
Lista obszarów do inwentaryzacji
- strona główna, menu, wyszukiwarka, filtry i sortowanie;
- karty produktów, galerie, warianty, dostępność i cena;
- koszyk, logowanie, rejestracja i konto klienta;
- formularze adresowe, wybór dostawy, zgody i komunikaty walidacyjne;
- bramka płatnicza oraz przekazanie do dostawcy płatności;
- e-maile, potwierdzenia, faktury, regulaminy i dokumenty PDF;
- zwroty, reklamacje, czat, infolinia i formularz kontaktowy;
- aplikacja mobilna, jeśli służy do zawarcia lub obsługi umowy.
W procesie płatności warto oddzielnie sprawdzić, czy fokus klawiatury jest widoczny, pola mają etykiety, błędy są jednoznaczne, a użytkownik może wrócić do wcześniejszego kroku bez utraty danych. Pomocny będzie artykuł Płatność online: wdrożenie, bezpieczeństwo i dostępność.
WCAGbot Accessibility Path: praktyczny plan działania
WCAGbot Accessibility Path porządkuje działania w taki sposób, aby szybkie wsparcie użytkownika nie zostało pomylone z pełnym procesem zapewniania dostępności.
Etap 1. Ustal zakres i właściciela procesu
Spisz usługi, produkty, kanały sprzedaży, podmioty zewnętrzne i role firmy. Wyznacz osobę, która zbiera decyzje zespołu UX, IT, e-commerce, compliance i obsługi klienta. Efektem ma być mapa zakresu, nie ogólne stwierdzenie „PAD nas dotyczy” albo „PAD nas nie dotyczy”.
Etap 2. Zmapuj rzeczywistą ścieżkę użytkownika
Przejdź proces jak klient: od wyszukiwania do potwierdzenia płatności i kontaktu po zakupie. Zapisz wszystkie miejsca, w których użytkownik podaje dane, podejmuje decyzję, otrzymuje błąd albo opuszcza serwis.
Etap 3. Wykonaj audyt i testy zadaniowe
Audyt powinien obejmować kod, treści i interakcje. Sprawdź obsługę klawiaturą, strukturę nagłówków, etykiety formularzy, kontrast, powiększenie, komunikaty statusu oraz współpracę z czytnikiem ekranu. ARIA może uzupełniać poprawny HTML, ale nie powinna maskować błędnej semantyki. Zobacz: ARIA: praktyczny poradnik wdrożenia i testowania oraz HTML semantyczny: praktyczny poradnik wdrożenia.
Etap 4. Priorytetyzuj naprawy źródłowe
Najpierw napraw bariery blokujące wykonanie zadania: brak obsługi klawiaturą, nieopisane pola, niewidoczny fokus, niedostępny przycisk, błędny komunikat walidacyjny czy nieosiągalny koszyk. Następnie zajmij się barierami utrudniającymi zrozumienie treści, takimi jak niski kontrast lub nieczytelna hierarchia nagłówków.
Widget dostępności, audyt i naprawa źródłowa
Etap 5. Dodaj funkcje wspierające dostępność
WCAGbot można uruchomić po wklejeniu jednej linii kodu, bez przebudowy strony. Narzędzie daje użytkownikowi między innymi tryby kontrastu, nasycenia i skali szarości, zmianę wielkości tekstu, interlinii i odstępów, czytanie treści, lupę, większy kursor, podświetlenie linków i nagłówków oraz możliwość zatrzymania animacji.
To użyteczny pierwszy krok, szczególnie gdy zespół równolegle planuje audyt i poprawki. Widget nie naprawi jednak błędnej kolejności fokusu, brakującej etykiety pola w kodzie, niejasnego błędu walidacji ani niedostępnej logiki płatności. Otwórz panel na własnej stronie, przetestuj kontrast, zwiększ tekst i sprawdź, czy możesz przejść kluczowy proces bez myszy.
Etap 6. Testuj po wdrożeniu i przy każdej zmianie
Po naprawie wykonaj test regresji. Nowy moduł marketingowy, zmiana szablonu Shopify, aktualizacja wtyczki WordPress lub nowa bramka płatnicza mogą wprowadzić kolejne bariery. Praktyczne checklisty znajdziesz w poradniku Testy po wdrożeniu: praktyczny poradnik i checklisty. Warto także uzupełnić testy techniczne o testy użytkowników.
Mini-scenariusz: sklep z niedostępnym koszykiem
Scenariusz ilustracyjny, nie opisuje wdrożenia u klienta WCAGbot. Sklep z wyposażeniem domu uruchamia nowy koszyk. Wizualnie wszystko działa poprawnie, ale użytkownik korzystający z klawiatury nie widzi, gdzie aktualnie znajduje się fokus. Po dodaniu produktu wysuwa się panel boczny, który przechwytuje fokus w nieprzewidywalny sposób. Komunikat o błędzie kodu rabatowego ma wyłącznie czerwony kolor i nie jest odczytywany przez czytnik ekranu.
Zespół nie powinien ograniczać się do dodania opcji większego tekstu lub kontrastu. Trwałe działania obejmują poprawę zarządzania fokusem, oznaczenie komunikatu jako programowo dostępnego statusu, dodanie tekstowej informacji o błędzie i sprawdzenie całej ścieżki koszyka. Równolegle WCAGbot może pozwolić użytkownikowi dostosować czytelność interfejsu do swoich potrzeb.
Jak dokumentować wdrożenie?
Dokumentacja nie musi być rozbudowanym raportem dla każdego drobnego poprawienia tekstu. Powinna jednak umożliwić zespołowi zrozumienie, co sprawdzono, jakie bariery znaleziono, kto odpowiada za naprawę i czy poprawka została przetestowana.
- lista usług, produktów i kanałów objętych analizą;
- mapa ścieżek użytkownika oraz systemów zewnętrznych;
- kryteria audytu i wyniki testów;
- rejestr błędów z priorytetem, właścicielem i terminem;
- decyzje dotyczące dostawców i komponentów zewnętrznych;
- wyniki testów regresji oraz testów z użytkownikami;
- opis wyjątków, jeżeli firma rozważa powołanie się na szczególne przesłanki ustawowe.
Ocena nieproporcjonalnego obciążenia lub zasadniczej zmiany nie powinna być ogólnym uzasadnieniem braku działań. Wymaga indywidualnej analizy i udokumentowania. Nie zastępuje też poprawy tych elementów, które można naprawić racjonalnym nakładem pracy.
Podsumowanie dla zarządzającego i sprzedaży
PAD wymaga podejścia procesowego. Firma powinna wiedzieć, jakie usługi i produkty oferuje, gdzie klient zawiera umowę oraz które bariery uniemożliwiają samodzielne skorzystanie z oferty. Największą wartość daje połączenie audytu, napraw źródłowych, testów i stałej kontroli zmian.
Dla zespołu sprzedaży i obsługi klienta dostępność oznacza mniej sytuacji, w których klient nie może dokończyć zakupu, wysłać formularza lub zrozumieć informacji. Dla zespołu technicznego oznacza konkretne wymagania jakościowe już na etapie projektowania, a nie kosztowną reakcję po publikacji.
Mapa dostępnej ścieżki zakupowej
Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot. Potraktuj je jako wsparcie użytkownika oraz pierwszy krok do dostępności, a równolegle zaplanuj audyt i trwałe usuwanie barier: Dodaj funkcje dostępności.
FAQ: Polski Akt o Dostępności
Czy PAD dotyczy każdego przedsiębiorcy?
Nie. Ustawa obejmuje określone produkty i usługi oraz konkretne role podmiotów gospodarczych. Aby ocenić sytuację firmy, trzeba ustalić model działalności, rodzaj usługi lub produktu oraz ewentualne wyłączenia.
Od kiedy obowiązuje Polski Akt o Dostępności?
Ustawa obowiązuje od 28 czerwca 2025 r. Przepisy zawierają jednak szczególne reguły przejściowe dotyczące między innymi wcześniej zawartych umów i istniejących terminali. Nie należy zakładać ogólnego odroczenia wszystkich obowiązków do 2030 r.
Czy sklep internetowy jest usługą handlu elektronicznego?
Sklep internetowy może być usługą handlu elektronicznego, gdy umożliwia zawarcie umowy na odległość drogą elektroniczną na indywidualne żądanie konsumenta. Wątpliwości należy ocenić na podstawie rzeczywistego procesu sprzedaży.
Czy mikroprzedsiębiorca nie musi wdrażać dostępności?
Wyłączenie dla mikroprzedsiębiorcy dotyczy usług, ale nie przesądza automatycznie o sytuacji firmy w odniesieniu do produktów. Niezależnie od zakresu ustawowego poprawa dostępności może ułatwiać klientom korzystanie z serwisu.
Czy PAD wymaga zgodności wyłącznie z WCAG 2.1 AA?
Nie należy upraszczać PAD wyłącznie do WCAG 2.1 AA. Ustawa, norma EN 301 549 i WCAG mają różne funkcje. WCAG jest bardzo ważnym narzędziem oceny stron i aplikacji, ale nie wyczerpuje wszystkich zagadnień związanych z dostępnością produktów i usług objętych PAD.
Czy widget dostępności zapewnia zgodność z PAD?
Nie. Widget może wspierać użytkownika przez dodatkowe ustawienia widoku i czytelności, ale nie zastępuje audytu, testów ani napraw w kodzie i treści. Nie powinien być przedstawiany jako gwarancja pełnej zgodności z PAD, WCAG lub EN 301 549.
Jak sprawdzić dostępność formularza?
Sprawdź, czy każde pole ma widoczną i programowo powiązaną etykietę, czy wymagania są jasne, czy błędy są opisane słowami oraz czy można obsłużyć formularz klawiaturą. Przetestuj też, czy po błędzie fokus trafia w przewidywalne miejsce.
Dlaczego test klawiaturą jest ważny?
Wiele osób korzysta z klawiatury zamiast myszy, stale albo czasowo. Test powinien potwierdzić, że użytkownik może dotrzeć do wszystkich istotnych elementów, widzi fokus, nie wpada w pułapkę klawiaturową i rozumie działanie komponentów.
Czy trzeba testować z czytnikiem ekranu?
Takie testy są ważnym uzupełnieniem automatycznych skanerów i przeglądu kodu. Pozwalają sprawdzić, czy nazwy kontrolek, nagłówki, komunikaty błędów i zmiany statusu są przekazywane użytkownikowi w zrozumiały sposób. Podstawy pracy z narzędziem opisuje poradnik NVDA: praktyczny poradnik testowania dostępności.
Czy stare dokumenty PDF są objęte PAD?
Ustawa przewiduje wyjątki dla określonych starszych treści, w tym dla niektórych dokumentów opublikowanych przed wejściem ustawy. Wyjątek nie oznacza jednak, że cała usługa cyfrowa staje się wyłączona. Trzeba ocenić konkretny dokument, jego datę, aktualność i rolę w procesie usługi.
Co zrobić jako pierwsze, gdy firma nie zna swojego poziomu dostępności?
Zacznij od kwalifikacji usługi, spisania ścieżek klienta i audytu krytycznych procesów: logowania, formularzy, koszyka, płatności oraz kontaktu po zakupie. Następnie usuń bariery blokujące zadania użytkownika i włącz dostępność do procesu każdej kolejnej zmiany.
Źródła i materiały
- ISAP – Dz.U. 2024 poz. 731
- gov.pl – Polski Akt o Dostępności: usługi handlu elektronicznego
- MFiPR – Jak prowadzić biznes zgodnie z Polskim Aktem o Dostępności
- ETSI
- W3C Web Content Accessibility Guidelines
- dostepnosc.pfron.gov.pl
- bd.uw.edu.pl
- dyrektywaeaa.kdkinfo.pl
- dyrektywaeaa.adninstytut.pl
- www.gov.pl
- dostepnosc.pfron.gov.pl
- samorzad.gov.pl
