W skrócie10 min czytania

Najważniejsze wnioski

  • PAD to ustawa o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Obejmuje między innymi usługi handlu elektronicznego.
  • W e-commerce trzeba oceniać cały proces zakupowy: wejście do sklepu, wyszukanie produktu, wybór wariantu, koszyk, formularze, płatność, potwierdzenie i kontakt z obsługą.
  • PAD, norma EN 301 549 i wytyczne WCAG nie są tym samym. Ustawa określa obowiązki prawne, EN 301 549 jest normą techniczną, a WCAG pomaga projektować i testować interfejs.
  • Widget dostępności może być szybkim pierwszym krokiem wspierającym użytkowników, ale nie zastępuje audytu, testów klawiaturą i czytnikiem ekranu ani napraw źródłowych w kodzie i treści.
  • Wdrożenie powinno obejmować właściciela biznesowego, UX, development, treści, dostawcę płatności oraz obsługę klienta — zwłaszcza procedurę przyjmowania i rozpatrywania skarg.
Dla zarządzającego

Jeżeli firma świadczy usługę objętą PAD, dostępność należy potraktować jako element jakości usługi i zarządzania ryzykiem, a nie jednorazowy projekt techniczny. Priorytetem jest decyzja o zakresie, właścicielu procesu, budżecie na audyt i poprawki oraz kontroli kluczowej ścieżki klienta.

Dla sprzedaży

Dostępny proces zakupowy ogranicza bariery dla klientów korzystających z klawiatury, czytników ekranu, powiększenia lub ustawień kontrastu. Zespół sprzedaży i obsługi powinien znać kanał zgłoszeń dostępności, umieć przekazać problem do właściwego zespołu i nie obiecywać pełnej zgodności bez potwierdzenia.

Polski Akt o Dostępności (PAD) wymaga od części firm zapewniania dostępności określonych produktów i usług, w tym usług handlu elektronicznego. Dla sklepu internetowego nie oznacza to wyłącznie poprawy kontrastu strony głównej. Trzeba sprawdzić, czy klient może samodzielnie przejść przez istotne etapy zakupu — także klawiaturą, z czytnikiem ekranu, przy powiększeniu treści lub z własnymi ustawieniami kontrastu.

Stan prawny: 28 czerwca 2025 r. Tekst ma charakter informacyjny, nie jest indywidualną poradą prawną. Przed podjęciem decyzji dotyczącej konkretnej firmy należy potwierdzić aktualne brzmienie przepisów, zakres usługi i rolę przedsiębiorcy.

Najważniejsze wnioski

  • PAD jest ustawą wdrażającą europejskie wymagania dostępności dla wskazanych produktów i usług.
  • Handel elektroniczny należy do obszarów, które wymagają szczególnej analizy pod kątem PAD.
  • Ocena powinna obejmować pełną ścieżkę klienta, a nie wyłącznie stronę główną lub pojedynczy formularz.
  • WCAG i EN 301 549 pomagają przełożyć wymagania na działania projektowe oraz techniczne, ale nie są tożsame z ustawą.
  • Funkcje widgetu mogą wspierać użytkownika od razu, natomiast trwałe bariery wymagają audytu i naprawy źródłowej.

Czym jest Polski Akt o Dostępności?

Polski Akt o Dostępności 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, często określaną jako Europejski Akt o Dostępności lub EAA.

Ustawa reguluje między innymi wymagania dla produktów i usług, obowiązki podmiotów gospodarczych, nadzór rynku, skargi konsumenckie oraz sankcje. Dla firm cyfrowych najczęściej istotne są usługi handlu elektronicznego, bankowość detaliczna, usługi telekomunikacyjne, dostęp do audiowizualnych usług medialnych oraz określone cyfrowe elementy transportu pasażerskiego.

Jeżeli potrzebujesz szerszego spojrzenia na relację prawa unijnego i polskiej ustawy, zobacz również artykuł Europejski Akt o Dostępności: wdrożenie krok po kroku.

Dostępność nie zaczyna się od deklaracji i nie kończy na wtyczce. Zaczyna się tam, gdzie użytkownik ma wykonać samodzielnie konkretną czynność.

Kogo może dotyczyć PAD w e-commerce?

W przypadku usług odpowiedzialność co do zasady spoczywa na usługodawcy. W e-commerce warto analizować nie tylko to, kto jest właścicielem domeny, ale też kto faktycznie oferuje usługę, zarządza procesem zakupu, publikuje informacje dla klientów i obsługuje zgłoszenia.

