28 czerwca 2025 roku wszedł w życie European Accessibility Act (dyrektywa UE 2019/882) dla większości produktów i usług e-commerce sprzedawanych konsumentom w Unii Europejskiej. Rok później obraz z terenu jest jednoznaczny: większość sklepów PrestaShop nie spełnia wymagań, a większość sprzedawców wciąż o tym nie wie.
Temat nie jest wyłącznie etyczny. To dziś ryzyko prawne, handlowe (utrata zamówień publicznych i wrażliwych kontraktów B2B) oraz reputacyjne. Ten artykuł porządkuje realne ramy prawne, sposób prowadzenia nadzoru oraz techniczną mapę drogową doprowadzenia sklepu PrestaShop 8 albo 9 do zgodności bez przebudowy motywu.
Ramy prawne obowiązujące sklep PrestaShop w 2026 roku
EAA został wdrożony do prawa polskiego ustawą z 2024 roku o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług. Zakres jest szeroki: obejmuje każdą usługę handlu elektronicznego kierowaną do konsumentów w Unii, czyli witrynę, aplikację mobilną, proces zakupowy i komunikację posprzedażową.
Dwa wyłączenia o znaczeniu strukturalnym:
- Mikroprzedsiębiorstwa w rozumieniu unijnym (poniżej 10 pracowników ORAZ obrót lub suma bilansowa poniżej 2 mln EUR) są zwolnione w zakresie świadczonych usług. Uwaga: próg ocenia się na poziomie grupy.
- Treści zewnętrzne, nad którymi nie masz kontroli (na przykład surowe komentarze użytkowników), nie wchodzą w zakres, ale sprzedawca pozostaje odpowiedzialny za strukturę, w której te treści są prezentowane.
Techniczną normą odniesienia w całej Unii jest EN 301 549, zharmonizowana norma europejska, która w części dotyczącej treści internetowych opiera się na WCAG na poziomie AA. W praktyce codziennej pracy przewodnikiem jest WCAG 2.2, opublikowane w październiku 2023 roku, które dokłada dziewięć kryteriów sukcesu, w tym widoczny fokus (2.4.11), wystarczająco duże cele wskazywania (2.5.8) i trwałość elementów pomocy (3.2.6). Sklep zgodny z WCAG 2.2 na poziomie AA spełnia wymagania EN 301 549 w zakresie istotnym dla e-commerce.
Nadzór i sankcje: co to oznacza w praktyce
Polska ustawa wdrażająca EAA przewiduje system nadzoru rynku oraz kary administracyjne za niespełnienie wymagań dostępności. Nadzór nad usługami koordynowany jest przez organy wskazane w ustawie, przy istotnej roli PFRON, a nadzór nad produktami wpisuje się w ogólny system nadzoru rynku, w którym rolę koordynacyjną pełni UOKiK.
Trzy praktyczne obserwacje z pierwszego roku obowiązywania, wspólne dla większości rynków europejskich:
- Faza edukacyjna przeważa na początku: pierwsze kontrole kończą się zwykle wezwaniami do usunięcia uchybień i zobowiązaniami naprawczymi, rzadziej karami.
- Zaostrzenie następuje z czasem, w miarę jak organy budują praktykę kontrolną i rośnie liczba zgłoszeń od użytkowników.
- Ryzyko pośrednie jest prawdopodobnie większe niż kara: wykluczenie z zamówień publicznych, odmowa referencji przez centrale zakupowe B2B, zgłoszenia klientów.
Konkretne wysokości kar i tryb ich nakładania warto potwierdzić z prawnikiem przed przyjęciem założeń budżetowych, bo zależą od statusu podmiotu i charakteru naruszenia.
Najbardziej systematycznie weryfikowanym obowiązkiem widocznym jest oświadczenie o dostępności albo równoważna informacja o spełnianiu wymagań, publikowana na witrynie, opatrzona datą i wskazująca osiągnięty poziom zgodności wraz z planem dochodzenia do pełnej zgodności. Sklep bez takiej strony jest wychwytywany natychmiast.
Audyt w terenie: co realnie kuleje w PrestaShop
Na podstawie audytów, które prowadzimy na motywach Classic, Hummingbird, Warehouse i motywach na zamówienie, powtarzalne niezgodności skupiają się w sześciu rodzinach:
1. Niewystarczający kontrast (kryteria WCAG 1.4.3 i 1.4.11)
Jasna szarość na białym tle, używana do cen przekreślonych, dopisków „z VAT” i piktogramów zaufania, niemal zawsze nie spełnia wskaźnika 4,5:1 (tekst zwykły) albo 3:1 (tekst duży i interfejsy). Przebieg audytu w Lighthouse albo axe-core wykrywa zwykle od 15 do 40 defektów kontrastu na standardowej karcie produktu.
2. Zepsuta nawigacja klawiaturą
Górne menu rozwijane, filtry fasetowe po lewej, własny selektor ilości, popup newslettera: wszystkie te komponenty bywają niedostępne z poziomu samej klawiatury (Tab, Enter, spacja). Widoczny fokus znika w połowie motywów premium. To kryterium blokujące.
3. Źle opisany formularz checkoutu
Pole bez powiązanej etykiety, oznaczenie błędu wyłącznie kolorem (czerwień), brak atrybutu aria-describedby dla ograniczeń („minimum 8 znaków”), podsumowanie niedostępne dla czytnika ekranu. Natywny jednostronicowy checkout PrestaShop 8 zrobił postępy, ale wymaga uzupełnienia, zwłaszcza gdy dołożysz moduł płatności albo zewnętrzny selektor adresu.
4. Obrazy bez ustrukturyzowanego tekstu alternatywnego
Stary dobry problem: wszystkie zdjęcia produktowe mają pusty albo powielony atrybut alt (skopiowana nazwa produktu). Poprawna logika: pusty alt dla grafik czysto dekoracyjnych (alt=””), a opisowy i zróżnicowany alt dla ujęć dodatkowych („widok z tyłu”, „detal szwu”). PrestaShop nie robi tego automatycznie, więc uzupełnienie należy do sprzedawcy przy imporcie katalogu.
5. Wideo i karuzele z autoodtwarzaniem
Karuzela na stronie głównej przewijająca się sama, bez przycisku pauzy, albo wideo produktowe z autoodtwarzaniem to bezpośrednie naruszenie kryterium 2.2.2 (pauza, zatrzymanie, ukrycie). Technicznie rzecz biorąc, u odwiedzającego z zaburzeniami przedsionkowymi automatyczne przewijanie może wywołać złe samopoczucie.
6. Blokujący captcha i natrętne popupy
reCAPTCHA v2 typu „zaznacz pole” bez alternatywy dla użytkowników czytników ekranu, popup newslettera bez pułapki fokusu, okno cookies niemożliwe do zamknięcia klawiaturą. Trzy klasyki, które każdy audyt wychwytuje w kilka minut.
Mapa drogowa dojścia do zgodności, bez przebudowy motywu
Dobra wiadomość: większość sklepów może osiągnąć istotną zgodność z WCAG 2.2 AA w 4 do 8 tygodni celowanej pracy, bez pełnej przebudowy. Oto sekwencja, która działa:
Tydzień 1: audyt z liczbami
Uruchom audyt zautomatyzowany (axe DevTools, WAVE, Lighthouse) na 10 reprezentatywnych stronach: strona główna, kategoria, karta produktu, koszyk, etap dostawy, etap płatności, potwierdzenie, blog, kontakt, strona informacji prawnych. Uzupełnij testem ręcznym z samą klawiaturą oraz testem czytnika ekranu (darmowy NVDA na Windowsie, VoiceOver na Macu). Zbuduj macierz „kryterium, strona, waga” z ocenami.
Tygodnie 2 i 3: poprawki powierzchniowe o dużym wpływie
- Korekta palety kolorów tak, aby osiągnąć wymagane wskaźniki kontrastu. Często wystarczy dostroić jedną, dwie albo trzy zmienne CSS.
- Dodanie globalnego, czytelnego widocznego fokusu (obrys 2 piksele w kontrastowym kolorze).
- Poprawa opisów alt w katalogu: regułę da się zautomatyzować skryptem SQL albo modułem automatycznych poprawek WCAG.
- Usunięcie autoodtwarzania i dodanie sterowania pauzą w karuzeli.
Tygodnie 4 i 5: komponenty krytyczne
- Przebudowa menu głównego z pełną obsługą klawiatury (Tab, Enter, Escape, strzałki).
- Poprawne etykietowanie ARIA filtrów fasetowych, selektora ilości i powiadomień koszyka.
- Poprawa formularzy: powiązane etykiety, oznaczenia błędów tekstem ORAZ kolorem, fokus na pierwszym błędnym polu.
Tygodnie 6 i 7: zgodność redakcyjna i oświadczenie
- Audyt stron CMS i wpisów blogowych (struktura nagłówków, atrybuty alt).
- Redakcja i publikacja oświadczenia o dostępności zgodnego z wymogami (stan zgodności, uzasadnione wyłączenia, kanał zgłoszeń użytkowników, tryb odwoławczy).
- Publikacja planu dochodzenia do zgodności na tej samej stronie.
Tydzień 8: test z użytkownikiem i dokumentacja
Test z prawdziwym użytkownikiem z niepełnosprawnością (wzrokową albo ruchową) pozostaje jedynym sposobem potwierdzenia, że nie przeoczyłeś subtelnego kryterium. To także argument w razie kontroli, bo dowodzi prowadzenia procesu ciągłego doskonalenia.
Pułapka modułów zewnętrznych
Główny martwy punkt: moduły zewnętrzne bez przerwy dokładają elementy, które nie przeszły audytu. Popup listy życzeń, moduł cross-sell z karuzelą, widget opinii zewnętrznych: każdy dodatek może zepsuć wypracowaną zgodność. Zdrowa zasada: audytuj każdy nowy moduł przez axe-core przed wdrożeniem i wymagaj od dewelopera deklaracji zgodności z WCAG 2.2 AA.
Po stronie DataFirefly wszystkie nowsze moduły (koszyk boczny, alerty, wyszukiwanie na żywo, kreator stron) są testowane w axe-core i czytnikiem ekranu przed publikacją, a deklarację zgodności technicznej udostępniamy na życzenie sprzedawcom w trakcie kontroli.
Podsumowanie: ryzyko przestało być teoretyczne
Argument „nikt tego nie kontroluje” nie jest już do obrony rok po wejściu EAA w życie. Organy budują praktykę kontrolną, oświadczenie o dostępności stało się widocznym minimum, a presja B2B rośnie, bo centrale zakupowe, zamawiający publiczni i duzi kontrahenci wpisują dziś zobowiązania WCAG do umów.
Właściwy kąt strategiczny dla sprzedawcy PrestaShop to nie robienie kosmetycznego minimum, lecz wykorzystanie dojścia do zgodności jako ogólnego audytu UX: większość poprawek dostępności poprawia również konwersję (czytelność, kontrast, nawigacja klawiaturą doceniana przez zaawansowanych użytkowników, lepsza struktura semantyczna dla SEO i AEO). Inwestycja 4 do 8 tygodni, która pracuje na kilka celów naraz. Aby pokryć pozostałe wymogi regulacyjne karty produktu (Omnibus, GPSR, rękojmia, ESPR), nasz wybór modułów zgodności produktowej dla PrestaShop uzupełnia ten obszar prac.
Przeczytaj także: lista kontrolna GPSR.
Aby przejść do działania: nasz wybór modułów do dostępności i zgodności z EAA.
