Najważniejsze wnioski
- Sklep internetowy należy analizować jako usługę handlu elektronicznego, a nie wyłącznie jako stronę główną lub katalog produktów.
- PAD, norma EN 301 549 i wytyczne WCAG to trzy różne elementy: ustawa określa obowiązki, norma pomaga je technicznie oceniać, a WCAG wspiera testowanie interfejsu.
- Największe ryzyko barier zwykle występuje w wyszukiwarce, filtrach, wariantach produktu, koszyku, formularzach, logowaniu i płatności.
- Widget dostępności może ułatwić korzystanie ze sklepu dzięki funkcjom kontrastu, typografii, czytania treści i skupienia, ale nie zastępuje audytu ani naprawy kodu, treści i integracji płatniczych.
- Wyłączenie dla mikroprzedsiębiorcy wymaga sprawdzenia statusu firmy oraz zakresu konkretnej usługi; nie należy zakładać go automatycznie.
Dla zarządzającego
Dostępność sklepu warto potraktować jako element jakości usługi i zarządzania ryzykiem. Priorytetem jest decyzja, czy sklep podlega PAD, kto odpowiada za proces zakupowy oraz jaki budżet i harmonogram obejmą audyt, poprawki oraz utrzymanie.
Dla sprzedaży
Dostępny proces zakupu ogranicza sytuacje, w których klient nie może znaleźć produktu, wypełnić formularza lub opłacić zamówienia. Zespół sprzedaży i obsługi klienta powinien znać kanał zgłaszania barier oraz umieć przekazać problem do właściciela sklepu lub zespołu technicznego.
Stan prawny: [DO WERYFIKACJI: aktualność przepisów i materiałów urzędowych przed publikacją]. Artykuł ma charakter informacyjny i nie stanowi porady prawnej dopasowanej do sytuacji konkretnej firmy.
Polski Akt o Dostępności może dotyczyć sklepu internetowego, gdy sklep świadczy usługę handlu elektronicznego objętą ustawą. W praktyce nie wystarczy ocenić strony głównej. Trzeba sprawdzić cały proces: wyszukiwanie, filtry, kartę produktu, wybór wariantu, koszyk, formularze, logowanie, płatność, potwierdzenie zamówienia i obsługę posprzedażową.
Właściciel sklepu nie powinien zakładać ani że PAD z pewnością go nie dotyczy, ani że sam widget rozwiąże temat. Potrzebny jest uporządkowany proces: ocena zakresu usługi, testy, naprawy źródłowe, informacja dla klientów i stałe utrzymanie dostępności.
Najważniejsze wnioski
- PAD odnosi się do dostępności usług, w tym usług handlu elektronicznego, a nie tylko do wyglądu witryny.
- Kluczowy jest działający proces zakupu, także dla osoby korzystającej z klawiatury, czytnika ekranu lub powiększenia.
- EN 301 549 i WCAG pomagają przełożyć obowiązki na testy techniczne, ale nie są tym samym co ustawa.
- Funkcje WCAGbot mogą wesprzeć użytkownika od razu, jednak bariery w checkoutcie, kodzie formularza lub zewnętrznej płatności wymagają naprawy u źródła.
Czym jest Polski Akt o Dostępności dla e-commerce?
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 unijną dyrektywę 2019/882, znaną jako Europejski Akt o Dostępności.
Dla e-commerce ważne jest pojęcie usługi handlu elektronicznego. Obejmuje ono oferowanie lub świadczenie usługi na odległość, drogą elektroniczną, na indywidualne żądanie konsumenta, w celu zawarcia umowy. Dlatego sklep należy badać jako usługę zakupową, nie jako zbiór statycznych podstron.
Szersze tło unijnych regulacji omawia artykuł Europejski Akt o Dostępności: co oznacza dla firm. Właściciel sklepu powinien jednak przełożyć ogólny obowiązek na konkretne zadania w swoim katalogu, koszyku i procesie płatności.
Dostępny sklep nie kończy się na poprawnym nagłówku strony głównej. Jest dostępny wtedy, gdy użytkownik może samodzielnie znaleźć produkt, podjąć decyzję i zakończyć zakup.
Czy każdy sklep internetowy podlega PAD?
Nie należy odpowiadać na to pytanie automatycznie. W pierwszej kolejności trzeba ustalić, czy firma oferuje usługę handlu elektronicznego w rozumieniu ustawy, w jakiej roli działa oraz czy zastosowanie ma któreś z ustawowych wyłączeń.
Oficjalne materiały rządowe wskazują wyłączenie dla usług oferowanych lub świadczonych przez mikroprzedsiębiorcę. Nie oznacza to jednak, że każda mała firma może bez dalszej analizy uznać cały temat za nieaktualny. Należy ustalić status przedsiębiorcy, rodzaj usługi i ewentualne obowiązki dotyczące produktów, kontraktów albo wymagań partnerów biznesowych.
Wyłączenie prawne nie usuwa również potrzeby biznesowej. Niedostępny filtr, nieczytelny formularz lub przycisk niewidoczny po nawigacji klawiaturą pozostają barierą dla potencjalnego klienta.
Jak rozdzielić PAD, EN 301 549 i WCAG?
| Element | Rola w sklepie internetowym | Praktyczne zastosowanie |
|---|---|---|
| Polski Akt o Dostępności | Ustawa określająca wymagania i obowiązki dla objętych nią podmiotów. | Ustalenie zakresu usługi, informacji dla konsumentów, procedur i odpowiedzialności. |
| EN 301 549 | Norma techniczna dotycząca dostępności produktów i usług ICT. | Punkt odniesienia do planowania wymagań i oceny rozwiązania. |
| WCAG | Wytyczne dla dostępności treści internetowych. | Testy kontrastu, klawiatury, formularzy, struktury, komunikatów i kompatybilności. |
| Audyt WCAG | Ocena faktycznych barier w konkretnym serwisie. | Lista błędów, priorytety napraw i retesty. |
| WCAGbot | Narzędzie z funkcjami wspierającymi dostępność. | Pomoc użytkownikowi, np. kontrast, powiększenie tekstu, czytanie treści i skupienie. |
WCAGbot Accessibility Path dla sklepu internetowego
Nie należy sprowadzać PAD wyłącznie do hasła „WCAG 2.1 AA”. WCAG 2.1 AA: co oznacza i jak wdrożyć na stronie pomaga zrozumieć praktyczne kryteria, ale analiza obowiązków powinna zaczynać się od ustawy i aktualnego wykazu norm lub specyfikacji technicznych.
Co sprawdzić w sklepie internetowym?
Najlepiej testować sklep według realnej ścieżki klienta. Nie wystarczy kliknąć kilku elementów myszą. Potrzebne są testy klawiaturą, w różnych rozmiarach tekstu oraz — tam, gdzie to uzasadnione — z czytnikiem ekranu.
1. Wyszukiwanie, menu i filtry
- Czy wyszukiwarka ma widoczną etykietę i czy komunikat o wynikach jest zrozumiały?
- Czy filtry można obsłużyć klawiaturą bez utraty fokusu?
- Czy zaznaczenie opcji nie powoduje nieoczekiwanej zmiany kontekstu?
- Czy kolor nie jest jedyną informacją o aktywnym filtrze lub wybranym wariancie?
2. Karta produktu
- Czy zdjęcia produktowe mają adekwatny tekst alternatywny, gdy przekazują informację potrzebną do zakupu?
- Czy cena, promocja, dostępność i wariant są odczytywane w logicznej kolejności?
- Czy wybór rozmiaru, koloru lub konfiguracji ma właściwe etykiety?
- Czy przycisk dodania do koszyka działa klawiaturą i ma wyraźny fokus?
Wskazówki dotyczące struktury kodu zawiera poradnik HTML semantyczny: praktyczny poradnik wdrożenia, a poprawne użycie atrybutów i ról omawia tekst ARIA: praktyczny poradnik wdrożenia i testowania. ARIA nie zastępuje semantycznego HTML i nie powinna służyć do maskowania błędnej struktury interfejsu.
3. Koszyk, formularz i płatność
Checkout jest miejscem, w którym bariera ma bezpośredni skutek: użytkownik nie może sfinalizować zakupu. Sprawdź etykiety pól, wymagany format danych, komunikaty błędów, możliwość poprawienia wpisu, wybór dostawy, płatności i zgód oraz potwierdzenie zamówienia.
W praktyce warto zacząć od materiału Dostępny formularz: jak projektować i testować zgodnie z WCAG. Do testu samego procesu zakupowego przyda się także poradnik WCAG dla e-commerce: jak ułatwić zakupy online.
4. Klawiatura, fokus i czytnik ekranu
Przejdź przez sklep klawiszem Tab, Shift+Tab, Enter, Spacją oraz strzałkami tam, gdzie interfejs ich wymaga. Zapisz, czy fokus jest widoczny, czy nie znika pod sticky headerem albo oknem cookie i czy jego kolejność odpowiada kolejności wizualnej.
Pomocne są szczegółowe materiały o widocznym fokusie WCAG 2.4.7, fokusie niezasłoniętym WCAG 2.4.11 oraz testowaniu dostępności w NVDA.
WCAGbot Accessibility Path: jak zaplanować wdrożenie?
WCAGbot Accessibility Path porządkuje działania tak, aby szybka pomoc dla użytkownika nie była mylona z pełnym wdrożeniem dostępności.
- Ustal zakres. Opisz modele sprzedaży, kanały zakupu, dostawców checkoutu, płatności i obsługi klienta. Zweryfikuj, czy usługa podlega PAD oraz jakie wyłączenia mogą mieć znaczenie.
- Zmapuj ścieżkę zakupu. Wypisz wszystkie kroki od wejścia do sklepu po potwierdzenie zamówienia i kontakt po zakupie.
- Przeprowadź audyt i testy. Połącz automatyczne wykrywanie wybranych błędów z testami manualnymi. Priorytet nadaj barierom blokującym zakup.
- Napraw źródło problemu. Popraw kod HTML, komponenty, etykiety, teksty alternatywne, komunikaty błędów, style fokusu oraz integracje zewnętrzne.
- Dodaj funkcje wspierające. WCAGbot można uruchomić jedną linią kodu. Użytkownik może skorzystać m.in. z trybów kontrastu, powiększenia tekstu, regulacji interlinii, czytania treści, lupy, większego kursora czy podświetlania nagłówków i linków.
- Utrzymuj dostępność. Włącz kontrolę dostępności do procesu publikacji produktów, zmian motywu, aktualizacji checkoutu i kampanii promocyjnych.
PAD, EN 301 549 i WCAG — różne role
Doświadczeniowe CTA: przed podjęciem decyzji otwórz panel WCAGbot na własnej stronie, włącz kontrast, zwiększ tekst i spróbuj przejść do koszyka bez użycia myszy. To prosty sposób, aby odróżnić funkcję wspierającą od bariery wymagającej poprawki w sklepie.
Co widget dostępności pomaga zrobić, a czego nie naprawi?
Widget dostępności może być rozsądnym pierwszym krokiem. WCAGbot udostępnia funkcje, które użytkownik włącza zależnie od swoich potrzeb, w tym ustawienia kontrastu, nasycenia i skali szarości, narzędzia typograficzne, czytanie treści oraz funkcje skupienia i nawigacji. System może także automatycznie uzupełniać wybrane wykrywalne atrybuty ARIA, alt i title.
Nie oznacza to jednak, że widget naprawi każdą barierę. Nie zastąpi poprawnej etykiety w niestandardowym komponencie, logicznej kolejności fokusu, dostępnego komunikatu błędu, poprawnej obsługi modala ani testu zewnętrznej bramki płatniczej. Te problemy wymagają audytu i naprawy źródłowej. Granicę między tymi działaniami wyjaśnia artykuł Widget WCAG: co pomaga, a czego nie naprawi.
Mini-scenariusz: sklep z niedostępnym wyborem dostawy
Scenariusz ilustracyjny, nie opisuje wdrożenia u klienta. Sklep ma poprawny kontrast i widoczny fokus w menu, ale podczas checkoutu wybór dostawy otwiera panel, w którym fokus pozostaje na przycisku z poprzedniego kroku. Użytkownik klawiatury nie dociera do opcji dostawy, a czytnik ekranu nie komunikuje błędu.
W tym przypadku włączenie większego tekstu lub kontrastu może poprawić komfort części użytkowników, lecz nie rozwiąże blokady zakupu. Zespół powinien naprawić zarządzanie fokusem, semantykę komponentu, etykiety opcji i komunikat walidacyjny. Następnie należy powtórzyć test klawiaturą oraz z czytnikiem ekranu.
Jak przygotować informację o dostępności usługi?
Usługodawca powinien publicznie udostępnić informacje o oferowanej i świadczonej usłudze, informacje potrzebne do korzystania z niej oraz opis sposobu, w jaki usługa spełnia wymagania dostępności. Nie warto ograniczać się do zdania „strona jest zgodna z WCAG”.
Praktyczna informacja o dostępności usługi może obejmować:
- opis dostępnych kanałów korzystania ze sklepu i kontaktu;
- informację o testowanym zakresie procesu zakupowego;
- znane ograniczenia wraz z planem ich usunięcia, jeśli występują;
- kontakt do zgłaszania barier;
- alternatywny sposób uzyskania pomocy, gdy wystąpi problem w zakupie;
- datę ostatniego przeglądu dokumentu.
Jeżeli firma rozważa powołanie się na zasadniczą zmianę właściwości usługi lub nieproporcjonalne obciążenie, potrzebuje udokumentowanej oceny. Samo ogólne stwierdzenie o kosztach nie jest rzetelną podstawą takiej decyzji.
Dostępny checkout — punkty kontrolne
Podsumowanie dla zarządzającego i sprzedaży
Dla zarządzającego najważniejsza jest odpowiedzialność za całą usługę, również komponenty dostarczane przez platformę, motyw, integratorów oraz operatorów płatności. Warto wskazać właściciela procesu, stworzyć rejestr barier i ustalić, które problemy blokują zakup.
Dla sprzedaży i obsługi klienta priorytetem jest prosty kanał zgłaszania trudności oraz procedura przekazania problemu do zespołu technicznego. Informacja o dostępności powinna pomagać klientowi skorzystać z usługi, a nie być wyłącznie formalnym dokumentem.
Jeżeli potrzebujesz punktu startowego bez przebudowy sklepu, dodaj funkcje dostępności i przetestuj WCAGbot. Równolegle zaplanuj audyt oraz naprawy źródłowe w obszarach, których widget nie może poprawić.
FAQ: Polski Akt o Dostępności a sklep internetowy
Czy Polski Akt o Dostępności dotyczy każdego sklepu internetowego?
Nie należy zakładać tego bez analizy. Sklep może świadczyć usługę handlu elektronicznego objętą ustawą, ale znaczenie mają również status przedsiębiorcy, rola firmy i ustawowe wyłączenia. W razie wątpliwości warto skonsultować kwalifikację prawną z doradcą.
Od kiedy obowiązuje Polski Akt o Dostępności?
Ustawa weszła w życie 28 czerwca 2025 r. Przed publikacją procedur lub dokumentów wewnętrznych należy sprawdzić aktualne brzmienie przepisów w Elektronicznym Dzienniku Ustaw.
Czy mikroprzedsiębiorca musi dostosować sklep do PAD?
Oficjalne informacje wskazują wyłączenie dla usług oferowanych lub świadczonych przez mikroprzedsiębiorcę. Trzeba jednak prawidłowo ustalić status firmy i zakres usługi. Zwolnienie nie oznacza, że dostępność przestaje być ważna dla klientów i partnerów biznesowych.
Czy wystarczy wdrożyć WCAG 2.1 AA?
Nie. WCAG 2.1 jest ważnym punktem odniesienia przy testach interfejsu, ale PAD, EN 301 549 i WCAG pełnią różne funkcje. Ocena powinna obejmować wymagania ustawy, właściwe normy oraz faktyczne działanie usługi.
Czy widget WCAG zapewnia zgodność z PAD?
Nie. Widget może wspierać użytkownika poprzez funkcje kontrastu, typografii, czytania i nawigacji, ale nie zastępuje audytu, testów ani napraw źródłowych w kodzie, treści i integracjach.
Jakie elementy sklepu testować w pierwszej kolejności?
Zacznij od ścieżki, która prowadzi do zakupu: wyszukiwania, filtrów, karty produktu, wariantów, koszyka, formularza, wyboru dostawy, płatności i potwierdzenia zamówienia. Następnie sprawdź konto klienta i kontakt po zakupie.
Jak sprawdzić, czy checkout działa z klawiaturą?
Przejdź cały proces bez myszy. Użyj klawiszy Tab, Shift+Tab, Enter, Spacji i strzałek. Obserwuj widoczność fokusu, kolejność przejścia, możliwość wyboru opcji, obsługę błędów i powrót do pola wymagającego poprawy.
Czy trzeba publikować deklarację dostępności sklepu?
W przypadku usług objętych PAD należy udostępnić publicznie informacje o usłudze, informacje potrzebne do korzystania z niej oraz sposób, w jaki spełnia wymagania dostępności. Nie musi to być dokument o identycznej formie jak deklaracja stosowana przez podmioty publiczne.
Co zrobić, gdy klient zgłosi barierę dostępności?
Przyjmij zgłoszenie, odtwórz problem, określ wpływ na możliwość skorzystania z usługi, zaproponuj pomoc oraz przekaż błąd do właściciela technicznego. Ustawa zawiera procedurę skargową i terminy odpowiedzi, dlatego warto mieć udokumentowany proces obsługi takich spraw.
Czy niedostępna płatność zewnętrzna jest problemem sklepu?
Może być istotnym ryzykiem dla całego procesu zakupowego. Nawet gdy płatność dostarcza zewnętrzny operator, właściciel sklepu powinien ją testować, dokumentować problemy i uwzględniać dostępność przy wyborze dostawcy.
