Jak przygotować sklep Shoper do wymogów WCAG i Europejskiego Aktu o Dostępności

PAD może obejmować sklep Shoper, jeśli przedsiębiorca świadczy konsumentom usługę handlu elektronicznego i nie korzysta z ustawowego wyłączenia. EAA to unijna dyrektywa o dostępności produktów i usług, a polska ustawa wdrażająca jej wymagania jest nazywana Polskim Aktem o Dostępności. Wymagania obowiązują od 28 czerwca 2025 r.; informacje sprawdziliśmy w październiku 2026 r. w serwisie Gov.pl.

PAD nie stosuje się do usług oferowanych lub świadczonych przez mikroprzedsiębiorców. Ocena, czy firma ma taki status i czy konkretna usługa korzysta z wyłączenia, wymaga uwzględnienia jej sytuacji; sama platforma Shoper tego nie rozstrzyga. Przy wątpliwościach dotyczących obowiązku prawnego skonsultuj firmę i usługę ze specjalistą.

Usługa handlu elektronicznego to zdalne oferowanie lub świadczenie usługi przez stronę albo urządzenie mobilne, drogą elektroniczną, na indywidualne żądanie konsumenta i w celu zawarcia umowy. Zakres oceny dotyczy usługi oraz całej ścieżki zakupowej, również elementów pochodzących z aplikacji i usług zewnętrznych.

Usługodawca objęty PAD powinien publicznie udostępnić informacje o oferowanej i świadczonej usłudze, informacje niezbędne do korzystania z niej oraz opis tego, jak usługa spełnia wymagania dostępności. Gov.pl wskazuje, że informację należy przekazać w dostępnej formie, na przykład w regulaminie świadczenia usług handlu elektronicznego lub dokumencie równoważnym. Zakres obowiązku sprawdziliśmy w październiku 2026 r.

Lista testów w tym artykule jest praktycznym punktem wyjścia opartym na WCAG 2.2 AA. WCAG oznacza wytyczne dostępności treści internetowych; wymagania prawne PAD należy oceniać według ustawy i wymagań dostępności dotyczących usługi. Gov.pl publikuje dla usług handlu elektronicznego wykaz norm obejmujący EN 301 549 V3.2.1 z 2021 r. Testy opisane w artykule nie stanowią automatycznego potwierdzenia spełnienia PAD.

Jeśli potrzebujesz określić zakres sprawdzenia i uporządkować kolejne prace, audyt cyfrowy sklepu i procesu zakupowego może pomóc przygotować plan oceny.

Zacznij od inwentaryzacji widoków i elementów Shoper, które klient napotyka podczas zakupu. Uwzględnij aktywny motyw, jego moduły, aplikacje, treści, konfigurację płatności i połączenia z systemami zewnętrznymi.

W panelu Shoper aktywny motyw sprawdzisz w obszarze "Wygląd i treści > Wygląd sklepu > Edycja szablonu graficznego". Nazwy lub układ zakładek mogą zależeć od wersji panelu. Dokumentacja Shoper opisuje też wcześniejszą ścieżkę "Wygląd i treści > Wygląd sklepu > Obecny szablon graficzny". Zmiany układu modułów sprawdź najpierw w kopii lub środowisku testowym, jeśli jest dostępne.

Listę aplikacji znajdziesz w panelu pod "Aplikacje i integracje > Zainstalowane aplikacje"; starsza wersja panelu mogła używać nazwy "Dodatki i integracje > Moje aplikacje". Sprawdź zwłaszcza dodatki, które wyświetlają warianty, komunikaty, okna modalne lub dodatkowe pola w koszyku. W dokumentacji aplikacji zweryfikuj, kto może poprawić jej komponent i jak zgłosić problem.

Plan inwentaryzacji:
1. Zapisz adresy i typy widoków: kategorię, kartę produktu, koszyk, formularz, konto i potwierdzenie zamówienia.
2. Wypisz aktywne moduły motywu, aplikacje, metody płatności i integracje używane w zakupie.
3. Wybierz reprezentatywny produkt z wariantem, informacją o dostępności i metodą dostawy.
4. Przejdź przykładowy zakup na komputerze i telefonie, zapisując bariery oraz właścicieli zmian.

Właściciel sklepu może koordynować poprawki treści i konfiguracji, a wykonawca motywu lub dostawca aplikacji może odpowiadać za zmiany techniczne. Audyt dostępności WCAG pomoże rozdzielić problemy treści, motywu i integracji.

Motyw Shoper przechodzi podstawowy test nawigacji, gdy każdą funkcję można obsłużyć klawiaturą, fokus wskazuje aktualny element, a zmiana rozmiaru tekstu nie ukrywa treści. W tej procedurze stosujemy WCAG 2.2 AA jako praktyczny poziom odniesienia, a nie samodzielną ocenę ustawowego obowiązku PAD.

