Zgodność z WCAG 2.1 AA w sklepie oznacza jedno: osoba korzystająca z klawiatury, czytnika ekranu albo powiększenia może samodzielnie znaleźć produkt, dodać go do koszyka i sfinalizować zamówienie. Poziom AA nie jest wyborem – to próg wskazany przez zharmonizowaną normę europejską EN 301 549, która technicznie definiuje wymagania dostępności cyfrowej w Unii.

Od 28 czerwca 2025 roku obowiązuje European Accessibility Act (Dyrektywa 2019/882), który obejmuje większość sklepów e-commerce w UE. Szczegóły obowiązku, wyłączeń dla mikroprzedsiębiorstw i sankcji opisujemy osobno – jeśli szukasz strony prawnej, zajrzyj do wpisu akt o dostępności 2025. Tutaj skupiamy się wyłącznie na technicznej egzekucji: bariera w WooCommerce, naprawa, kryterium. To przewodnik po tym, co realnie poprawić, a nie kolejny przegląd przepisów.

Warto od razu ustawić proporcje. Dostępność Twojego sklepu w dużej mierze zależy od motywu i sposobu wdrożenia, a nie od pojedynczej wtyczki. Dlatego kolejne sekcje prowadzą Cię przez faktyczne ekrany, po których klient się porusza.

Pierwszy test dostępności sklepu jest darmowy i zajmuje kilka minut: odłóż mysz i przejdź całą drogę zakupu samym klawiszem Tab (oraz Shift+Tab, Enter, Escape). Jeśli gdzieś utkniesz albo nie zobaczysz, na czym jesteś, masz problem.

Siatka produktów i mega-menu kategorii

Rozwijane menu kategorii często działa tylko na najechanie myszą – znika, gdy tylko ruszysz kursorem, i nie da się go obsłużyć z klawiatury. Menu musi otwierać się także na fokus, pozostawać widoczne, gdy najedziesz na jego treść, i zamykać się klawiszem Escape. To wymóg kryterium 1.4.13 Treść spod kursora lub fokusu (AA), dodanego właśnie w WCAG 2.1. W siatce produktów upewnij się, że do każdej karty i przycisku da się dojść Tabem w logicznej kolejności.

Karta produktu, warianty, koszyk i quick-view

Modale quick-view oraz szuflada mini-koszyka to najczęstsze pułapki fokusu: po otwarciu fokus zostaje uwięziony i klawiatura przestaje działać na reszcie strony, albo – odwrotnie – ucieka w tło, do niewidocznej zawartości. Cała ścieżka (siatka produktów, karta, koszyk, checkout) musi być operowalna z klawiatury, każdy modal zamykalny Escape, a fokus po zamknięciu ma wracać tam, skąd przyszedł. To kryteria 2.1.1 Klawiatura (A), 2.1.2 Brak pułapki klawiatury (A) oraz 2.4.3 Kolejność fokusu (A).

Widoczny wskaźnik fokusu

Wiele motywów WooCommerce i resetów CSS usuwa domyślny outline z linków i przycisków. Efekt: osoba na klawiaturze nie wie, na którym elemencie stoi. Każdy element interaktywny – link produktu, przycisk dodaj do koszyka, pola checkoutu – musi mieć wyraźny, kontrastowy wskaźnik fokusu. Wymaga tego 2.4.7 Fokus widoczny (AA), a sam wskaźnik i obramowania pól powinny mieć kontrast min. 3:1 względem tła (1.4.11 Kontrast elementów nietekstowych (AA)).

Checkout to miejsce, w którym niedostępność kosztuje najwięcej – tu klient albo kupuje, albo rezygnuje.

Etykiety zamiast placeholderów

Popularny wzorzec – pole z samym placeholderem zamiast trwałej etykiety – jest niedostępny: placeholder znika po kliknięciu, a czytnik ekranu nie zawsze go czyta. Każde pole formularza koszyka i checkoutu musi mieć widoczną etykietę `` trwale powiązaną z polem przez atrybuty `for` i `id`. To fundament dostępnych formularzy: 3.3.2 Etykiety lub instrukcje (A) i 1.3.1 Informacje i relacje (A). Dodaj też atrybut `autocomplete` na polach danych osobowych i adresowych – to kryterium 1.3.5 Określenie pożądanej wartości (AA) i realne ułatwienie dla wszystkich.

Komunikaty błędów i sugestie korekty

Błąd sygnalizowany samym czerwonym obramowaniem jest niewidoczny dla osoby nierozpoznającej kolorów i dla czytnika ekranu. Komunikat o błędzie musi być podany tekstem, powiązany z polem (np. przez `aria-describedby`) i – jeśli to możliwe – podpowiadać poprawkę, np. oczekiwany format kodu pocztowego. Odpowiadają za to 3.3.1 Identyfikacja błędu (A) oraz 3.3.3 Sugestia korekty błędu (AA).

Krok płatności: możliwość weryfikacji zamówienia

Przy kroku, który rodzi skutki finansowe, klient musi mieć szansę przejrzeć i poprawić zamówienie przed ostatecznym kliknięciem finalizacji. WCAG nazywa to 3.3.4 Zapobieganie błędom (prawnym, finansowym, w danych) (AA). W praktyce: widoczne podsumowanie koszyka, możliwość zmiany ilości i danych, brak automatycznej finalizacji bez potwierdzenia.

Teksty alternatywne zdjęć produktów i galerie

