Najważniejsze wnioski
- Polski Akt o Dostępności obejmuje usługę handlu elektronicznego rozumianą jako proces zawarcia umowy na odległość, a nie wyłącznie stronę główną sklepu.
- Dostępność trzeba oceniać na całej ścieżce: wyszukiwanie produktu, karta produktu, koszyk, formularze, logowanie, dostawa, płatność i komunikacja po zakupie.
- WCAG jest ważnym punktem odniesienia technicznego, ale PAD nie sprowadza się do hasła „WCAG 2.1 AA”; dla usług e-commerce należy uwzględniać ustawę oraz właściwą normę EN 301 549.
- Widget dostępności może być szybkim pierwszym krokiem wspierającym użytkownika, lecz nie zastępuje audytu, testów procesu zakupowego ani trwałej naprawy barier w kodzie i treści.
- Sklep powinien mieć przypisaną odpowiedzialność za obsługę skarg, dokumentowanie decyzji i usuwanie wykrytych barier w kolejności ryzyka dla użytkownika.
Dla zarządzającego
Dostępność w e-commerce warto traktować jako element jakości usługi i zarządzania ryzykiem operacyjnym. Decyzja zarządcza powinna objąć właściciela procesu, budżet na audyt i naprawy, kontrolę dostawców oraz sposób reagowania na zgłoszenia użytkowników.
Dla sprzedaży
Dla sprzedaży dostępność oznacza mniej barier na drodze do złożenia zamówienia. Zespół powinien umieć przekazać klientowi jasną informację o funkcjach usługi, odebrać zgłoszenie bariery i skierować je do osoby odpowiedzialnej za naprawę.
Polski Akt o Dostępności dla e-commerce oznacza konieczność spojrzenia na sklep jak na kompletną usługę zakupową. Nie wystarczy ocenić strony głównej ani samej karty produktu. Klient musi mieć możliwość samodzielnego znalezienia oferty, przeczytania informacji, wypełnienia formularza, wyboru dostawy, przejścia płatności i odebrania komunikatu o wyniku transakcji.
Stan prawny opisany w tym artykule: 5 sierpnia 2026 r. Materiał ma charakter informacyjny i nie stanowi porady prawnej. Zakres obowiązków konkretnej firmy zależy między innymi od jej roli, rodzaju oferowanej usługi oraz statusu przedsiębiorstwa.
Najważniejsze wnioski
- PAD dotyczy dostępności usługi handlu elektronicznego, nie tylko warstwy wizualnej witryny.
- Największe ryzyko praktyczne zwykle leży na ścieżce zakupu: w filtrach, formularzach, logowaniu, koszyku i płatności.
- EN 301 549 i WCAG pomagają przełożyć wymagania na kryteria techniczne, ale nie wyczerpują całego kontekstu usługi wynikającego z ustawy.
- Funkcje wspierające dostępność mogą poprawić komfort korzystania ze strony od razu, lecz bariery w strukturze, kodzie i procesach wymagają naprawy źródłowej.
Czym jest Polski Akt o Dostępności w e-commerce?
Polski Akt o Dostępności, czyli ustawa o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług, wdraża do polskiego prawa Europejski Akt o Dostępności. W przypadku handlu internetowego istotne jest pojęcie usługi handlu elektronicznego: usługi oferowanej lub świadczonej na odległość, drogą elektroniczną, na indywidualne żądanie konsumenta i w celu zawarcia umowy.
W praktyce może to obejmować klasyczny sklep online, rezerwację usługi z płatnością, aplikację zakupową albo proces zawarcia umowy prowadzony przez stronę i urządzenie mobilne. Pierwszym zadaniem nie jest więc wybór narzędzia, ale ustalenie, który podmiot odpowiada za poszczególne elementy usługi.
Jeżeli potrzebujesz podstawowego omówienia zakresu, przeczytaj także: Czy Polski Akt o Dostępności dotyczy sklepu online?. Szerszy kontekst zmian i obowiązków przedstawia również przewodnik po PAD dla e-commerce.
Dostępny sklep nie kończy się na stronie, którą da się przeczytać. Kończy się dopiero wtedy, gdy użytkownik może samodzielnie sfinalizować sprawę, dla której na tę stronę przyszedł.
Kogo może dotyczyć PAD i dlaczego status firmy trzeba sprawdzić osobno?
W e-commerce kluczowy jest zwykle usługodawca oferujący lub świadczący usługę handlu elektronicznego. Ustawa przewiduje wyłączenie dla usług oferowanych lub świadczonych przez mikroprzedsiębiorcę. Nie należy jednak zamieniać tego przepisu w skrót „mała firma jest zwolniona”. Mikroprzedsiębiorca jest kategorią ustawową, a nie potocznym określeniem niewielkiego biznesu.
WCAGbot Accessibility Path dla e-commerce
W dodatku przepisy dotyczące usług i produktów mają odrębne zasady. Sklep, marketplace, producent, importer, operator płatności i dostawca platformy mogą mieć inne role. Dlatego warto udokumentować odpowiedzi na cztery pytania:
- Czy firma oferuje usługę prowadzącą do zawarcia umowy z konsumentem?
- Czy działa jako usługodawca, sprzedawca, pośrednik czy dostawca technologii?
- Czy spełnia ustawowe warunki mikroprzedsiębiorcy?
- Które etapy procesu realizują zewnętrzni dostawcy, na przykład bramka płatnicza lub system rezerwacji?
Co trzeba sprawdzić w sklepie internetowym?
Ustawa wymaga, aby informacje i elementy usługi były postrzegalne, funkcjonalne, zrozumiałe i kompatybilne. To znane cztery zasady dostępności cyfrowej, ale ich zastosowanie w sklepie wymaga badania pełnego zadania użytkownika.
Informacje o produkcie i warunkach zakupu
Sprawdź opisy produktów, ceny, warianty, dostępność, koszty dostawy, regulaminy, politykę zwrotów oraz komunikaty o ograniczeniach. Tekst powinien być możliwy do odczytania, mieć logiczną strukturę nagłówków, odpowiedni kontrast i zrozumiałe linki. Obrazy pełniące funkcję informacyjną potrzebują adekwatnego tekstu alternatywnego, a nie automatycznej nazwy pliku.
Praktyczną listę kontroli znajdziesz w materiale Dostępność sklepu internetowego – checklista pierwszych kroków.
Formularze, koszyk i błędy
Formularz dostawy powinien mieć trwałe etykiety pól, jasne wymagania i komunikaty błędów, które mówią co należy poprawić. Użytkownik klawiatury musi widzieć aktualne miejsce fokusu, a osoba korzystająca z czytnika ekranu powinna otrzymać informację o błędzie i zmianie ceny lub dostępności.
W praktyce sprawdź między innymi, czy można:
- dodać i usunąć produkt bez używania myszy;
- zmienić liczbę sztuk oraz wariant produktu;
- zrozumieć, dlaczego kod rabatowy nie zadziałał;
- wrócić do błędnego pola bez utraty wpisanych danych;
- zamknąć okno modalne i wrócić do właściwego miejsca na stronie.
Logowanie, bezpieczeństwo i płatność
To obszar, którego nie wolno pominąć w audycie. Art. 18 ustawy obejmuje funkcje identyfikacji, bezpieczeństwa, płatności, podpisów elektronicznych oraz usług płatniczych będących częścią e-commerce. Dostępny katalog nie rozwiązuje problemu, jeżeli klient nie może zalogować się, przejść weryfikacji, zrozumieć komunikatu operatora płatności lub zatwierdzić transakcji.
W umowach z dostawcami checkoutu, płatności i narzędzi antyfraudowych warto określić sposób zgłaszania barier, terminy reakcji oraz zakres testów po aktualizacji integracji.
PAD, EN 301 549 i WCAG: jak nie pomylić pojęć?
| Pojęcie | Rola w e-commerce | Jak wykorzystać w pracy zespołu |
|---|---|---|
| Polski Akt o Dostępności | Ustawa określająca wymagania i obowiązki dotyczące wskazanych produktów oraz usług. | Ustal zakres, role, proces obsługi skarg, dokumentację i odpowiedzialność. |
| EN 301 549 | Norma techniczna wskazywana dla wymagań dostępności usług e-commerce. | Przełóż wymagania na plan testów technologii, treści i interfejsu. |
| WCAG | Wytyczne dotyczące dostępności treści internetowych, istotne dla stron i aplikacji. | Wykorzystaj do oceny kontrastu, klawiatury, formularzy, struktury i komunikatów. |
| Widget dostępności | Narzędzie zapewniające użytkownikowi dodatkowe ustawienia prezentacji i obsługi. | Traktuj jako wsparcie i pierwszy krok, nie jako dowód pełnej zgodności. |
Widget dostępności a naprawa źródłowa
Najbezpieczniej nie używać zdania „PAD to po prostu WCAG 2.1 AA”. WCAG jest ważne, ale ustawa odnosi się do szerszego procesu usługi, w tym do funkcji płatności, identyfikacji i bezpieczeństwa. Różnice między WCAG 2.1, WCAG 2.2 i normą opisuje artykuł WCAG 2.1, WCAG 2.2 i EN 301 549 – czym się różnią?.
WCAGbot Accessibility Path: jak zaplanować rozsądne działania?
WCAGbot Accessibility Path to prosty schemat organizacyjny dla sklepu, który chce połączyć szybkie wsparcie użytkowników z trwałą poprawą usługi.
- Ustal zakres. Zapisz kanały sprzedaży, systemy, integracje i właścicieli etapów zakupu.
- Zmapuj ścieżkę. Przejdź od znalezienia produktu do potwierdzenia zamówienia. Uwzględnij także konto klienta, zwroty i pomoc.
- Uruchom wsparcie natychmiastowe. Dodaj funkcje poprawiające dostępność, które użytkownik może sam włączyć, na przykład kontrast, większy tekst, czytanie treści lub wyróżnienie fokusu.
- Wykonaj audyt i testy zadaniowe. Testuj klawiaturą, czytnikiem ekranu i na urządzeniach mobilnych. Nie ograniczaj testu do strony głównej.
- Napraw źródłowo. Popraw komponenty, semantykę HTML, etykiety, opisy, komunikaty, kolejność fokusu oraz logikę procesu.
- Utrzymuj jakość. Dodaj dostępność do odbioru nowych funkcji, publikacji treści i kontroli aktualizacji dostawców.
WCAGbot można uruchomić przez jedną linię kodu na stronach WordPress, Shopify, HTML i innych platformach. Panel daje użytkownikowi między innymi tryby kontrastu, narzędzia typograficzne, czytanie treści, większy kursor, przewodnik do czytania, zatrzymywanie animacji oraz sześć profili wspierających różne potrzeby. System może również automatycznie uzupełniać wybrane wykrywalne atrybuty ARIA, alt i title.
To użyteczne wsparcie, ale nie zastąpi poprawy błędnie zbudowanego formularza, niedostępnej bramki płatności, niejasnej walidacji czy informacji ukrytej tylko w obrazie. Granice tego podejścia omawia tekst Widget dostępności a zgodność z WCAG: uczciwe porównanie.
Doświadczeniowe CTA: po uruchomieniu panelu ustaw większy tekst, włącz wybrany kontrast i spróbuj wykonać zakup wyłącznie klawiaturą. Takie krótkie ćwiczenie pomaga rozdzielić poprawę komfortu prezentacji od barier wymagających naprawy w produkcie.
Dostępna ścieżka zakupu
Mini-scenariusz: gdzie sklep może stracić dostępność?
Scenariusz ilustracyjny, nie opis rzeczywistego wdrożenia: sklep z kosmetykami ma poprawny wizualnie katalog i umożliwia powiększenie tekstu. Użytkownik wybiera produkt klawiaturą, ale po kliknięciu „Dodaj do koszyka” komunikat o powodzeniu pojawia się tylko wizualnie. Następnie w formularzu dostawy pola mają placeholdery zamiast trwałych etykiet. Po błędzie kodu pocztowego formularz oznacza pole kolorem czerwonym, nie wyjaśnia jednak błędu tekstowo.
W tym przypadku funkcje kontrastu i powiększenia pozostają wartościowym wsparciem, lecz nie rozwiązują problemów źródłowych. Plan naprawy powinien obejmować komunikat programowo dostępny dla technologii asystujących, właściwe etykiety pól i opis błędu połączony z konkretnym polem. Dopiero po retestach można uznać zadanie za zakończone.
Jak podejść do skarg i nieproporcjonalnego obciążenia?
PAD przewiduje możliwość złożenia przez konsumenta skargi dotyczącej braku spełniania wymagań dostępności. Firma powinna mieć prosty, dostępny kanał przyjęcia zgłoszenia oraz wewnętrzną ścieżkę jego obsługi. Ustawowy termin rozpatrzenia skargi wynosi 30 dni, a w sprawie szczególnie skomplikowanej może zostać wydłużony maksymalnie do 60 dni po poinformowaniu konsumenta.
Nieproporcjonalne obciążenie nie jest automatycznym uzasadnieniem dla zaniechania działań. Ustawa wiąże taką ocenę z konkretnymi kryteriami, a podmiot gospodarczy sporządza jej dokumentację. Warto rozdzielić dwa przypadki: rzeczywiście złożoną zmianę wymagającą udokumentowanej oceny oraz zwykły dług techniczny, który można zaplanować i usunąć etapami.
Plan na najbliższy cykl rozwojowy sklepu
- Wyznacz właściciela dostępności po stronie biznesu i technologii.
- Wypisz wszystkie ścieżki prowadzące do zawarcia umowy, także na urządzeniach mobilnych.
- Przetestuj klawiaturą koszyk, formularz, logowanie i płatność.
- Sprawdź strukturę nagłówków, kontrast, linki, opisy alternatywne i komunikaty błędów.
- Ustal z dostawcami zewnętrznymi sposób zgłaszania oraz usuwania barier.
- Dodaj funkcje wspierające dostępność jako pomoc dla użytkowników już teraz.
- Wprowadź audyt i testy dostępności do definicji ukończenia nowych funkcji.
Jeżeli chcesz zacząć od szybkiej konfiguracji, zobacz instrukcję Jak zainstalować WCAGbot na stronie. Zakres funkcji, które użytkownik może włączyć samodzielnie, opisujemy w artykule Kontrast, większy tekst i czytanie treści w WCAGbot.
FAQ: Polski Akt o Dostępności dla e-commerce
Czy Polski Akt o Dostępności dotyczy każdego sklepu internetowego?
Nie należy zakładać tego automatycznie. Trzeba ocenić, czy firma oferuje lub świadczy usługę handlu elektronicznego w rozumieniu ustawy, jaką pełni rolę oraz czy ma zastosowanie wyłączenie dla usług mikroprzedsiębiorcy.
Rejestr barier i decyzji dostępnościowych
Od kiedy wymagania dotyczą usług e-commerce?
Ustawa stosuje się do usług od 28 czerwca 2025 r., przy czym w konkretnych sytuacjach należy sprawdzić także przepisy przejściowe i zakres usługi.
Czy PAD oznacza obowiązek spełnienia WCAG 2.1 AA?
Nie warto upraszczać tego w ten sposób. WCAG jest istotne dla dostępności treści i interfejsów, ale PAD obejmuje szersze wymagania dotyczące świadczenia usługi. Ministerstwo wskazuje EN 301 549 jako właściwą normę techniczną dla usług e-commerce.
Czy wystarczy zainstalować widget dostępności?
Nie. Widget może wspierać użytkownika przez funkcje kontrastu, typografii, czytania lub fokusu, ale nie naprawi samodzielnie wszystkich barier w formularzach, strukturze kodu, treści, logice koszyka czy płatności.
Co w sklepie należy przetestować w pierwszej kolejności?
Najpierw ścieżki o największym znaczeniu dla klienta: wyszukanie produktu, karta produktu, dodanie do koszyka, formularz, logowanie, wybór dostawy, płatność i potwierdzenie zamówienia.
Czy bramka płatnicza jest odpowiedzialnością sklepu?
Funkcje płatności są elementem usługi e-commerce, dlatego nie należy ich pomijać. W praktyce odpowiedzialność kontraktowa i techniczna może być podzielona z dostawcą, ale sklep powinien uwzględnić ten etap w ocenie ryzyka i procedurze zgłaszania barier.
Jak sprawdzić sklep bez specjalistycznych narzędzi?
Wykonaj pełne zamówienie samą klawiaturą. Sprawdź widoczność fokusu, kolejność przechodzenia między elementami, działanie okien modalnych, komunikaty błędów i możliwość finalizacji płatności. To nie zastępuje audytu, ale szybko ujawnia część krytycznych problemów.
Czy automatyczny skaner wystarczy do audytu WCAG?
Nie. Skaner może wykryć część błędów technicznych, lecz nie oceni poprawnie kontekstu treści, zrozumiałości komunikatów, jakości alternatyw tekstowych ani całej ścieżki transakcyjnej z perspektywy użytkownika.
Czy sklep musi publikować deklarację dostępności?
Nie należy przenosić automatycznie obowiązków znanych z sektora publicznego na prywatny e-commerce. Warto natomiast przekazywać użytkownikom rzetelne informacje o dostępności usługi i zapewnić łatwy kontakt w sprawie barier, zgodnie z zakresem obowiązków mających zastosowanie do firmy.
Co oznacza nieproporcjonalne obciążenie?
To ustawowy wyjątek wymagający indywidualnej oceny, a nie ogólne stwierdzenie, że poprawki są kosztowne. Ocena powinna uwzględniać kryteria ustawowe i zostać udokumentowana.
Jaką rolę może pełnić WCAGbot w planie dostępności?
WCAGbot może być szybkim pierwszym krokiem: użytkownik otrzymuje dodatkowe ustawienia kontrastu, tekstu, czytania i nawigacji bez przebudowy strony. Równolegle zespół powinien prowadzić audyt oraz naprawę źródłową barier.
Podsumowanie
Polski Akt o Dostępności dla e-commerce wymaga myślenia o dostępności jako o jakości całej usługi, a nie pojedynczego ekranu. Najlepszy plan łączy wsparcie dostępne od razu dla użytkownika, audyt kluczowych ścieżek oraz systematyczne usuwanie barier w kodzie, treści i integracjach.
Dodaj funkcje dostępności i wykorzystaj WCAGbot jako praktyczny pierwszy krok, a następnie zaplanuj audyt oraz trwałe naprawy tam, gdzie użytkownik napotyka barierę.
Źródła i materiały
- Elektroniczny Dziennik Ustaw – ocena nieproporcjonalnego obciążenia
- Gov.pl – Polski Akt o Dostępności: usługi handlu elektronicznego
- Gov.pl – wykaz norm zharmonizowanych i specyfikacji technicznych
- www.w3.org
- www.etsi.org
- www.gov.pl
- pzn.org.pl
- www.parp.gov.pl
- pzn.org.pl
- digital-strategy.ec.europa.eu
- digital-strategy.ec.europa.eu
- uke.gov.pl