Materiały Gov.pl dotyczące usług handlu elektronicznego wskazują, że chodzi o usługi umożliwiające zawieranie umów na odległość przez strony internetowe lub aplikacje mobilne. Dlatego analiza powinna objąć zarówno własny sklep, jak i elementy procesu realizowane przez systemy zewnętrzne.

Czy mikroprzedsiębiorca jest wyłączony z obowiązków?

Ustawa co do zasady nie stosuje się do usług oferowanych lub świadczonych przez mikroprzedsiębiorców. Nie należy jednak automatycznie przenosić tego wyłączenia na wszystkie sytuacje. Dotyczy ono usług, a obowiązki związane z produktami mogą wymagać odrębnej analizy roli producenta, importera lub dystrybutora.

Nie traktuj statusu mikroprzedsiębiorcy jako argumentu za rezygnacją z dostępności. Dostępny sklep nadal może zmniejszać liczbę przerwanych procesów, zgłoszeń do obsługi i barier dla klientów.

PAD, EN 301 549 i WCAG — czym się różnią?

ElementRolaJak wykorzystać w firmie?
Polski Akt o DostępnościUstawa określająca obowiązki prawne dla wskazanych produktów i usług.Ustal zakres obowiązków, informacje dla klientów, procedurę skarg i odpowiedzialność organizacyjną.
EN 301 549Europejska norma techniczna dotycząca wymagań dostępności produktów i usług ICT.Wykorzystaj jako punkt odniesienia przy specyfikacji, zakupach, audycie i odbiorze prac.
WCAGWytyczne W3C dotyczące dostępności treści internetowych.Stosuj do projektowania i testowania treści, komponentów oraz interakcji na stronie.
WCAGbotWidget z funkcjami wspierającymi dostępność użytkownika.Dodaj jako szybkie wsparcie, równolegle planując audyt i naprawy źródłowe.
flow

WCAGbot Accessibility Path dla usługi e-commerce

1Ustal, czy usługa i podmiot mieszczą się w zakresie PAD2Wyznacz właściciela procesu oraz kluczowe ścieżki użytkownika3Wykonaj audyt i testy manualne4Napraw bariery w kodzie, treści i procesach5Dodaj funkcje wspierające dostępność6Opublikuj informacje o usłudze i obsługuj zgłoszenia
Plan diagramu pokazujący kolejność działań: od oceny zakresu PAD do stałego monitorowania dostępności.

Nie należy sprowadzać wymagań PAD wyłącznie do hasła „WCAG 2.1 AA”. Ustawa, norma i wytyczne działają na różnych poziomach. Pomocny kontekst techniczny znajdziesz w poradniku EN 301 549 w e-commerce: wdrożenie krok po kroku oraz w materiale Poziom AA WCAG: praktyczny poradnik wdrożenia.

Co sprawdzić w sklepie internetowym?

W praktyce dostępność sklepu internetowego należy oceniać jako ciąg działań użytkownika. Pojedyncza poprawna podstrona nie wystarczy, jeśli bariera pojawia się w koszyku albo po przejściu do płatności.

1. Wejście, wyszukiwanie i wybór produktu

  • Czy menu, wyszukiwarka, filtry i sortowanie działają z klawiatury?
  • Czy fokus jest widoczny, a aktywny element nie chowa się pod przyklejonym nagłówkiem lub banerem?
  • Czy produkt ma zrozumiałą nazwę, cenę, status dostępności i sensowny opis?
  • Czy obraz produktu ma właściwy tekst alternatywny, gdy obraz przekazuje ważną informację?

Przydatne uzupełnienie stanowią poradniki o widocznym fokusie klawiatury oraz o semantycznym HTML.

2. Koszyk, formularze i komunikaty błędów

Formularz jest dostępny wtedy, gdy użytkownik rozumie cel pola, może je obsłużyć bez myszy i otrzymuje czytelną informację, co poprawić. Sama czerwona ramka nie jest wystarczającym komunikatem błędu.

  • Każde pole powinno mieć programowo powiązaną etykietę.
  • Błędy powinny wskazywać pole i wyjaśniać sposób poprawy.
  • Obowiązkowość, format danych i konsekwencje działania powinny być zrozumiałe przed wysłaniem formularza.
  • Zmiana liczby produktów, ceny lub kosztu dostawy powinna być zakomunikowana użytkownikowi technologii asystującej.