Przy masowym imporcie produktów zdjęcia lądują z pustym atrybutem `alt` albo z `alt` równym nazwie pliku (IMG_2043.jpg) – dla osoby niewidomej to bezużyteczny szum. Każde zdjęcie produktu powinno mieć sensowny opis (np. płaszcz wełniany damski, kolor grafitowy), a zdjęcia czysto dekoracyjne – pusty `alt=""`, żeby czytnik je pominął. To kryterium 1.1.1 Treść nietekstowa (A). W galeriach i lightboxach zadbaj, by kolejne zdjęcia dało się przełączać z klawiatury i by miały opisy.

Osobna pułapka to swatche wariantów (próbki kolorów, rozmiarów). Sama próbka koloru nie wystarczy – każdy wariant musi mieć dostępną nazwę (kolor, rozmiar), bo kolor nie może być jedynym nośnikiem informacji. To samo dotyczy statusu dostępności towaru sygnalizowanego wyłącznie kolorem. Odpowiada za to 1.4.1 Użycie koloru (A).

Kontrast CTA, cen, promocji i statusów

Modne jasnoszare ceny, delikatne etykiety promocja czy brak w magazynie oraz przycisk dodaj do koszyka w niskokontrastowym kolorze to klasyka niedostępnych sklepów – i rzecz silnie zależna od motywu. Progi są konkretne: tekst zwykły min. 4.5:1, tekst duży (od 18pt lub 14pt pogrubiony) min. 3:1 (1.4.3 Kontrast minimum (AA)), a granice przycisków, pól i ikony-kontrolki min. 3:1 (1.4.11 Kontrast elementów nietekstowych (AA)). Sprawdź to zwłaszcza na przyciskach akcji i cenach promocyjnych.

To serce problemu dostępności w WooCommerce i miejsce, którego prawie nikt nie opisuje. WooCommerce mocno korzysta z AJAX-a: dodanie produktu, aktualizacja licznika mini-koszyka, zastosowanie kuponu, przeliczenie sumy czy komunikat o stanie magazynu zmieniają zawartość strony bez przeładowania i – co gorsza – bez przeniesienia fokusu.

AJAX dodano do koszyka i mini-koszyk, których NVDA nie ogłasza

Dla osoby widzącej myszą wszystko działa: klika, produkt ląduje w koszyku, licznik rośnie. Dla osoby niewidomej korzystającej z NVDA albo VoiceOver nie dzieje się nic – czytnik nie ogłasza żadnej zmiany, bo DOM zmienił się po cichu. Rozwiązanie to umieszczenie komunikatów statusu w regionie `aria-live` lub `role="status"`, który ogłasza treść bez zabierania fokusu. To dokładnie kryterium 4.1.3 Komunikaty o stanie (AA) – i warto wiedzieć, że zostało ono dodane w WCAG 2.1, co jest jednym z powodów, dla których EAA wskazuje właśnie poziom 2.1 AA, a nie starszy 2.0.

Warianty, oceny i stepper ilości jako custom widgety

Selektor wariantu, gwiazdki oceny i stepper ilości są często budowane jako własne komponenty z `

Dostępność sklepu WooCommerce jest w dużej części funkcją motywu i użytego page-buildera – to tam rodzi się lub gaśnie większość problemów z poprzednich sekcji.

Jak wybrać i zweryfikować motyw pod WCAG

Szukaj motywu z deklarowanym wsparciem dostępności (accessibility-ready), ale traktuj tę etykietę jako punkt startu, nie gwarancję. Po instalacji zweryfikuj semantykę: jeden nagłówek `

` na stronie, logiczna hierarchia nagłówków bez przeskoków oraz obecność znaczników struktury `header`, `nav`, `main` i `footer`. Poprawne nagłówki i etykiety to kryterium 2.4.6 Nagłówki i etykiety (AA), a poprawna struktura – 1.3.1 Informacje i relacje (A). Nie ma jednego uniwersalnie zgodnego motywu; decyduje implementacja i treści.

Ryzyko Elementora i WPBakery

Ciężkie page-buildery, takie jak Elementor czy WPBakery, potrafią generować zagnieżdżone struktury `

Nie potrzebujesz od razu pełnego audytu, żeby złapać najgrubsze błędy. Podstawowy przegląd zajmuje około 30 minut i wymaga tylko darmowych narzędzi.

• Klawiatura – przejdź całą ścieżkę zakupu (produkt, koszyk, checkout) samym klawiszem Tab. Sprawdź, czy wszędzie widać fokus i czy nic nie uwięzi kursora.
• Czytnik ekranu – włącz NVDA (darmowy, Windows) albo VoiceOver (macOS) i posłuchaj, czy sklep ogłasza dodano do koszyka oraz czy odczytuje etykiety pól.
• Skanery automatyczne – uruchom axe DevTools, WAVE (WebAIM) albo zakładkę Accessibility w Lighthouse (Chrome), by wyłapać braki kontrastu i puste atrybuty `alt`.

Ważny warunek brzegowy: narzędzia automatyczne oraz nakładki typu overlay wykrywają lub łatają tylko część problemów – sens tekstów alternatywnych, logikę fokusu w checkout czy komunikaty AJAX trzeba sprawdzić ręcznie. Dlatego overlay nie czyni sklepu zgodnym z WCAG; więcej o tym, dlaczego nakładka to nie zgodność, znajdziesz we wpisie o dofinansowaniu dostępności cyfrowej. Jeśli chcesz poznać zakres i koszt profesjonalnego badania, zajrzyj do wpisu audyt WCAG – cennik i zakres.

Kiedy audyt manualny wykryje więcej, niż jesteś w stanie poprawić samodzielnie, warto oddać to specjalistom. Zajmujemy się wdrożeniem WCAG dla sklepów WooCommerce oraz budową i optymalizacją sklepów internetowych od strony dostępności i konwersji. Umów bezpłatną konsultację, a przejdziemy Twoją ścieżkę zakupową i wskażemy konkretne poprawki.