Dostępność cyfrowa w e-commerce: WCAG 2.1 i EAA – poradnik dla sklepów PrestaShop

Home » Rozwiązania i Poradniki » Dostępność WCAG i EAA

Wprowadzenie

Dostępność cyfrowa to projektowanie stron i sklepów internetowych w taki sposób, by każdy użytkownik – także z niepełnosprawnościami – mógł z nich wygodnie korzystać. Dla właścicieli e-sklepów (zwłaszcza opartych na PrestaShop) dostępność staje się nie tylko kwestią etyki i użyteczności, ale i obowiązkiem prawnym. W 2025 roku w życie wchodzi Europejski Akt o Dostępności (EAA), który wymaga, by sklepy internetowe były zgodne ze standardem WCAG 2.1 (Web Content Accessibility Guidelines). To oznacza, że „PrestaShop WCAG” – czyli zgodność sklepu PrestaShop z wytycznymi dostępności – nie jest już opcjonalna, a konieczna.

Dlaczego warto się tym przejmować? Po pierwsze, ustawodawstwo wymusza dostosowanie sklepów (o czym więcej za chwilę). Po drugie, dostępność poszerza bazę potencjalnych klientów – szacuje się, że nawet 15% populacji ma trwałe lub czasowe ograniczenia sprawiające trudność w korzystaniu z niedostępnych stron. Po trzecie, to się po prostu opłaca biznesowo. Sklep spełniający standardy WCAG jest bardziej przyjazny i intuicyjny dla wszystkich użytkowników, co przekłada się na lepsze wyniki. Na przykład, strony dostępne notują średnio 12% wyższy ruch z wyników organicznych niż strony z ignorowanymi standardami. Wynika to z faktu, że wiele praktyk dostępności pokrywa się z dobrymi praktykami SEO (np. poprawna struktura HTML, opisy alternatywne obrazków). Innymi słowy – dopracowanie dostępności poprawia doświadczenie użytkownika (UX), SEO i konwersje sprzedażowe. To inwestycja, która się zwraca.

W tym poradniku wyjaśnimy najważniejsze aspekty dostępności cyfrowej dla e-commerce. Omówimy minimum wiedzy prawnej o WCAG 2.1 i EAA, pokażemy dlaczego sam moduł dostępności (np. popularny PrestaShop moduł WCAG czy PrestaShop moduł EAA) nie wystarczy, przystępnie przedstawimy zasady POUR według WCAG, wskażemy typowe błędy dostępności w sklepach internetowych oraz przeprowadzimy Cię przez proces zapewniania dostępności (od audytu, przez wdrożenie, po deklarację). Ponadto przedstawimy narzędzia audytowe (takie jak axe DevTools, WAVE, Lighthouse itp.), zaprezentujemy checklistę kontrolną dla właściciela sklepu i na koniec podsumujemy całość konkretnym planem działania. Poradnik jest napisany w przystępnym języku i naszpikowany praktycznymi wskazówkami – tak, abyś mógł od razu zastosować zdobytą wiedzę w swoim sklepie.

Kogo dotyczą wymogi WCAG/EAA?

Obowiązek dotyczy:

Sklepów internetowych (e‑commerce) – czyli tych oferujących zakupy online z koszykiem i płatnością skierowaną do konsumentów w UE.
Dostawców, producentów, importerów – wszystkich podmiotów, które oferują produkty lub usługi objęte zakresem EAA w UE.

Wyłączenia:

Mikroprzedsiębiorstwa, czyli firmy zatrudniające < 10 osób i mające roczny obrót lub sumę bilansową < 2 mln € – są zwolnione z obowiązku WCAG/EAA.
Dodatkowo: mogą uzyskać zwolnienie przy uzasadnieniu „disproportionate burden” – gdy koszt dostosowania przewyższa korzyści społeczne.

Jeśli nie jesteś wyłączony, to obecność funkcji sprzedaży online (koszyk, płatność, dostawa) oznacza, że musisz dostosować sklep do WCAG 2.1 AA i spełniać wymogi EAA.

W skrócie: Czy masz obowiązek?

Sprawdź, czy jesteś mikroprzedsiębiorstwem – jeśli tak i spełniasz kryteria, jesteś zwolniony niezależnie od funkcji sklepu.
Jeśli nie – a masz e‑commerce – musisz być zgodny z dostępnością po 28 czerwca 2025.

Minimum wiedzy prawnej o WCAG 2.1 i EAA

WCAG 2.1 (Web Content Accessibility Guidelines) to międzynarodowe wytyczne określające standard dostępności treści internetowych. Obecnie standard WCAG 2.1 jest powszechnie uznawany i wymagany prawnie w wielu krajach. Zbiór tych wytycznych został opracowany przez W3C (World Wide Web Consortium) i definiuje kryteria na trzech poziomach zgodności: A (podstawowe), AA (zalecany jako minimalny dla większości serwisów, w tym e-commerce) oraz AAA (najbardziej rygorystyczny). Dla sklepów internetowych minimalnym praktycznym poziomem jest WCAG 2.1 AA – oznacza to spełnienie kilkudziesięciu szczegółowych kryteriów dotyczących m.in. tekstów alternatywnych, nawigacji, kontrastu kolorów, struktury dokumentu, formularzy, multimediów itd. W skrócie, sklep zgodny z WCAG 2.1 AA powinien być percepcyjnie, funkcjonalnie, zrozumiale i solidnie (o tych zasadach w kolejnym rozdziale).

European Accessibility Act (EAA), czyli Europejski Akt o Dostępności, to dyrektywa Unii Europejskiej z 2019 roku, która zobowiązuje przedsiębiorców do zapewnienia dostępności wybranych produktów i usług. Od 28 czerwca 2025 r. wymogi EAA obejmą również sklepy internetowe w krajach UE. W praktyce oznacza to, że każdy sklep e-commerce sprzedający swoje produkty konsumentom w UE musi spełniać kryteria dostępności określone w WCAG 2.1 (co zostało zaimplementowane w prawie krajowym – np. w Polsce uchwalono odpowiednią ustawę w kwietniu 2024, która w pełni wchodzi w życie z dniem obowiązywania dyrektywy). Przedsiębiorcy, którzy zlekceważą te wymogi, narażają się na konsekwencje prawne – organy nadzoru będą mogły egzekwować dostępność, a brak zgodności może skutkować karami finansowymi lub nawet wykluczeniem niedostępnego produktu/usługi z rynku. Co ważne, przepisy dotyczą przede wszystkim średnich i dużych podmiotów (mikrofirmy mogą być częściowo wyłączone), jednak z punktu widzenia konkurencyjności rynkowej każdy sklep powinien dążyć do spełnienia standardów. Nawet jeśli Twój biznes jest niewielki, dostępność będzie atutem budującym przewagę.