Jeżeli sklep używa ARIA, trzeba stosować ją ostrożnie i po testach. Więcej na ten temat wyjaśnia wpis ARIA: praktyczny poradnik wdrożenia i testowania.

3. Płatność i potwierdzenie

Płatność online często angażuje zewnętrznego operatora. Nie zwalnia to jednak właściciela sklepu z potrzeby sprawdzenia całej ścieżki użytkownika, w tym czy przekazanie do bramki płatniczej jest jasne oraz czy po powrocie użytkownik otrzymuje zrozumiałe potwierdzenie.

Przeczytaj także: Płatność online: wdrożenie, bezpieczeństwo i dostępność.

WCAGbot Accessibility Path: jak zaplanować wdrożenie?

WCAGbot Accessibility Path porządkuje działania, ale nie jest procedurą prawną ani substytutem audytu. To praktyczny model dla zespołu, który chce zacząć od ryzyk istotnych dla użytkownika i równolegle wdrożyć szybkie wsparcie.

  1. Ustal zakres. Spisz usługi, kanały sprzedaży, aplikacje, formularze i integracje. Zweryfikuj, czy firma podlega PAD oraz w jakim zakresie.
  2. Wybierz ścieżki krytyczne. Dla sklepu będą to zwykle wyszukanie produktu, karta produktu, koszyk, logowanie, rejestracja, dostawa, płatność, potwierdzenie i kontakt.
  3. Przeprowadź audyt. Połącz test automatyczny z przeglądem eksperckim, testem klawiaturą, czytnikiem ekranu i powiększeniem. Automaty nie wykryją wszystkich barier.
  4. Napraw źródło problemu. Popraw kod, strukturę nagłówków, etykiety, komunikaty, komponenty, kontrast i treści. Wprowadź kryteria dostępności do procesu tworzenia zmian.
  5. Dodaj wsparcie użytkownika. WCAGbot można uruchomić jedną linią kodu. Widget oferuje między innymi tryby kontrastu, powiększenie tekstu, czytanie treści, podświetlanie elementów, większy kursor i profile wspierające różne potrzeby.
  6. Testuj po zmianach. Każda istotna aktualizacja motywu, checkoutu, formularza lub integracji może wprowadzić nową barierę.
  7. Utrzymuj proces. Przygotuj informacje o dostępności usługi, kanał zgłoszeń i sposób przekazywania problemów do zespołu odpowiedzialnego za naprawę.
comparison

PAD, EN 301 549 i WCAG — trzy różne poziomy

1PAD: obowiązki prawne dla wskazanych produktów i usług2EN 301 549: norma techniczna dotycząca wymagań dostępności ICT3WCAG: wytyczne dla treści i interfejsów internetowych4Audyt: ocena faktycznego działania usługi5Testy użytkowników: sprawdzenie realnych barier6Widget: wsparcie użytkownika, nie dowód pełnej zgodności
Plan tabelarycznej grafiki wyjaśniającej relację między ustawą, normą techniczną i wytycznymi dla interfejsów.

Doświadczeniowe CTA: uruchom WCAGbot na stronie testowej lub własnej witrynie, a następnie sprawdź kontrast, zwiększ tekst, włącz czytanie treści i przejdź klawiaturą przez najważniejszy formularz. Takie sprawdzenie pokaże, które funkcje są pomocne od razu, a które bariery wymagają poprawki w źródle.

Mini-scenariusz: sklep z barierą w koszyku

Scenariusz ilustracyjny — nie opisuje rzeczywistego klienta ani wdrożenia. Sklep oferuje produkty przez stronę internetową. Strona główna ma poprawiony kontrast, lecz w koszyku przyciski „zwiększ liczbę” i „usuń” nie mają dostępnej nazwy dla czytnika ekranu. Formularz dostawy pokazuje błąd wyłącznie kolorem, a po wyborze płatności fokus znika poza widocznym obszarem.

Zespół nie powinien uznać, że problem został rozwiązany przez dodanie panelu dostępności. W pierwszej kolejności powinien naprawić nazwy kontrolek, powiązania etykiet, komunikaty błędów i zarządzanie fokusem w kodzie. Następnie warto dodać funkcje wspierające dostępność, takie jak powiększenie tekstu, czytelna czcionka lub tryby kontrastu, aby użytkownik mógł dostosować sposób odbioru strony do swoich potrzeb.