Otwórz sklep bez myszy i naciskaj Tab oraz Shift+Tab. Sprawdź menu kategorii, wyszukiwarkę, przyciski modułów i przejście do głównej treści. Następnie zwiększ rozmiar tekstu do 200%, a osobno sprawdź układ strony przy szerokości odpowiadającej 320 pikselom CSS. Te testy sprawdzają czytelność tekstu oraz możliwość przeglądania treści bez przewijania w dwóch kierunkach.

Tabela odpowiada na pytanie, jak ręcznie sprawdzić nawigację i układ motywu. Oczekiwane wyniki opisują podstawowe kontrole WCAG, które warto uwzględnić w ocenie sklepu.

Tabela rozdziela test powiększenia tekstu od kontroli układu przy wąskim widoku. Po zmianie motywu sprawdź ponownie kategorię i kartę produktu, bo moduły mogą zachowywać się odmiennie.

Automatyczny skaner wskazuje część błędów technicznych, ale nie ocenia samodzielnie logicznej kolejności menu, sensu opisów ani możliwości przejścia całego zakupu. Wynik skanu uzupełnij testem ręcznym.

Karta produktu Shoper powinna przekazywać nazwę, cenę, dostępność, warianty i funkcję przycisku zakupu bez polegania wyłącznie na kolorze lub położeniu. W formularzach każde pole powinno mieć widoczną etykietę, a błąd powinien wskazać problem i sposób jego poprawy.

W opisie produktu sprawdź, czy nazwa wariantu jest widoczna i możliwa do odczytania przez technologię asystującą. Jeżeli aplikacja dodaje wybór koloru, rozmiaru lub personalizacji, przetestuj go na karcie produktu oraz po dodaniu do koszyka. Zmiana wariantu nie powinna być sygnalizowana wyłącznie kolorem obramowania.

Tekst alternatywny zdjęcia powinien opisywać istotną dla zakupu cechę obrazu. Dla obrazu dekoracyjnego właściwy może być pusty tekst alternatywny, o ile motyw pozwala go ustawić. Nie powielaj tytułu produktu, jeśli opis zdjęcia nie wnosi dodatkowej informacji.

Przykłady komunikatów:
- Błąd: "Pole obowiązkowe" bez wskazania pola i sposobu poprawy.
- Lepiej: "Podaj adres e-mail w formacie nazwa@domena.pl" przy polu "Adres e-mail".
- Błąd: wariant rozróżniony wyłącznie czerwonym kolorem.
- Lepiej: wariant ma nazwę "Czerwony" i stan zaznaczenia dostępny także dla technologii asystującej.

Po zmianie formularza sprawdź, czy etykieta pola nie jest zastępowana przez tekst podpowiedzi znikający po rozpoczęciu wpisywania. Jeżeli wariant albo walidację dodaje aplikacja, zgłoś problem jej dostawcy i sprawdź poprawkę w tym samym widoku, w którym wystąpiła bariera.

Koszyk i płatność przechodzą test użytkowy, gdy klient może wybrać produkt, poprawić dane, wybrać dostawę i płatność oraz odczytać potwierdzenie bez bariery blokującej zakup. Szczególną uwagę zwróć na przekazanie do operatora płatności, ponieważ formularz płatniczy może pochodzić z zewnętrznej usługi.

Wykonaj jeden pełny scenariusz testowy klawiaturą. W Shoper sprawdź komunikat po dodaniu produktu, zmianę ilości, wybór dostawy, pola danych kupującego, wymagane zgody oraz widok po powrocie od operatora. Do przejścia użyj Tab, Shift+Tab, Enter i spacji; po błędzie sprawdź, czy komunikat wskazuje pole, a fokus pozwala wrócić do poprawy.

W panelu Shoper dostępne metody płatności można sprawdzić w "Ustawienia > Zarządzanie sprzedażą > Metody płatności". Nazwa ścieżki pochodzi z dokumentacji Shoper dla konfiguracji płatności; dostępne opcje zależą od aktywnej usługi. W testowym zamówieniu sprawdź, czy nazwa metody jest zrozumiała, czy wybór pozostaje widoczny w podsumowaniu i czy błąd operatora ma czytelną informację zwrotną.

Perspektywa KC Mobile: odbiór poprawki koszyka powinien objąć stany pośrednie, takie jak aktualizacja ilości, błędne dane i powrót z płatności. Zapisz krok, w którym proces przestaje być zrozumiały lub możliwy do kontynuowania, a barierę po stronie bramki zgłoś operatorowi.

Właściciel sklepu może zwykle poprawić treści produktów i część ustawień, natomiast błędy fokusu, struktury HTML albo komponentu aplikacji wymagają pomocy technicznej. Przed zmianą ustal, czy źródłem bariery jest treść, ustawienie panelu, motyw, aplikacja czy operator zewnętrzny.