Podsumowując kwestie prawne: masz obowiązek zapewnić, że Twój sklep online jest dostępny cyfrowo dla osób z niepełnosprawnościami. Wymaga tego zarówno WCAG 2.1, będący zbiorem konkretnych wytycznych technicznych, jak i EAA, czyli prawo unijne, które przenosi te wymagania na grunt prawny. W kolejnych częściach poradnika dowiesz się, jak praktycznie podejść do tego zadania, ale najpierw ważna przestroga – sama instalacja modułu “dostępności” nie załatwi sprawy.

Dlaczego sam moduł dostępności nie wystarczy

Jeśli szukałeś szybkiego rozwiązania problemu dostępności, mogłeś natrafić na różne wtyczki i moduły obiecujące uczynić sklep „WCAG compliant” jednym kliknięciem. Przykłady to choćby dedykowane dodatki typu PrestaShop moduł WCAG lub nawet PrestaShop moduł EAA dostępne na marketplace. Takie moduły zwykle dodają do sklepu tzw. widget dostępności – panel pozwalający użytkownikom zmieniać kontrast, wielkość czcionki, kursora, a nawet korzystać z pseudo-czytnika ekranu. Brzmi dobrze, ale niestety – samo zastosowanie takiego modułu to za mało, by rzeczywiście spełnić wymagania WCAG 2.1/EAA.

Dlaczego? Ponieważ prawdziwa dostępność musi być zaszyta w strukturze i treści Twojej strony, a nie tylko nałożona jako warstwa z wierzchu. Tzw. nakładki dostępności działają zwykle w sposób automatyczny, próbując „naprawiać” pewne aspekty w locie, bez ingerencji w kod źródłowy strony. Niestety, większość takich rozwiązań nie jest w stanie poprawić kluczowych braków. Przykładowo: moduł może dodać przycisk powiększający font, ale nie wygeneruje sam z siebie sensownych tekstów alternatywnych (alt) do obrazków, jeśli ich nie zapewniłeś. Może umożliwić nawigację klawiaturą po elementach strony, ale nie naprawi błędnej kolejności nagłówków czy braku etykiet formularzy. Co więcej, niektóre nakładki mogą nawet wprowadzać nowe błędy i konflikty, utrudniając działanie czytników ekranu.

Warto też uważać na obietnice „automatycznego audytu WCAG”. Żaden moduł ani skaner online nie zastąpi pełnej oceny eksperckiej. Automatyczne narzędzia mogą wychwycić oczywiste uchybienia (np. brak alt tekstu czy niski kontrast), ale nie ocenią, czy tekst linku jest zrozumiały, czy kolejność skakania po elementach klawiaturą jest logiczna, albo czy komunikaty o błędach w formularzu są wystarczająco jasne. Dlatego poleganie wyłącznie na pluginie może dać fałszywe poczucie bezpieczeństwa – strona może wyglądać na „bardziej dostępną”, ale nadal nie spełniać wielu kryteriów WCAG.

Reasumując: moduły dostępności mogą być przydatnym uzupełnieniem (np. oferując tryb wysokiego kontrastu dla osób słabowidzących czy ułatwiając powiększanie tekstu). Jednak nie zwalniają z obowiązku ręcznego dostosowania sklepu do standardów. Traktuj je raczej jako wisienkę na torcie – interfejs ułatwiający życie części użytkowników – ale fundamentem „tortu” musi być poprawny kod, treść i projekt zgodny z WCAG. Poniżej omówimy podstawowe zasady, na których opiera się WCAG 2.1, co pomoże Ci zrozumieć, na co zwracać uwagę przy dostosowywaniu sklepu, zamiast liczyć na magiczną wtyczkę.

Przystępne omówienie zasad POUR (WCAG)

Standard WCAG opiera się na czterech głównych zasadach, często określanych akronimem POUR (od angielskich nazw: Perceivable, Operable, Understandable, Robust). W języku polskim możemy je oddać jako Postrzegalność, Funkcjonalność, Zrozumiałość, Solidność. Poniżej wyjaśniamy te pojęcia w prosty sposób, z naciskiem na ich znaczenie dla sklepów internetowych:

Postrzegalność (Perceivable) – treści i elementy interfejsu muszą być dostrzegalne dla użytkownika niezależnie od tego, jak odbiera on informacje. W praktyce chodzi o to, by ważne informacje nie były przekazywane wyłącznie jednym zmysłem. Przykłady: do obrazków dodaj tekst alternatywny (alt), aby osoby niewidome mogły usłyszeć ich opis; zapewnij odpowiedni kontrast kolorów między tekstem a tłem, by osoby słabowidzące lub oglądające w słońcu mogły odczytać treść (WCAG wymaga kontrastu co najmniej 4.5:1 dla tekstu zwykłego); nie polegaj wyłącznie na kolorze, aby przekazać informację (np. podkreśl linki nie tylko kolorem, ale i stylowo, oznacz pola obowiązkowe formularza nie tylko czerwoną ramką, ale też np. gwiazdką i etykietą "wymagane"). Treść ma być dostępna w różnej formie – np. transkrypcja dla podcastu, napisy dla wideo, opis tekstowy dla infografiki.
Funkcjonalność (Operable) – interfejs musi być w pełni obsługiwalny dla każdego, niezależnie od używanego urządzenia czy sprawności ruchowej. Oznacza to m.in., że wszystkie funkcje sklepu powinny być dostępne za pomocą klawiatury – użytkownik musi móc nawigować Tabulatorem po menu, produktach, przyciskach i formularzach, a następnie uruchamiać akcje klawiszem Enter czy Spacja. Nie powinno być sytuacji, że fokus klawiatury „utknie” w jakimś miejscu (tzw. pułapka focus) – zadbaj o to podczas implementacji nawigacji i okien modalnych. Dla elementów dynamicznych (np. rozwijane menu, popup koszyka) upewnij się, że można je otworzyć i zamknąć klawiaturą oraz że fokus jest odpowiednio przenoszony. Przykłady: jeśli masz baner slider na stronie głównej, daj możliwość jego wstrzymania (osoby z ograniczeniami mogą nie nadążyć za zmieniającymi się slajdami); zapewnij widoczny obrys fokusu (focus indicator) dla aktywnego elementu, aby wiadomo było, który element jest aktualnie wybrany przy nawigacji klawiaturą; do linków lub przycisków używaj natywnych elementów HTML (a, button) lub zapewnij im role ARIA i obsługę zdarzeń klawiatury, by nie były „niewidzialne” dla czytników.
Zrozumiałość (Understandable) – zawartość i nawigacja muszą być zrozumiałe i przewidywalne dla użytkownika. Strona powinna komunikować się jasnym językiem i zachowywać w sposób, którego użytkownik może się spodziewać. Przykłady: używaj czytelnej, prostej terminologii (zwłaszcza w instrukcjach, opisach błędów – unikaj żargonu technicznego tam, gdzie nie jest potrzebny); zachowaj spójną strukturę nagłówków i układu na wszystkich podstronach (np. jeśli sekcja "Opis produktu" jest nagłówkiem h2, stosuj podobne podejście na innych kartach produktów); dbaj o intuicyjność nawigacji – menu i przyciski powinny działać konsekwentnie (np. wszystkie kategorie rozwijają się w podobny sposób). W formularzach, takich jak rejestracja czy finalizacja zakupu, zapewnij jasne komunikaty o błędach (np. “Proszę wprowadzić poprawny adres e-mail” zamiast enigmatycznego “Błąd 1002”) oraz podpowiedzi co do oczekiwanego formatu danych. Generalnie użytkownik nie powinien być zaskakiwany ani zmuszany do domyślania się, co coś oznacza lub jak coś zrobić.
Solidność (Robust) – Twój sklep musi być technicznie solidny i zgodny ze standardami, tak aby różne urządzenia i technologie asystujące mogły go prawidłowo interpretować. Chodzi o to, by kod był poprawny, a elementy – kompatybilne z czytnikami ekranu, lupami, oprogramowaniem zamieniającym tekst na mowę itp. Przykłady: trzymaj się standardów HTML5 – poprawnie zamykaj znaczniki, nie łam struktury dokumentu, używaj elementów zgodnie z ich przeznaczeniem (np. <button> do przycisków zamiast <div> stylowanego jak przycisk); gdy semantyka HTML jest niewystarczająca, stosuj ARIA (Accessible Rich Internet Applications) do oznaczania ról elementów (np. role="navigation" dla bloku menu, aria-label do opisania przycisku ikony, aria-live do dynamicznych komunikatów). Testuj swój sklep z użyciem różnych przeglądarek i czytników ekranu (np. NVDA, JAWS, VoiceOver) – jeśli kod jest solidny, asystujące technologie powinny poprawnie odczytać strukturę strony, przyciski, listy produktów itp. Solidność wymaga też, by sklep był przystosowany mobilnie (responsywnie) i skalowalny – np. powiększenie strony 200% nie powinno powodować, że coś przestaje działać lub teksty nachodzą na siebie.

Powyższe cztery zasady stanowią filozofię WCAG. Każde kryterium sukcesu WCAG 2.1 jest przypisane do jednej z nich. Jako właściciel sklepu nie musisz znać na pamięć wszystkich punktów technicznych, ale zrozumienie POUR daje Ci intuicję, na co zwracać uwagę. Na przykład, gdy wprowadzasz nowy element do sklepu (np. czat pomocniczy, karuzelę produktów, nowy filtr wyszukiwania), pomyśl: czy będzie on postrzegalny, operowalny, zrozumiały i solidny dla każdego? Jeśli tak – prawdopodobnie spełniasz też szczegółowe kryteria. Teraz przyjrzyjmy się konkretnym błędom, jakie najczęściej łamią te zasady w sklepach internetowych.

Typowe błędy dostępności w e-commerce

Niestety, audyty pokazują, że większość sklepów internetowych ma liczne problemy z dostępnością. Badanie Baymard Institute wykazało, że aż 94% największych serwisów e-commerce nie spełnia wymogów WCAG 2.1 AA, a do najczęstszych uchybień należą brak opisów alternatywnych przy obrazach, problemy z nawigacją oraz nieprawidłowe oznaczenia elementów interfejsu. Poniżej lista typowych błędów dostępności, na które szczególnie narażone są sklepy online:

Brak tekstów alternatywnych (atributów alt) dla obrazów – w kontekście e-commerce dotyczy to przede wszystkim zdjęć produktów, banerów promocyjnych i ikon. Gdy obraz nie ma alt albo alt jest pusty/niewiele mówiący, osoba korzystająca z czytnika ekranu “usłyszy” jedynie nazwę pliku lub nic. To poważny problem, bo cała treść niesiona przez grafikę zostaje utracona. Przykład: zdjęcie sukienki powinno mieć alt w stylu „Czerwona sukienka koktajlowa model X na modelce” zamiast pozostawionego alt="" lub domyślnego nazewnictwa pliku. Alt tekst powinien przekazywać funkcję lub informację obrazu (co przedstawia i w jakim kontekście jest użyty).
Niewystarczający kontrast kolorów – częsty grzech designerski to stylowy, ale blady tekst na jasnym tle albo jasnoszare przyciski na białym tle. Osoby słabowidzące, starsze lub używające ekranów o słabej jasności mogą w ogóle nie odczytać takiego tekstu. WCAG 2.1 AA wymaga, by kontrast tekstu względem tła wynosił co najmniej 4,5:1 (dla dużych fontów 3:1). Przykład: jasnoszara czcionka 12px na białym tle to fatalny pomysł; lepiej użyć ciemniejszego koloru lub zwiększyć rozmiar. Pamiętaj też o kontrastach elementów interfejsu – np. ikon, obramowań pól formularza itp.
Brak pełnej obsługi klawiaturą – często menu nawigacyjne, rozwijane listy kategorii, suwaki cenowe czy filtry są zaprojektowane z myślą o myszce, a zapomina się o klawiaturze. Każdy interaktywny element powinien być dostępny poprzez naciśnięcia Tab/Enter/Esc. Typowe błędy to: pominięcie pewnych linków w kolejności tabulacji (np. elementy nie-fokusowalne), brak możliwości rozwinięcia submenu klawiaturą, brak możliwości zamknięcia okienka (np. koszyka czy pop-upu) klawiszem Esc, niewidoczny fokus. Użytkownik bez myszy lub na urządzeniu mobilnym z klawiaturą bluetooth powinien móc przejść cały proces zakupowy od wyboru produktu, przez dodanie do koszyka, po wypełnienie formularza zamówienia bez dotykania myszy czy ekranu dotykowego.
Niepoprawna struktura nagłówków i sekcji – w pośpiechu tworzenia opisów produktów czy wpisów na blogu, łatwo użyć dużej czcionki lub stylu graficznego zamiast prawidłowych nagłówków HTML (h1, h2, h3...). To błąd, bo czytniki ekranu polegają na strukturze nagłówków, by “zmapować” stronę. Jeśli pominiemy <h1> lub przeskoczymy bez sensu z <h1> do <h3>, struktura staje się chaotyczna. Podobnie, układ sekcji w kodzie powinien odpowiadać logicznemu układowi treści. W e-commerce nagłówkiem h1 będzie zwykle nazwa produktu na karcie produktu (lub tytuł strony na stronie głównej), h2 – np. “Opis produktu”, “Opinie klientów” itd. Trzeba tego konsekwentnie pilnować.
Formularze bez etykiet i opisów błędów – proces rejestracji czy finalizacji zamówienia często bywa problematyczny dla osób z niepełnosprawnościami z powodu błędów w formularzach. Typowe problemy: brak powiązania etykiety tekstowej z polem (<label for=""> i odpowiadające id pola) – przez co czytnik ekranu nie odczyta nazwy pola; używanie wyłącznie podpowiedzi w placeholderze (który znika po zaczęciu pisania); brak komunikatów dla osób niewidzących o tym, że pole jest błędnie wypełnione (np. komunikat jest tylko w formie czerwonej ramki, bez tekstu). Każde pole powinno mieć tekstową etykietę, a w razie błędu powinien pojawić się czytelny komunikat tekstowy powiązany z polem (np. poprzez aria-describedby). Tak samo, przycisk “Wyślij zamówienie” powinien być aktywny dla klawiatury i jasno opisany (nie samą ikoną).
Elementy interfejsu nieoznaczone dla technologii asystujących – dotyczy to zwłaszcza niestandardowych komponentów tworzonych przez front-end developerów. Często buduje się coś “od zera” na <div> i JavaScript – np. rozbudowany selektor rozmiaru produktu, gwiazdki ocen, slider zakresu ceny – zapominając o atrybutach ARIA. W efekcie czytnik ekranu może takiego elementu w ogóle nie ogłaszać lub nie podać jego roli. Przykład: suwak ceny może potrzebować roli slider i atrybutów aria-valuemin, aria-valuemax, aria-valuenow oraz obsługi strzałek z klawiatury, by był faktycznie użyteczny dla osób niewidomych. Jeśli tego zabraknie – użytkownik słyszy tylko “przycisk, przycisk, przycisk” lub nic.
Multimedia bez transkrypcji/napisów – jeśli w sklepie prezentujesz wideo (np. recenzje produktów, instrukcje montażu) lub audio (podcast o marce), zadbaj o napisy lub transkrypcję. Osoby niesłyszące inaczej nie skorzystają z tych treści. Napisy przydają się zresztą też osobom oglądającym film bez dźwięku (np. w biurze, w autobusie). Dla treści audio daj tekstową wersję do poczytania.
Treści animowane, migające, rozpraszające – slajdery, automatycznie zmieniające się banery, wyskakujące okienka pojawiające się znienacka – to wszystko może być uciążliwe. Dla niektórych użytkowników (np. osób z zaburzeniami uwagi, epilepsją fotogenną) nawet niebezpieczne są elementy migające lub błyskające (stąd WCAG zakazuje treści migających ponad 3 razy na sekundę). Staraj się ograniczać zbędne animacje, a te które są – dawać pod kontrolę użytkownika (np. przycisk “pauza” dla carousel).

Lista mogłaby być dłuższa, ale już widać pewną prawidłowość: większości błędów można uniknąć, stosując dobre praktyki kodowania i projektowania od początku. Często problemy biorą się z niedbalstwa (np. brak alt tekstu, bo „to oczywiste, co jest na obrazku”) albo z nadmiernej kreatywności bez oglądania się na standardy (wynajdowanie koła na nowo w interfejsie). W następnej części opisujemy, jak krok po kroku zapewnić dostępność w Twoim sklepie – od audytu po deklarację – aby wyeliminować takie błędy.

Proces zapewniania dostępności (audyt, raport, wdrożenie, retest, deklaracja)

Zapewnienie dostępności to proces – składa się z kilku etapów, które logicznie następują po sobie. Poniżej opisujemy 5 głównych kroków tego procesu:

Audyt dostępności – na start musisz dowiedzieć się, gdzie obecnie Twój sklep nie spełnia wymogów. Audyt polega na przeanalizowaniu strony pod kątem WCAG 2.1 AA. Obejmuje to zarówno testy automatyczne, jak i weryfikację ręczną. Warto skorzystać z narzędzi (o nich w kolejnym rozdziale) takich jak WAVE czy Lighthouse, aby szybko wyłapać podstawowe problemy (np. brak alt, zły kontrast, błędy HTML). Jednak na tym nie poprzestajemy – audytor (czy to Ty, czy zatrudniony specjalista) musi przejrzeć sklep „oczami” różnych użytkowników. Oznacza to przetestowanie klawiaturą (czy da się kupić produkt bez myszy?), sprawdzenie działania z czytnikiem ekranu na kluczowych podstronach (homepage, lista produktów, karta produktu, koszyk, checkout), sprawdzenie czy wszystkie funkcjonalności (filtry, sortowanie, logowanie, itp.) są osiągalne i zrozumiałe. Wynikiem audytu jest lista wykrytych problemów dostępności wraz z przypisaniem ich do konkretnych elementów strony.
Raport i rekomendacje naprawcze – same wyniki surowego audytu to za mało; potrzebujesz je zinterpretować i zaplanować poprawki. Dlatego kolejnym etapem jest sporządzenie raportu z audytu. Raport dostępności powinien wymieniać znalezione błędy, każdy opisany pod kątem: które kryterium WCAG nie jest spełnione, dlaczego to problem dla użytkownika oraz – najważniejsze – jak go naprawić. Dobrą praktyką jest nadanie priorytetów (np. krytyczne, wysokie, średnie, niskie) aby wiedzieć, czym zająć się najpierw. Przykładowo: „Brak etykiety przy polu e-mail (WCAG 1.3.1): dodać tag <label> z odpowiednim for, aby czytnik odczytał nazwę pola”. Taki raport staje się planem działania dla dewelopera lub agencji wdrażającej poprawki. Warto też uwzględnić pozytywne znaleziska (co już jest OK) – dla pełnego obrazu i docenienia tego, czego nie trzeba ruszać.
Wdrożenie poprawek (implementacja) – to kluczowy i często najbardziej pracochłonny etap. Polega na wprowadzeniu zmian w kodzie i treści sklepu zgodnie z raportem. Może obejmować bardzo różne działania, w zależności od tego, jakie błędy wykryto. Typowe zadania to: dodanie brakujących atrybutów alt do obrazków produktów; poprawa struktury nagłówków w szablonie; dodanie opisów tekstowych do ikon (np. przycisku koszyka, lupki wyszukiwania – via aria-label lub screen-reader-only tekst); dopisanie obsługi zdarzeń klawiatury do elementów interaktywnych (np. otwieranie modala koszyka klawiszem Enter i zamykanie Esc); poprawki stylów CSS dla fokusu (żeby był widoczny); zapewnienie wymaganego kontrastu kolorystycznego (np. zmiana odcienia tekstu lub tła); przebudowa części formularzy, by miały odpowiednie etykiety i komunikaty błędów; dodanie napisów do filmów promocyjnych; usunięcie lub zastąpienie niedostępnych pluginów. Czasem może zajść potrzeba głębszych zmian, np. zmiany szablonu graficznego na bardziej dostępny, jeśli obecny jest bardzo problematyczny. W przypadku PrestaShop warto sprawdzić, czy wybrany motyw spełnia przynajmniej podstawy WCAG – jeśli nie, rozważ zainwestowanie w motyw dostosowany do WCAG 2.1 (coraz więcej się takich pojawia). Wdrożenie obejmuje też aktualizację modułów – jeśli któryś moduł (np. slider, popup newslettera) powoduje problemy, sprawdź czy jest jego nowsza, bardziej accessible wersja lub poszukaj alternatywy. Ten etap zwykle realizują programiści front-end (we współpracy z webmasterem lub administratorem sklepu). Po wprowadzeniu poprawek warto przeszkolić zespół – osoby dodające treści (np. nowe produkty, banery) powinny znać podstawowe zasady, by nie wprowadzać ponownie błędów (więcej o edukacji patrz krok 5 poniżej).
Retest (weryfikacja ponowna) – po zaimplementowaniu zmian, trzeba sprawdzić, czy odniosły zamierzony skutek i czy niczego nie pominięto. Retest to powtórka audytu: znów uruchamiamy narzędzia automatyczne (powinny teraz pokazać czystszy wynik) oraz testy manualne. Warto zaangażować osoby z niepełnosprawnościami do testów – nawet krótkie konsultacje mogą ujawnić coś, czego my nie zauważyliśmy. Jeśli wprowadzałeś duże zmiany w kodzie, upewnij się też, że nie popsuły one czegoś niezwiązanego z dostępnością (regresja). W retestach zaleca się sprawdzenie wszystkich krytycznych ścieżek użytkownika: przejrzenie oferty, dodanie do koszyka, rejestracja/logowanie, checkout, kontakt przez formularz. Jeżeli jakieś problemy nadal występują, wracasz do kroku 3 i poprawiasz – aż do uzyskania satysfakcjonującego poziomu zgodności. Pamiętaj, że dostępność to nie stan zero-jedynkowy, a pewne spektrum – celem jest spełnić wszystkie kryteria na poziomie AA (chyba że coś jest nieadekwatne do Twojego sklepu). Gdy uznasz, że Twój sklep spełnia te kryteria lub ma tylko drobne odstępstwa, przechodzisz do ostatniego etapu.
Deklaracja dostępności – jest to dokument (publicznie dostępny, najczęściej jako podstrona w serwisie, np. link w stopce “Dostępność” lub w regulaminie), w którym oświadczasz stan zgodności Twojego sklepu z wymaganiami. Dla sektora publicznego taka deklaracja jest wymagana już od dawna; EAA wprowadza podobny obowiązek dla komercyjnych serwisów. W deklaracji należy podać: do jakiego standardu odnosisz dostępność (np. WCAG 2.1 AA), na jakim poziomie Twój serwis go spełnia (np. „w pełni zgodny” lub „częściowo zgodny, z następującymi odstępstwami…” – jeśli czegoś nie udało się dostosować, np. starszych treści wideo), datę sporządzenia deklaracji i metodę oceny (np. samodzielna ocena, audyt zewnętrzny, nazwa firmy audytorskiej), a także informacje kontaktowe dla użytkowników. Ten ostatni element jest bardzo ważny – musisz wskazać, jak osoba napotykająca na bariery może Cię o tym powiadomić (np. adres e-mail do punktu kontaktowego ds. dostępności) oraz jak może złożyć skargę do nadzoru, jeśli sklep nie spełnia wymagań. Celem deklaracji jest transparentność – pokazujesz klientom, że traktujesz dostępność poważnie i uczciwie informujesz o statusie. Po przygotowaniu takiej deklaracji (wzorując się np. na publicznych instytucjach, które już to mają), opublikuj ją na stronie.

