- Strategia oparta o dane i cele biznesowe.
- Rekomendacje UX, integracji i automatyzacji.
- Plan wdrożeń i wsparcie zespołu.
28 czerwca 2025 roku wejdzie w życie dla podmiotów sektora prywatnego obowiązek wynikający z Polskiego Aktu o Dostępności (Ustawa z dnia 26 kwietnia 2023 r. o dostępności cyfrowej). Dla sklepów internetowych, platform e-commerce i serwisów sprzedaży online oznacza to, że serwis musi spełniać wymagania dostępności cyfrowej zgodne z WCAG 2.1 AA — albo wykazać, że nieproporcjonalne obciążenie uniemożliwia pełne wdrożenie. To nie jest nowe rozporządzenie „na papierze” — to ustawa z realnym mechanizmem egzekucji przez Prezesa Zarządu PFRON i możliwością nałożenia kar.
PAD implementuje unijną dyrektywę o dostępności produktów i usług (European Accessibility Act, EAA) i jest częścią szerszego europejskiego ruchu w kierunku dostępności cyfrowej. Dyrektywa objęła usługi elektroniczne — w tym e-commerce — jako obszar o strategicznym znaczeniu dla inclusion osób z niepełnosprawnościami, których w Polsce jest ponad 3,3 mln (GUS, 2023). Dla firm, które ignorowały dostępność przez lata, 28 czerwca to data, po której „nie wiedziałem” przestaje być tarczą.
Przeprowadzimy audyt dostępności Twojego sklepu, naprawimy krytyczne błędy i przygotujemy deklarację dostępności — zanim wejdzie w życie termin PAD.
Kogo dotyczy PAD w sektorze e-commerce
PAD dotyczy podmiotów sektora prywatnego świadczących usługi drogą elektroniczną, jeśli ich działalność wykracza poza „mikroprzedsiębiorstwo” w rozumieniu dyrektywy — czyli firma zatrudniająca mniej niż 10 pracowników i z rocznymi obrotami lub sumą bilansową nieprzekraczającą 2 mln EUR jest z obowiązku zwolniona. Dla pozostałych — w tym małych firm z przychodami powyżej tego progu — obowiązek jest realny. Sklep internetowy generujący kilkaset tysięcy złotych obrotu miesięcznie i zatrudniający kilkanaście osób mieści się w zakresie ustawy.
Praktyczne wymagania PAD dla sklepu e-commerce to: zgodność z WCAG 2.1 AA dla serwisu www (strony produktowe, koszyk, checkout, konto klienta, formularze), opublikowanie deklaracji dostępności na stronie z opisem stanu zgodności i mechanizmem zgłaszania problemów, oraz wyznaczenie kanału kontaktowego, przez który użytkownicy mogą zgłaszać bariery dostępności i oczekiwać odpowiedzi w ciągu 30 dni. Brak deklaracji dostępności to jeden z najłatwiej wykrywalnych i najczęściej egzekwowanych naruszeń — i od tego zazwyczaj zaczyna się kontrola.
Co WCAG 2.1 AA oznacza dla sklepu WooCommerce
WooCommerce jako platforma ma relatywnie dobrą bazę dostępności w standardowych motywach i komponentach — ale większość sklepów używa niestandardowych motywów, wtyczek do page builderów i custom komponentów (quick view, filtry, konfiguratory), które dostępność łamią. Badanie WebAIM dotyczące najczęstszych błędów WCAG na stronach e-commerce wskazuje, że 94% stron ma przynajmniej jeden błąd poziomu A lub AA, a najczęstsze to: niski kontrast kolorów (68% stron), brakujący tekst alt (58%), niepoprawne etykiety formularzy (51%) i niedostępna nawigacja klawiaturą (43%).
Szczególnie wrażliwe miejsca w sklepie WooCommerce to: strona produktu (galeria zdjęć bez alt, dynamiczne warianty bez informacji dla screen readera, przycisk „Dodaj do koszyka” bez czytelnej etykiety), filtrowanie i wyszukiwanie produktów (filtry AJAX często łamią focus management), checkout (pola formularza bez poprawnych etykiet, błędy bez powiązania z polem, brak aria-live dla dynamicznych komunikatów), popup’y i modalne okna (brak zarządzania focusem, niemożność zamknięcia klawiaturą). Każdy z tych elementów można naprawić — i powinien być naprawiony przed 28 czerwca 2025.
Deklaracja dostępności — od czego zacząć
Deklaracja dostępności to dokument opublikowany na stronie (zazwyczaj dostępny z każdej podstrony w stopce lub przez dedykowany link), który opisuje: jaki standard dostępności serwis spełnia (WCAG 2.1 AA), w jakim zakresie jest zgodny (w pełni / częściowo / niezgodny z wykazem wyjątków), datę ostatniego przeglądu dostępności, dane kontaktowe do zgłaszania problemów i terminy odpowiedzi. Wzór deklaracji i szczegółowe wytyczne dotyczące jej treści opisaliśmy w osobnym artykule — znajdziesz go tutaj.
Deklaracja jest dokumentem żywym — powinna być aktualizowana co roku lub po większych zmianach serwisu. Firmy, które opublikowały deklarację „raz” w 2023 roku i jej nie aktualizowały, a serwis w tym czasie przeszedł redesign — mają nieaktualne informacje, co jest naruszeniem tak samo realnym jak brak deklaracji w ogóle. Mechanizm zgłaszania problemów (adres email lub formularz) musi być aktywny i monitorowany — odpowiedź na zgłoszenie w ciągu 30 dni to wymóg ustawowy.
Nieproporcjonalne obciążenie — kiedy można się powołać
PAD, podobnie jak dyrektywa EAA, przewiduje klauzulę „nieproporcjonalnego obciążenia” — firma może wskazać elementy, których wdrożenie wymaga nakładów niewspółmiernych do korzyści dla użytkowników z niepełnosprawnościami. Brzmi jak wyjście awaryjne — ale w praktyce jest bardzo wąskie. Klauzula wymaga formalnego uzasadnienia z analizą kosztów i korzyści, nie może obejmować całości serwisu (tylko konkretnych elementów), i musi być udokumentowana w deklaracji dostępności. Regulatorzy europejscy konsekwentnie orzekają, że standardowe elementy sklepu (checkout, formularze, nawigacja) nie kwalifikują się do tego wyjątku — koszt ich naprawy jest proporcjonalny do prowadzonej działalności.
Plan działań przed 28 czerwca 2025
Realny plan dla sklepu e-commerce z kilkoma miesiącami do terminu: zacznij od audytu automatycznego (Axe DevTools, WAVE, Lighthouse w Chrome DevTools) — 1–2 godziny, daje listę oczywistych błędów. Następnie przetestuj ręcznie kluczowe ścieżki klawiaturą i screen readerem (NVDA dla Windows, VoiceOver dla Mac) — checkout musi działać bez myszy. Zleć naprawę błędów krytycznych (poziom A i AA na checkoucie, formularzach i stronach produktowych) deweloperowi — to jest praca na kilka dni do tygodnia. Opublikuj deklarację dostępności — wzór i wytyczne w artykule o informacji o dostępności i artykule o priorytetach naprawczych WCAG. Skonfiguruj kanał zgłaszania problemów.
Dostępność to nie jednorazowy projekt — to standard jakości, który powinien być wbudowany w proces tworzenia i aktualizacji serwisu. Firmy, które traktują PAD jako „kolejny compliance checkbox do odhaczenia”, będą wracać do napraw po każdej większej aktualizacji. Firmy, które wbudują dostępność w swoje procesy (testy w CI/CD, szkolenia dla zespołu, przegląd przy wdrożeniu nowych komponentów) — nie będą mieć z tym problemu.