W Shoperze sprawdź, czy nieprawidłowy element pochodzi z modułu aktywnego motywu, aplikacji widocznej na karcie produktu albo integracji uruchamianej przy płatności. Jeśli problem dotyczy elementu aplikacji, zbierz adres widoku, kroki odtworzenia i nazwę aplikacji. Nie edytuj kodu aktywnego motywu bez kopii lub procedury przywracania.

Tabela pokazuje, które poprawki można rozpocząć samodzielnie, a które zwykle wymagają wsparcia technicznego. Poziom wiedzy i ryzyko odnoszą się do typowego zakresu zmian w sklepie Shoper.

Tabela pomaga przypisać odpowiedzialność za zmianę. Przed wdrożeniem poprawki wykonawca powinien znać widok, kroki odtworzenia i oczekiwane zachowanie.

Rejestr dostępności powinien łączyć każdą barierę z adresem widoku, dowodem, priorytetem, właścicielem poprawki i wynikiem ponownego testu. Rejestr służy do zarządzania pracami i nie zastępuje obowiązkowego zawiadomienia Ministra Cyfryzacji, gdy usługa objęta PAD nie spełnia wymagań dostępności.

Zapisz kroki odtworzenia i oczekiwane zachowanie. Dowodem może być zrzut ekranu lub nagranie, o ile nie ujawnia danych klienta. Po naprawie powtórz ten sam test i oznacz wynik jako zaliczony albo nadal niezaliczony. Po aktualizacji motywu lub aplikacji wróć do testów elementów, których dotyczyła zmiana.

Tabela pokazuje pola potrzebne do śledzenia barier i wyniku poprawki w sklepie. Każdy wpis powinien wskazywać konkretny widok oraz osobę lub dostawcę odpowiedzialnego za dalsze działanie.

Rejestr pozwala odróżnić problem naprawiony od bariery oczekującej na dostawcę motywu lub aplikacji.

Usługodawca objęty PAD, który stwierdzi, że usługa handlu elektronicznego nie spełnia wymagań dostępności, ma niezwłocznie poinformować Ministra Cyfryzacji o niezgodności i działaniach naprawczych. Wewnętrzny rejestr barier nie zastępuje tego zawiadomienia.

Aktualna instrukcja Gov.pl dotycząca obowiązków informacyjnych w PAD wskazuje, że informacja powinna zawierać dane podmiotu, nazwę usługi i adres strony lub aplikacji, niespełnione wymagania, syntetyczny opis niezgodności, status oraz opis podjętych lub planowanych działań naprawczych i przewidywany termin ich zakończenia. Informację podpisuje osoba uprawniona do reprezentowania podmiotu.

Do przygotowania zawiadomienia służy wzór informacji o niespełnianiu wymagań dostępności dla usługi handlu elektronicznego. Gov.pl opisuje przekazanie podpisanego dokumentu elektronicznie przez e-Doręczenia, ePUAP lub e-mail na wskazany adres; dokument papierowy można wysłać pocztą na adres Ministerstwa Cyfryzacji, a jego wersję edytowalną należy dodatkowo przesłać e-mailem. Sprawdź aktualne instrukcje i wymagany podpis przed wysłaniem.

Zawiadomienie i naprawa to odrębne działania. Równolegle przypisz właściciela poprawki, ustal termin, zachowaj dowody niezgodności i po wdrożeniu powtórz test; wewnętrzny rejestr pomaga monitorować postęp, ale nie zastępuje zgłoszenia.

Po wdrożeniu poprawki bariera może nadal występować na stronie mobilnej, w wariancie dodanym przez aplikację albo przy powrocie od operatora płatności. Odbiór ograniczony do strony głównej lub wyniku skanera nie pokazuje wszystkich stanów procesu zakupowego.

Perspektywa KC Mobile: zakres odbioru powinien objąć ścieżkę od wyboru produktu do potwierdzenia zamówienia oraz miejsca, w których klient może poprawiać dane. Po korekcie modułu wariantów sprawdź, czy fokus jest widoczny na karcie produktu i czy wybrany wariant trafia do koszyka.

Przed zamknięciem prac sprawdź, czy rejestr zawiera wynik retestu, a problem aplikacji lub płatności ma przypisanego dostawcę i dalszy krok. Skaner traktuj jako źródło wskazówek, nie jako dowód spełnienia wymagań PAD. Jeśli potrzebujesz zewnętrznej oceny barier i planu kolejnych prac, audyt cyfrowy ścieżki zakupowej pomoże ustalić zakres testów.

• Dostępność cyfrowa w e-commerce: EAA, szablony IdoSell i kontrola sklepu
• Jak przygotować stronę internetową pod dostępność cyfrową WCAG
• Czym jest analiza SWOT sklepu internetowego i jak przełożyć ją na plan działania
• Audyt stron produktowych w e-commerce: checklista i priorytety poprawek