Na koniec procesu masz sklep dostosowany do wymogów oraz formalne potwierdzenie tego faktu. Warto jednak pamiętać, że dostępność to proces ciągły, a nie jednorazowy projekt. Każda aktualizacja PrestaShop, instalacja nowego modułu, zmiana szaty graficznej czy dodanie funkcji powinna być dokonywana z myślą o WCAG. Dlatego dobrze jest wprowadzić zasadę „accessibility by design” – planując rozwój sklepu, od razu uwzględniaj kryteria dostępności. Dodatkowo, regularnie (np. raz na kwartał) przeprowadzaj mini-audyt lub przynajmniej skanuj stronę automatycznymi narzędziami dla pewności. Dzięki temu utrzymasz zgodność i nie dasz się zaskoczyć kolejnym kontrolom czy rosnącym oczekiwaniom klientów.

Narzędzia audytowe (axe DevTools, WAVE, Lighthouse, inne)

Na szczęście nie musisz polegać wyłącznie na własnej intuicji – istnieje szereg świetnych narzędzi, które pomogą Ci wykryć problemy z dostępnością. Oto kilka z nich, które warto znać i używać:

WAVE (Web Accessibility Evaluation Tool) – to darmowe narzędzie od WebAIM, dostępne jako strona online oraz wtyczka do przeglądarki (Chrome, Firefox). WAVE pozwala jednym kliknięciem przeanalizować stronę i wizualnie pokazać wykryte problemy: oznacza na stronie ikonkami miejsca, gdzie brakuje alt, gdzie kontrast jest za niski, gdzie brak nagłówka itp. Dla właściciela sklepu jest to bardzo przystępne – widzisz swój sklep z naniesionymi uwagami. WAVE wyłapuje też potencjalne ostrzeżenia (np. zbyt długie linki, puste nagłówki). Pamiętaj jednak, że WAVE nie złapie wszystkiego – np. nie powie Ci, czy dany opis jest sensowny, czy kolejność focusu logiczna – to już musisz ocenić sam lub z ekspertem.
axe DevTools – axe to silnik automatycznego testowania od firmy Deque, uznawany za jeden z najlepszych. axe DevTools to wtyczka do przeglądarki (oraz pakiet integrujący się z narzędziami deweloperskimi) dla bardziej technicznych użytkowników. Po uruchomieniu skanu otrzymujemy listę naruszeń z odniesieniem do konkretnych punktów WCAG i wskazaniem fragmentu kodu HTML, którego dotyczy problem. Jest to narzędzie idealne dla dewelopera pracującego nad poprawkami – daje dokładne informacje gdzie i co jest nie tak, często z sugestią poprawy. Wersja podstawowa wtyczki jest darmowa. Dla właściciela-nietechnicznego sama lista błędów może być trudniejsza do zinterpretowania niż kolorowe oznaczenia WAVE, ale warto przekazać raport z axe swojemu developerowi.
Lighthouse – to narzędzie wbudowane w przeglądarkę Chrome (panel DevTools > zakładka Lighthouse lub Audits). Pozwala przeprowadzić automatyczny audyt strony pod kątem kilku aspektów, w tym Accessibility. Wynikiem jest raport z ogólnym wynikiem (score) dostępności od 0 do 100 oraz listą znalezionych problemów podzielonych na kategorie (np. kontrast, nazwy przycisków, etc.). Lighthouse jest proste w użyciu – wystarczy uruchomić audyt – i szybko daje pogląd, jak strona wypada. Wadą jest to, że ocena jest dość ogólna i trzeba uważać, by nie “grać pod wynik” – celem nie jest 100/100 w Lighthouse, ale realna dostępność (można np. oszukać Lighthouse dodając aria-label byle gdzie, co podniesie wynik, ale niekoniecznie poprawi UX). Mimo to, Lighthouse jest świetne do monitoringu postępów – np. po wdrożeniu poprawek możesz zobaczyć, czy Twój wynik wzrósł z 50 na 90, co oznacza, że większość problemów zniknęła.
Inne narzędzia i metody – poza powyższymi trzema, warto wspomnieć o kilku dodatkowych. Narzędzia do analizy kontrastu: np. Accessible Color Contrast Checker czy wtyczki typu Contrast Lens – pozwalają sprawdzić dokładny współczynnik kontrastu dwóch wybranych kolorów (przydatne dla grafików dobierających paletę). Screen Reader: samodzielne przetestowanie sklepu przy użyciu czytnika ekranu (np. darmowego NVDA na Windows lub VoiceOver na Mac) to bezcenna metoda na wyłapanie problemów, których automat nie wyłapie – usłyszysz stronę tak, jak słyszą ją osoby niewidome. Accessibility Insights: kompleksowe narzędzie od Microsoft (też jako wtyczka), które krok po kroku prowadzi przez testy (łączy automatyczne i częściowo manualne sprawdzanie). Validatory kodu (HTML/CSS): poprawny kod to podstawa solidności – skorzystaj z validator.w3.org żeby wykluczyć grube błędy w HTML, które mogą zakłócać działanie asystujących technologii. Ponadto, jeśli masz dostęp do testerskich urządzeń mobilnych, sprawdź na nich nawigację po sklepie za pomocą wbudowanych ułatwień dostępu (TalkBack na Androidzie, VoiceOver na iPhone). No i nie zapominaj o ludziach – jeśli masz możliwość, zaangażuj realnych użytkowników z niepełnosprawnościami do oceny sklepu, choćby w formie feedbacku. Żadne narzędzie nie zastąpi prawdziwych doświadczeń użytkownika.