Po wdrożeniu należy wykonać ponowny test klawiaturą oraz test z czytnikiem ekranu, np. zgodnie z podejściem opisanym w artykule NVDA: praktyczny poradnik testowania dostępności. Warto również zaplanować testy po wdrożeniu, zamiast kończyć pracę na odbiorze technicznym.

Jak przygotować obsługę skarg i informacje dla klientów?

Usługodawca powinien publicznie przekazać informacje o usłudze, informacje potrzebne do korzystania z niej oraz informacje o sposobie spełniania wymagań dostępności. Szczegóły opisuje materiał Gov.pl o obowiązkach informacyjnych w PAD.

Operacyjnie warto przygotować prostą procedurę:

  1. opublikuj dostępny kanał zgłoszeń i wskaż możliwe formy kontaktu;
  2. zapisz, kto odbiera zgłoszenie i kto klasyfikuje problem;
  3. ustal sposób przekazania zgłoszenia do UX, developmentu, treści lub dostawcy zewnętrznego;
  4. odpowiadaj językiem konkretnym: co wykryto, jakie działanie podjęto i jaki jest kolejny krok;
  5. prowadź rejestr zgłoszeń, decyzji, poprawek i retestów.

Ustawa przewiduje co do zasady 30 dni na rozpatrzenie skargi. W sprawie szczególnie skomplikowanej termin może zostać wydłużony maksymalnie do 60 dni po poinformowaniu konsumenta o przyczynie opóźnienia. Szczegółowe warunki wynikają z tekstu ustawy i wymagają potwierdzenia dla konkretnego przypadku.

Czego nie rozwiąże sam widget dostępności?

Widget dostępności może pomóc użytkownikowi dostosować widok strony, np. zwiększyć tekst, zmienić kontrast, zatrzymać animacje lub skorzystać z czytania treści. Nie naprawi jednak automatycznie każdej bariery.

Naprawy źródłowej wymagają zwykle między innymi: nieobsługiwane klawiaturą komponenty, błędna kolejność fokusu, brak opisów pól, nieczytelne komunikaty błędów, wadliwe okna modalne, niedostępny checkout, błędy semantyki HTML oraz treści niezrozumiałe bez dodatkowego kontekstu.

WCAGbot automatycznie uzupełnia wybrane atrybuty ARIA, alt i title w elementach, które potrafi wykryć. Nie jest to jednak zamiennik redakcyjnego opisu obrazu, poprawnej semantyki ani testów działania konkretnego komponentu. Rzetelna strategia łączy funkcje wspierające dostępność z audytem i systematycznym usuwaniem barier.

Podsumowanie dla zarządzającego i sprzedaży

Dla zarządzającego najważniejsza decyzja brzmi: czy dostępność jest częścią procesu rozwoju usługi, czy jedynie reakcją na problem. W pierwszym wariancie firma ma właściciela procesu, listę priorytetowych ścieżek, kryteria odbioru, plan poprawek oraz sposób obsługi zgłoszeń.

mockup

Dostępna ścieżka zakupu w sklepie internetowym

1Wyszukiwarka i filtry obsługiwane klawiaturą2Czytelna nazwa, cena i dostępność produktu3Opisowe etykiety pól formularza4Widoczny fokus i komunikaty błędów przy polach5Dostępna metoda płatności i przekazanie do operatora6Potwierdzenie zamówienia oraz kontakt z obsługą
Plan makiety przedstawiającej punkty kontrolne od listy produktów do potwierdzenia zamówienia.

Dla sprzedaży i obsługi klienta dostępność oznacza przede wszystkim możliwość pomocy bez tworzenia dodatkowych barier. Zespół powinien umieć przyjąć zgłoszenie, przekazać je do realizacji i poinformować klienta o dalszym kroku. Nie powinien deklarować zgodności z PAD lub WCAG wyłącznie na podstawie instalacji widgetu.

Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot jako praktyczny pierwszy krok. Równolegle zaplanuj audyt, testy oraz naprawy źródłowe najważniejszych elementów usługi.

FAQ: Polski Akt o Dostępności

Czy Polski Akt o Dostępności dotyczy każdego sklepu internetowego?

