Najważniejsze wnioski
- PAD dotyczy usług handlu elektronicznego oferowanych na odległość, drogą elektroniczną i na indywidualne żądanie konsumenta w celu zawarcia umowy.
- Ocena dostępności sklepu powinna obejmować całą ścieżkę zakupową: wyszukiwanie, filtry, produkt, koszyk, formularze, logowanie, płatność, potwierdzenie i obsługę posprzedażową.
- WCAG 2.1 A i AA są ważnym punktem odniesienia, ale PAD należy analizować szerzej, z uwzględnieniem ustawy, EN 301 549 oraz wymagań dla informacji, identyfikacji, bezpieczeństwa i płatności.
- Mikroprzedsiębiorca świadczący usługi może korzystać z wyłączenia przewidzianego w ustawie, lecz nie należy automatycznie przenosić tego wyłączenia na każdą sprzedaż produktów online.
- WCAGbot może szybko dodać funkcje wspierające dostępność użytkowników, ale nie zastępuje audytu, testów z użytkownikami ani naprawy źródłowej formularzy, kodu, treści i integracji płatniczych.
Dla zarządzającego
Dostępność e-commerce warto traktować jako element jakości usługi, obsługi klienta i zarządzania ryzykiem. Najrozsądniejszy plan to ustalenie zakresu, audyt krytycznej ścieżki zakupowej, priorytety napraw i udokumentowanie działań oraz ograniczeń.
Dla sprzedaży
Zespół sprzedaży i obsługi klienta powinien umieć rozpoznać zgłoszenie bariery, przekazać je do właściciela usługi oraz zapewnić dostępny kanał kontaktu. Szczególną uwagę warto poświęcić formularzom, płatnościom, kodom rabatowym, dostawie i komunikatom po złożeniu zamówienia.
Polski Akt o Dostępności (PAD) dotyczy e-commerce wtedy, gdy usługa umożliwia konsumentowi zawarcie umowy na odległość przez Internet. Dlatego właściciel sklepu nie powinien ograniczać analizy do strony głównej albo wyglądu karty produktu. Kluczowe są również wyszukiwarka, filtrowanie, wybór wariantu, koszyk, formularze, logowanie, dostawa, płatność, potwierdzenie zakupu i informacje po sprzedaży.
Ten poradnik ma charakter informacyjny, a nie jest indywidualną poradą prawną. Stan prawny: 28 czerwca 2025 r.; przed publikacją lub wykorzystaniem w decyzji biznesowej należy ponownie sprawdzić aktualne brzmienie przepisów oraz właściwość organu nadzoru.
Najważniejsze wnioski dla sklepu internetowego
- PAD nie jest wyłącznie tematem dla zespołu IT. Dotyka sprzedaży, UX, contentu, obsługi klienta, regulaminów i zewnętrznych dostawców płatności.
- Najlepszym punktem startowym jest mapa realnej ścieżki zakupowej, a nie ogólne sprawdzenie strony narzędziem automatycznym.
- WCAG pomaga ocenić wiele barier technicznych, lecz wymagań PAD nie należy sprowadzać wyłącznie do hasła „WCAG 2.1 AA”.
- Funkcje wspierające dostępność, takie jak kontrast, powiększenie tekstu czy czytanie treści, mogą ułatwić korzystanie z serwisu od razu. Nie naprawiają jednak błędnej semantyki, niedostępnego checkoutu ani nieopisanych komunikatów błędów.
Dostępny sklep nie kończy się na tym, że użytkownik widzi produkt. Musi jeszcze samodzielnie znaleźć go, zrozumieć ofertę, opłacić zamówienie i otrzymać informację o jego realizacji.
Czym jest Polski Akt o Dostępności w e-commerce?
Polski Akt o Dostępności to ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Jest polską regulacją wdrażającą dyrektywę 2019/882, znaną jako Europejski Akt o Dostępności. Szerszy kontekst unijny opisujemy w artykule Europejski Akt o Dostępności: co oznacza dla firm.
W ustawie usługi handlu elektronicznego są rozumiane szeroko. Chodzi o usługę oferowaną lub świadczoną na odległość, przez stronę internetową albo urządzenie mobilne, drogą elektroniczną, na indywidualne żądanie konsumenta i w celu zawarcia umowy. W praktyce może to obejmować klasyczny sklep internetowy, marketplace, serwis subskrypcyjny, platformę rezerwacyjną czy aplikację z zakupem.
Jeżeli potrzebujesz omówienia zakresu typowego sklepu internetowego, przeczytaj także Polski Akt o Dostępności: sklep internetowy i PAD. W tym artykule skupiamy się na planie działania, który można wykorzystać w projekcie wdrożeniowym.
Kogo może obejmować PAD i gdzie zachować ostrożność?
Najczęściej analizę należy przeprowadzić dla podmiotu prowadzącego sklep, marketplace albo usługę pozwalającą konsumentowi zawrzeć umowę online. Nie ma znaczenia, czy sprzedaż odbywa się na platformie SaaS, w WordPressie, Shopify czy w rozwiązaniu własnym. Znaczenie ma funkcja usługi i sposób jej świadczenia.
Szczególnej ostrożności wymaga temat mikroprzedsiębiorców. Ustawa przewiduje wyłączenie dla mikroprzedsiębiorcy świadczącego usługi, ale nie oznacza to automatycznie, że każda mikrofirma sprzedająca online jest wyłączona z każdego obowiązku. Dla produktów ustawa przewiduje odrębne zasady. Przed przyjęciem wyłączenia trzeba sprawdzić status przedsiębiorcy, charakter działalności, rolę w łańcuchu dostaw oraz aktualne przepisy.
Na marketplace’ach warto rozdzielić dwie kwestie: dostępność samej usługi platformy oraz wymagania dotyczące konkretnego produktu i informacji przekazywanych przez odpowiedni podmiot w łańcuchu dostaw. Operator platformy nie powinien zakładać, że obecność wielu sprzedawców zwalnia go z odpowiedzialności za dostępność własnego procesu zakupowego.
WCAGbot Accessibility Path dla e-commerce
Co w sklepie trzeba sprawdzić w pierwszej kolejności?
Ustawa wymaga, aby usługi były postrzegalne, funkcjonalne, zrozumiałe i kompatybilne. To kierunek zbliżony do zasad WCAG, ale w e-commerce trzeba dodatkowo patrzeć na funkcje związane z identyfikacją, bezpieczeństwem, płatnościami i podpisami elektronicznymi, jeżeli występują w usłudze.
1. Informacje, treści i komunikaty
Opis produktu, cena, rabat, dostępność towaru, warunki dostawy, zasady zwrotu, regulamin oraz komunikaty o błędzie muszą być możliwe do odebrania i zrozumienia. W praktyce oznacza to między innymi właściwy kontrast, tekst alternatywny dla istotnych obrazów, strukturę nagłówków, jasne linki i komunikaty, które nie opierają znaczenia wyłącznie na kolorze.
Warto pamiętać, że tekst alternatywny nie jest podpisem technicznym dla każdej grafiki. Ma przekazywać funkcję lub treść obrazu wtedy, gdy obraz jest istotny. Równie ważna jest semantyka HTML, którą omawiamy w poradniku HTML semantyczny: praktyczny poradnik wdrożenia.
2. Nawigacja, fokus i obsługa klawiaturą
Użytkownik powinien móc przejść przez menu, wyszukiwarkę, filtry, kartę produktu, koszyk i formularz bez myszy. Fokus musi być widoczny, mieć logiczną kolejność i nie może być zasłonięty przez baner, okno cookie lub element przyklejony do ekranu. Szczegółowe wskazówki znajdziesz w materiałach o widocznym fokusie WCAG 2.4.7 oraz WCAG 2.4.11 Focus Not Obscured.
3. Formularze, koszyk i checkout
To obszar o najwyższym priorytecie biznesowym. Każde pole powinno mieć programistycznie powiązaną etykietę. Błędy muszą wskazywać problem, podpowiadać sposób poprawy i być dostępne dla technologii wspomagających. Należy sprawdzić pola adresowe, checkboxy zgód, wybór dostawy, kod rabatowy, dane do faktury oraz przycisk złożenia zamówienia.
Jeżeli formularz korzysta z komunikatów dynamicznych, właściwe użycie ARIA może pomóc w przekazaniu zmian czytnikowi ekranu. ARIA nie naprawia jednak błędnej struktury ani nie zastępuje natywnych elementów HTML. Więcej na ten temat: ARIA: praktyczny poradnik wdrożenia i testowania.
4. Logowanie, bezpieczeństwo i płatność
Sprawdź, czy proces logowania nie wymaga wyłącznie rozpoznania obrazu, wykonania gestu niedostępnego dla części użytkowników albo szybkiej reakcji bez alternatywy. Następnie przetestuj przejście do zewnętrznego operatora płatności oraz powrót do sklepu. Nawet gdy część procesu realizuje dostawca zewnętrzny, warto udokumentować zakres odpowiedzialności i zgłaszać wykryte bariery partnerowi.
WCAG, EN 301 549 i PAD: jak je rozróżnić?
| Element | Rola | Jak wykorzystać w e-commerce? |
|---|---|---|
| Polski Akt o Dostępności | Ustawa określająca wymagania dla wskazanych produktów i usług. | Ustal zakres usługi, obowiązki informacyjne, wymagania dotyczące funkcji i procesu zakupowego. |
| EN 301 549 | Europejska norma dotycząca wymagań dostępności ICT. | Wykorzystaj jako techniczne odniesienie przy wymaganiach dla strony, aplikacji i dokumentacji. |
| WCAG | Wytyczne W3C dla treści internetowych. | Testuj m.in. kontrast, klawiaturę, strukturę, formularze, multimedia i kompatybilność z technologiami wspomagającymi. |
| Audyt i naprawa źródłowa | Proces wykrywania i usuwania konkretnych barier. | Planuj poprawki w kodzie, treści, szablonach, integracjach i procesach redakcyjnych. |
| Widget WCAGbot | Warstwa funkcji wspierających użytkownika. | Dodaj opcje kontrastu, typografii, czytania treści i skupienia jako szybkie wsparcie, równolegle z pracą nad barierami źródłowymi. |
Wytyczne dostępności wskazują przede wszystkim normę EN 301 549 V3.2.1 oraz WCAG 2.1 na poziomach A i AA jako ważne punkty odniesienia. Nie należy jednak komunikować, że sam wynik automatycznego testu albo deklaracja „WCAG 2.1 AA” przesądza o spełnieniu wszystkich wymagań PAD.
Widget dostępności a naprawa źródłowa
WCAGbot Accessibility Path: plan wdrożenia dla e-commerce
WCAGbot Accessibility Path porządkuje działania tak, aby zespół jednocześnie wspierał użytkowników teraz i usuwał najważniejsze bariery w trwały sposób.
- Ustal właściciela usługi i zakres. Zapisz domeny, aplikacje, subdomeny, checkout, systemy logowania, czat, dokumenty i zewnętrzne integracje.
- Rozpisz ścieżkę zakupu. Oprzyj ją na konkretnym scenariuszu: wyszukanie produktu, filtr, wariant, koszyk, dane, dostawa, płatność, potwierdzenie.
- Wykonaj testy manualne. Użyj klawiatury, powiększenia i czytnika ekranu. Praktyczny punkt startowy opisuje artykuł NVDA: praktyczny poradnik testowania dostępności.
- Uszereguj bariery. Najpierw rozwiązuj problemy blokujące zakup, logowanie, formularze, płatność lub kontakt z obsługą.
- Wprowadź naprawy źródłowe. Popraw komponenty, szablony, teksty, etykiety i obsługę błędów. Przy większym zakresie pomocny będzie plan audytu WCAG i wdrożenia.
- Dodaj funkcje wspierające dostępność. WCAGbot można uruchomić jedną linią kodu. Użytkownik otrzymuje m.in. tryby kontrastu, skalę szarości, powiększenie tekstu, zmianę interlinii, czytanie treści, lupę, większy kursor, przewodnik do czytania i sześć gotowych profili.
- Retestuj i dokumentuj. Po poprawkach powtórz scenariusz zakupu, opisz znane ograniczenia oraz udostępnij informację o dostępności usługi w dostępnym formacie.
Doświadczeniowe CTA: otwórz panel WCAGbot na własnej stronie testowej, zwiększ tekst, uruchom wybrany kontrast i przejdź klawiaturą przez menu oraz formularz. Taki test nie zastąpi audytu, ale szybko pokazuje, jak użytkownik może zmienić sposób odbioru treści.
Mini-scenariusz: sklep z niedostępnym checkoutem
Scenariusz ilustracyjny, nie opisuje wdrożenia u klienta. Sklep odzieżowy ma czytelne karty produktów, ale w koszyku pole kodu rabatowego ma etykietę wyświetlaną wyłącznie jako placeholder. Po wpisaniu błędnego kodu komunikat pojawia się czerwonym tekstem przy polu i nie jest ogłaszany przez czytnik ekranu. Ponadto po przejściu do płatności fokus trafia pod przyklejony baner promocyjny.
W tym przypadku zmiana kontrastu w panelu dostępności może ułatwić części użytkowników odczyt treści, ale nie usunie trzech źródłowych barier. Zespół powinien: dodać trwałą etykietę pola, zapewnić dostępny komunikat o błędzie, poprawić widoczność fokusu oraz ponownie przetestować cały krok płatności klawiaturą i czytnikiem ekranu. To właśnie różnica między funkcją wspierającą dostępność a naprawą wymaganą w kodzie usługi.
Jak przygotować informację o dostępności usługi?
Usługodawca powinien publicznie udostępniać informacje o usłudze, sposobie korzystania z niej oraz o tym, jak usługa spełnia wymagania dostępności. Informacje mogą znaleźć się w regulaminie albo w równoważnym dokumencie, ale muszą być dostępne dla osób ze szczególnymi potrzebami.
Praktyczna sekcja „Dostępność serwisu i zakupów online” może zawierać:
- zakres objętych stron, aplikacji i funkcji zakupowych;
- datę ostatniego przeglądu lub testu;
- opis sposobu testowania, np. klawiatura, czytnik ekranu, powiększenie;
- obsługiwane mechanizmy dostępności;
- znane ograniczenia opisane konkretnie, bez ukrywania ich za ogólnym hasłem;
- sposób zgłaszania problemu i alternatywny kanał kontaktu;
- plan lub status działań naprawczych, gdy jest dostępny.
Nie publikuj ogólnego zdania „strona jest w pełni dostępna”, jeśli nie masz aktualnych, udokumentowanych podstaw. Podobnie nie używaj określenia „certyfikat zgodności”, jeżeli nie opisuje ono rzeczywiście istniejącej i zweryfikowanej usługi.
Podsumowanie dla zarządzającego i sprzedaży
Dla zarządzającego priorytetem jest wskazanie właściciela procesu, budżetu na audyt i poprawki oraz kontroli nad zewnętrznymi integracjami. Dla sprzedaży i obsługi klienta kluczowe jest zebranie zgłoszeń o barierach, szybka ścieżka eskalacji i dostępna komunikacja z klientem. Wspólnym celem nie jest jednorazowe „odhaczenie” dostępności, lecz utrzymanie dostępnego procesu zakupowego także po zmianie szablonu, promocji, systemu płatności lub aplikacji.
Test dostępnej ścieżki zakupowej
Jeśli chcesz szerzej zaplanować dostępność sklepu, zobacz poradnik WCAG dla e-commerce: jak ułatwić zakupy online oraz materiał Widget WCAG: co pomaga, a czego nie naprawi.
FAQ: Polski Akt o Dostępności a e-commerce
Czy każdy sklep internetowy podlega Polskiemu Aktowi o Dostępności?
Nie należy zakładać tego automatycznie. Trzeba ocenić, czy dana działalność jest usługą handlu elektronicznego w rozumieniu ustawy, kto świadczy usługę oraz czy ma zastosowanie konkretne wyłączenie. Mikroprzedsiębiorca świadczący usługi może korzystać z wyłączenia ustawowego, ale sytuację trzeba sprawdzić indywidualnie.
Od kiedy PAD obowiązuje dla e-commerce?
Ustawa weszła w życie 28 czerwca 2025 r., z wyjątkami wskazanymi w przepisach. Przed podjęciem decyzji wdrożeniowej warto sprawdzić aktualne brzmienie ustawy i przepisy przejściowe dotyczące konkretnej usługi.
Czy WCAG 2.1 AA wystarczy, aby spełnić wymagania PAD?
WCAG 2.1 na poziomach A i AA jest istotnym punktem odniesienia, ale nie należy traktować go jako jedynego kryterium oceny PAD. Analiza powinna obejmować także wymagania ustawy, normę EN 301 549 oraz funkcje związane z informacją, identyfikacją, bezpieczeństwem i płatnościami.
Czy widget dostępności zapewnia zgodność z PAD?
Nie. Widget może wspierać użytkownika funkcjami takimi jak kontrast, powiększenie tekstu, czytanie treści lub większy kursor. Nie zastępuje jednak audytu, testów z użytkownikami ani naprawy źródłowej niedostępnych formularzy, komunikatów błędów, semantyki, integracji i płatności.
Jakie elementy checkoutu trzeba testować?
Testuj etykiety pól, obowiązkowość danych, opis błędów, kolejność fokusu, obsługę klawiaturą, checkboxy zgód, wybór dostawy, kupony, fakturę, przycisk zamówienia, przekierowanie do płatności i potwierdzenie zakupu.
Czy zewnętrzna bramka płatnicza zwalnia sklep z analizy dostępności?
Nie zwalnia z analizy całej ścieżki. Sklep powinien przetestować przejście do bramki i powrót do serwisu, określić zakres odpowiedzialności dostawcy oraz zgłaszać wykryte bariery. Szczegółowa odpowiedzialność prawna zależy od modelu usługi i umów.
Czy informacja o dostępności usługi jest tym samym co deklaracja dostępności?
Nie należy używać tych pojęć zamiennie bez analizy podstawy prawnej. W przypadku PAD istotne są obowiązki informacyjne dotyczące usługi i sposobu, w jaki spełnia ona wymagania dostępności. Treść powinna być konkretna, aktualna i dostępna dla użytkowników.
Jak szybko wykryć najważniejsze bariery w sklepie?
Przejdź najczęstszą ścieżkę zakupu wyłącznie klawiaturą, sprawdź widoczność fokusu, użyj czytnika ekranu do formularzy oraz przetestuj powiększenie tekstu. Następnie wykonaj profesjonalny audyt obejmujący reprezentatywne widoki, komponenty i integracje.
Czy automatyczne testy dostępności są wystarczające?
Nie. Narzędzia automatyczne wykrywają część problemów technicznych, ale nie ocenią w pełni sensu tekstu alternatywnego, logiczności komunikatów, jakości instrukcji, kolejności procesu zakupowego czy rzeczywistej obsługi płatności przez czytnik ekranu.
Co jest lepsze na początek: audyt czy szybkie funkcje wspierające dostępność?
Najlepiej realizować oba działania równolegle. Audyt wskazuje bariery i priorytety napraw źródłowych, a WCAGbot może szybko dodać użytkownikom opcje ułatwiające odbiór treści. Jedno działanie nie zastępuje drugiego.
Jak utrzymać dostępność po wdrożeniu?
Dodaj kontrolę dostępności do procesu publikacji produktów, kampanii, zmian w szablonach i wdrożeń zewnętrznych integracji. Powtarzaj test krytycznej ścieżki zakupowej po większych zmianach oraz aktualizuj informację o dostępności usługi.
Chcesz zacząć od praktycznego wsparcia użytkowników? Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot.
Źródła i materiały
- Elektroniczny System Aktów Prawnych, ustawa z 26 kwietnia 2024 r.
- Ministerstwo Cyfryzacji
- Główny Urząd Statystyczny, Społeczeństwo informacyjne w Polsce w 2025 r.
- Materiały informacyjne udostępnione w serwisie gov.pl
- www.gov.pl
- digital-strategy.ec.europa.eu
- www.etsi.org
- www.w3.org
- www.gov.pl
- digital-strategy.ec.europa.eu
- isap.sejm.gov.pl
- accessible-eu-centre.ec.europa.eu