Na koniec pamiętaj: narzędzia audytowe to pomoc, ale nie wyrocznia. Wykorzystuj je, aby łatwiej zidentyfikować problemy i weryfikować postępy, ale finalnie to Ty (lub specjalista) musisz ocenić użyteczność. Jak wspomniano wcześniej, nawet najlepszy skaner nie oceni jakości tekstów czy intuicyjności nawigacji. Kombinuj różne metody – automatyczne i manualne – by osiągnąć pełny obraz dostępności swojego e-sklepu.

Checklista dla właściciela sklepu

Poniżej przedstawiamy checklistę kontrolną, która pomoże Ci szybko ocenić, czy Twój sklep spełnia podstawowe wymogi dostępności. Możesz ją wykorzystać samodzielnie lub przekazać swojemu zespołowi/deweloperowi. Sprawdź, czy:

Obrazy i grafiki mają poprawne opisy alt – Każdy obraz zawierający istotną informację powinien mieć atrybut alt opisujący jego treść lub funkcję. Jeśli obraz jest czysto dekoracyjny, alt może być pusty (alt=""), ale upewnij się, że tak jest rzadkością. Przykładowo: logo firmy może mieć alt „Logo [Twoja Firma]” (jeśli pełni rolę linku na stronę główną, rozważ dodanie w alt np. „[Twoja Firma] – powrót do strony głównej”). Zdjęcia produktów – opis produktu, np. „buty sportowe model X, kolor czarny, widok z boku”.
Nagłówki i struktura strony są logiczne – Przejrzyj stronę główną i kluczowe podstrony pod kątem nagłówków. Powinna być użyta hierarchia h1, h2, h3... zgodnie z układem treści. Czy na każdej podstronie jest dokładnie jeden h1 (tytuł strony lub nazwa produktu)? Czy podsekcje mają h2/h3 w kolejności, bez przeskakiwania poziomów? Upewnij się, że nie stosujesz nagłówków tylko dla stylu (np.
bo tekst ma być większy) – nagłówek oznacza logiczną sekcję. Dobra struktura pomaga zarówno użytkownikom, jak i SEO.
Można nawigować po sklepie za pomocą klawiatury – Spróbuj sam: otwórz stronę i używając klawisza Tab przechodź przez kolejne elementy interaktywne. Czy fokusem da się objąć wszystkie ważne linki i przyciski? Czy fokus jest widoczny (np. obramowanie lub podświetlenie na aktywnym elemencie)? Spróbuj otworzyć menu główne i przejść po nim strzałkami/tabulatorem. Sprawdź, czy wejdziesz do podstron, dodasz produkt do koszyka i wypełnisz formularz – wszystko tylko klawiaturą. Jeśli gdzieś “utkniesz” albo nie wiesz, gdzie jesteś na stronie (brak widocznego fokusa), to znak, że trzeba to naprawić. Każda funkcja (rozwijanie filtrów, paginacja, zamykanie modali itp.) powinna mieć obsługę klawiatury.
Kolorystyka spełnia wymogi kontrastu – Oceń (lub użyj narzędzia) główne zestawienia kolorów: tekst vs tło, linki vs tło, przyciski vs tekst na nich. Czytelność musi być dobra. Jeśli nie jesteś pewien, skorzystaj z darmowego testera kontrastu – wpisz kod koloru tekstu i tła, sprawdź czy wynik >= 4.5:1 (dla normalnego tekstu). Przy okazji, czy treści przekazywane kolorem mają też dodatkowe oznaczenie? Np. błędne pole formularza – czy oprócz czerwonej ramki jest np. ikonka błędu lub tekst? Linki w tekście – czy odróżniają się nie tylko kolorem, ale np. podkreśleniem? To ważne dla osób niewidzących kolorów.
Formularze są przyjazne i opisane – Przejrzyj formularze (rejestracja, logowanie, wyszukiwarka, checkout). Czy każde pole ma label (widoczny tekst lub ukryty dla czytników)? Kliknięcie w tekst etykiety powinno aktywować pole (to test powiązania label-for). Czy pola mają podpowiedzi lub opisy, jeśli potrzebne? Np. format daty, wymagania co do hasła – czy są wyjaśnione? Sprawdź komunikaty błędów: wprowadź błąd (np. pusty formularz) i zobacz, co się dzieje. Czy pojawia się tekst z informacją co poprawić? Idealnie komunikat powinien się pojawić obok błędnego pola i być odczytywany przez czytnik (np. poprzez aria-describedby). Upewnij się też, że po kliknięciu “wyślij” fokus nie znika – powinien przejść np. na pierwszy błąd.
Multimedia i animacje nie wykluczają użytkowników – Jeśli masz materiały wideo, są do nich dodane napisy lub przynajmniej streszczenie treści w opisie? Czy automatyczne karuzele/banery mają możliwość zatrzymania przewijania? Unikaj treści migających. Jeśli używasz animowanych GIF-ów lub autoodtwarzających się filmów, upewnij się, że nie są uciążliwe – lepiej, by video nie startowało samo (albo aby było domyślnie wyciszone i z opcją odtworzenia).
Poprawność techniczna – To punkt dla Twojego działu technicznego: czy kod HTML sklepu jest wolny od poważnych błędów? Jeśli możesz, sprawdź stronę główną przez validator W3C – jeżeli sypie setką errorów, warto to uporządkować. Sprawdź, czy wszystkie interaktywne elementy mają unikalne id (jeśli potrzebne), czy atrybuty ARIA używane są zgodnie z przeznaczeniem (błędne użycie ARIA może pogorszyć dostępność). Upewnij się, że żadne istotne funkcje nie opierają się tylko na JavaScript bez alternatywy – np. link, który nie ma href tylko nasłuchuje eventu onclick (taki element dla czytnika może być “martwy”). Lepiej użyć <button> lub <a href="#">. Ogólnie strona powinna renderować się sensownie nawet przy wyłączonych stylach – to szybki test na semantykę: wyłącz CSS i zobacz, czy kolejność treści nadal jest logiczna.
Wsparcie dla różnych urządzeń – Otwórz sklep na smartfonie i tablecie. Czy interakcje (zwłaszcza dotykowe) działają poprawnie? Elementy nie powinny być zbyt małe (WCAG zaleca minimum \~44px wysokości dla przycisków). Sprawdź powiększenie – czy przy zoomie 200% layout w wersji mobilnej/desktopowej nie rozsypuje się? Również, jeśli masz możliwość, użyj trybu wysokiego kontrastu w systemie (Windows High Contrast Mode) lub trybu ciemnego – czy strona jest czytelna (to nie obowiązek WCAG, ale coraz więcej użytkowników korzysta z dark mode).
Dostępność treści i linków – Przejrzyj teksty na stronie: czy linki mają zrozumiałe opisy? Unikaj wielu linków o treści "kliknij tutaj" – link powinien mówić, dokąd prowadzi (np. "Regulamin sklepu" zamiast "kliknij tutaj"). Czy język strony jest ustawiony prawidłowo (<html lang="pl"> dla polskiej wersji)? Czy jeśli masz fragmenty w innym języku (np. cytat po angielsku), są oznaczone lang? To drobiazgi, które jednak wpływają na odbiór przez asystywne technologie.
Deklaracja dostępności i kontakt – Sprawdź, czy na stronie (np. w stopce) znajduje się informacja o dostępności. Dla zgodności z EAA powinieneś opublikować Deklarację dostępności, jak omawialiśmy wyżej. Upewnij się, że zawiera ona aktualne informacje i dane kontaktowe. Spróbuj wysłać testowego maila przez formularz kontaktowy – czy obsługa klienta wie, jak reagować na zgłoszenia od osób z niepełnosprawnościami? Np. jeśli ktoś poprosi o podanie informacji w alternatywnym formacie (lepsze zdjęcia produktu, bo obecne są zbyt małe), czy macie procedurę, aby pomóc?