Nie należy zakładać, że każda firma bez wyjątku podlega PAD. Handel elektroniczny jest objęty zakresem ustawy, ale trzeba ocenić konkretną usługę, rolę przedsiębiorcy oraz ustawowe wyłączenia. W szczególności należy ostrożnie analizować status mikroprzedsiębiorcy i zakres faktycznie świadczonej usługi.

Od kiedy obowiązuje Polski Akt o Dostępności?

Ustawa zasadniczo weszła w życie 28 czerwca 2025 r. Przepisy zawierają jednak szczególne zasady dotyczące między innymi produktów wprowadzonych do obrotu przed tą datą, umów zawartych wcześniej i określonych terminali.

Czy PAD oznacza obowiązek zgodności wyłącznie z WCAG 2.1 AA?

Nie. PAD jest ustawą, EN 301 549 jest normą techniczną, a WCAG to wytyczne dostępności treści internetowych. WCAG może być bardzo użyteczne przy realizacji wymagań dla interfejsu, ale nie wyczerpuje wszystkich obowiązków organizacyjnych i informacyjnych wynikających z PAD.

Czy mikroprzedsiębiorca musi zapewnić dostępność sklepu?

Ustawa co do zasady wyłącza usługi oferowane lub świadczone przez mikroprzedsiębiorców. To nie oznacza automatycznie wyłączenia wszystkich możliwych obowiązków związanych z produktami ani braku korzyści z dostępności. Indywidualną kwalifikację warto potwierdzić na podstawie aktualnych przepisów i modelu działalności.

Czy widget dostępności zapewnia zgodność z PAD?

Nie. Widget może wspierać dostępność, dając użytkownikowi funkcje takie jak kontrast, powiększenie tekstu czy czytanie treści. Nie zastępuje jednak audytu, testów z użytkownikami, testów klawiaturą ani trwałych poprawek w kodzie i treści.

Jak sprawdzić dostępność koszyka i płatności?

Przejdź całą ścieżkę bez myszy: wybierz produkt, zmień liczbę sztuk, usuń pozycję, wpisz dane, wywołaj błędy walidacji, wybierz dostawę i płatność. Następnie powtórz test z czytnikiem ekranu oraz przy powiększeniu. Sprawdź też, czy integracja z operatorem płatności nie przerywa zrozumiałej ścieżki.

Jakie informacje o dostępności usługi trzeba przekazać klientowi?

Usługodawca powinien przekazać informacje o oferowanej i świadczonej usłudze, informacje niezbędne do korzystania z niej oraz informacje o sposobie spełniania wymagań dostępności. Informacje powinny być dostępne dla osób ze szczególnymi potrzebami.

Co powinna zawierać skarga dotycząca braku dostępności?

Ustawa wskazuje między innymi dane osoby składającej skargę, dane kontaktowe i preferowany sposób kontaktu, wskazanie produktu lub usługi, opis niespełnionego wymagania oraz żądanie zapewnienia dostępności. Firma powinna przygotować zespół do przyjmowania takich zgłoszeń w dostępny sposób.

Co oznacza nieproporcjonalne obciążenie?

Nie jest to ogólne stwierdzenie, że poprawki są kosztowne. Ustawa przewiduje ocenę opartą na konkretnych kryteriach, takich jak koszty, korzyści, skala korzystania, zasoby podmiotu czy koszty zmian procesowych. Ocena powinna być udokumentowana, a jej zastosowanie nie może być automatyczne.

Czy test automatyczny wystarczy do wykrycia problemów?

Nie. Test automatyczny pomaga wychwycić część błędów, ale nie potwierdzi na przykład, czy proces zakupu jest zrozumiały, czy fokus porusza się logicznie albo czy komunikat błędu rzeczywiście pomaga użytkownikowi. Potrzebne są testy manualne oraz, gdy to możliwe, testy z użytkownikami.

Źródła i materiały

  1. Elektroniczny Dziennik Ustaw
  2. Gov.pl — Polski Akt o Dostępności: usługi handlu elektronicznego
  3. Elektroniczny Dziennik Ustaw
  4. Gov.pl — Obowiązki informacyjne w PAD
  5. dostepnosc.pfron.gov.pl
  6. www.etsi.org
  7. www.w3.org
  8. www.parp.gov.pl
  9. www.gov.pl
  10. www.gov.pl
  11. uke.gov.pl
  12. rf.gov.pl
Graf wiedzy

Powiązane zagadnienia