Ta checklista nie jest wyczerpująca, ale pokrywa najważniejsze punkty, które właściciel e-sklepu może sam zweryfikować lub zlecić do sprawdzenia swojemu zespołowi. Regularne przechodzenie przez taką listę – np. przed większym updatem sklepu albo co kilka miesięcy – pomoże wychwycić problemy zanim staną się poważne.

Podsumowanie i plan działania

Dostępność cyfrowa to już nie luksus czy niszowy wymóg – to fundament nowoczesnego e-commerce. Zapewnienie zgodności z WCAG 2.1 i przepisami EAA sprawi, że Twój sklep PrestaShop będzie przyjazny dla wszystkich klientów, co przełoży się na ich zadowolenie, lojalność i pozytywny wizerunek Twojej marki. To także minimalizacja ryzyka prawnego oraz lepsze wyniki biznesowe – dostępny sklep potrafi zwiększyć współczynnik konwersji nawet o kilkanaście procent, a przy okazji poprawia SEO i ogólną użyteczność. Krótko mówiąc, WCAG się opłaca.

Zdobyłeś właśnie sporą dawkę wiedzy – czas przekuć ją w konkretne działania. Oto plan działania dla Ciebie jako właściciela sklepu:

Zapoznaj się ze stanem obecnym – Wykonaj wstępny audyt: użyj narzędzi takich jak WAVE czy Lighthouse, przejdź sklep klawiaturą, zanotuj zauważone problemy. To da Ci obraz, od czego zacząć.
Ustal priorytety i zbierz zasoby – Na bazie audytu przygotuj listę rzeczy do poprawy. Zdecyduj, co zrobisz sam (np. uzupełnienie alt tekstów w panelu PrestaShop), a do czego potrzebujesz wsparcia dewelopera lub specjalisty. Zaplanuj budżet i czas na te poprawki.
Wdrażaj zmiany krok po kroku – Zacznij od najważniejszych kwestii (te, które blokują podstawowe funkcje dla użytkowników, np. brak nawigacji klawiaturą w menu czy kluczowych alt tekstów). Wprowadzaj poprawki w kodzie i treści zgodnie z omówionymi zasadami. Testuj na bieżąco po każdej większej zmianie.
Włącz dostępność w codzienne działania – Przeszkol swój zespół (redaktorów, obsługę produktu, marketing) z podstaw dostępności. Ustal wewnętrzne checklisty jakości – np. dodając nowy produkt, zawsze wypełniamy opis pola alt; tworząc nową stronę, sprawdzamy strukturę nagłówków; projektując grafikę, dbamy o kontrast. Dzięki temu utrzymasz dostępność w dłuższej perspektywie.
Przygotuj Deklarację Dostępności – Gdy uznasz, że sklep spełnia (w dużej mierze) wymogi WCAG 2.1 AA, sporządź oficjalną deklarację. Wzór możesz zaczerpnąć z publicznych instytucji, dostosowując do swojego kontekstu. Umieść ją na stronie i bądź gotów na ewentualne pytania ze strony klientów czy organów nadzoru.
Monitoruj i doskonal – Uczyń zwyczajem okresowy przegląd dostępności: np. co kwartał odpal Lighthouse i zobacz wynik, raz do roku zamów zewnętrzny audyt lub skorzystaj z konsultacji eksperta, śledź aktualizacje WCAG (np. WCAG 2.2) i EAA, bo standardy ewoluują. Jeśli pojawiają się nowe wymagania – reaguj zawczasu.

Na koniec, pamiętaj o głównej idei: sklep internetowy ma być wygodny dla każdego użytkownika. Dzięki wdrożeniu zasad dostępności zyskasz nie tylko zgodność z prawem, ale przede wszystkim większe grono zadowolonych klientów i przewagę konkurencyjną na rynku. Dostosowanie PrestaShop do WCAG 2.1 i EAA może wymagać wysiłku, ale jest to wysiłek, który się opłaci – prawnie, finansowo i wizerunkowo. Powodzenia w wdrażaniu dostępności w Twoim e-sklepie!

Informacje prawne

Informacje zawarte na tej stronie zostały opracowane na podstawie dostępnych źródeł publicznych oraz interpretacji przepisów obowiązujących na dzień publikacji. Nie stanowią one porady prawnej ani oficjalnej wykładni prawa. Serwis SEIGI.eu nie jest kancelarią prawną, a przedstawione treści mają charakter ogólny i informacyjny. W razie wątpliwości zalecamy konsultację z wykwalifikowanym doradcą prawnym lub kancelarią specjalizującą się w prawie europejskim i handlu elektronicznym.