Dostępność WooCommerce: błędy WCAG w 110 polskich sklepach

Skan przeprowadziłem 13 września 2026 roku narzędziem axe-core 4.13 w przeglądarce Chromium, na ekranie 1366×900. Sprawdzałem reguły WCAG 2.0 i 2.1 na poziomach A i AA.

Próba objęła 114 sklepów z polskojęzyczną stroną, a WooCommerce potwierdziłem w kodzie każdej z nich. 74 sklepy znalazłem w wyszukiwarce po domyślnych adresach WooCommerce w 38 branżach, a 40 pochodziło z portfoliów 13 agencji, najwyżej 12 z jednej. Sklepy z obu źródeł wypadły prawie tak samo: mediana 5 i 4 rodzajów naruszeń, błąd krytyczny w 73% i 69% z nich.

Poprawnie odpowiedziało 110 sklepów. W każdym sprawdziłem stronę główną, kategorię i kartę produktu, razem 301 stron. Nie skanowałem koszyka ani kasy, bo wymagałoby to dodawania produktów do koszyka w cudzych sklepach.

Automat wykrywa tylko część barier. Nie ocenia obsługi klawiaturą, kolejności czytania ani tego, czy tekst alternatywny rzeczywiście opisuje obraz. Nazw sklepów nie podaję, bo celem jest obraz rynku, a nie ranking.

Mediana wyniosła 5 różnych rodzajów naruszeń i 96 elementów z błędem na sklep, licząc łącznie trzy sprawdzone strony. Najczęstsze problemy dotyczyły kontrastu i nazw linków, ale lista obejmuje też obrazy, formularze, strukturę list i kod ARIA.

Każda z tych reguł opisuje konkretną barierę dla użytkownika. Sposób naprawy zależy od tego, skąd element pochodzi: z motywu, z wtyczki albo z treści wprowadzonej w panelu.

Za niski kontrast tekstu wystąpił w 96% sklepów, z medianą 73 elementów na sklep. W przykładach powtarzały się linki, przyciski, plakietki, ceny i pozycje menu.

Dwa wzorce są typowe dla WooCommerce. Przekreślona stara cena albo cena o za niskim kontraście pojawiła się w co najmniej 24% sklepów, a plakietka promocji w co najmniej 10%. Słabowidzący klient nie odczyta wtedy informacji, która decyduje o zakupie.

Zwykły tekst powinien mieć kontrast co najmniej 4,5:1, a duży 3:1. Poprawka to zmiana koloru tekstu albo tła w stylach motywu i sprawdzenie wszystkich stanów elementu, także linków i przycisków po najechaniu kursorem.

Link bez dostępnej nazwy pojawił się w 85% sklepów, z medianą 15 takich elementów na sklep, a przycisk bez nazwy w 24%. Czytnik ekranu odczytuje taki element tylko jako „link” albo „przycisk”, bez informacji, dokąd prowadzi i co robi.

Źródła powtarzają się między sklepami: ikony serwisów społecznościowych, zdjęcia produktów na liście, lupa wyszukiwarki, kropki slidera i przyciski ilości. Ikona, którą widać, nie wystarcza, jeśli jej znaczenie nie trafia do dostępnej nazwy.

Naprawa to zwykle dodanie zrozumiałego tekstu albo atrybutu aria-label, na przykład „Szukaj” przy lupie czy „Zwiększ ilość” przy plusie. Element dekoracyjny nie powinien przejmować fokusu, a element, który coś robi, musi mieć właściwą rolę i nazwę.

Zakładki z opisem i informacjami dodatkowymi miały zagnieżdżone elementy interaktywne albo błędne role ARIA w co najmniej 24% sklepów. Czytnik ekranu dostaje wtedy sprzeczne informacje o tym, co jest zakładką, która jest aktywna i jaką treść pokazuje.

Lista rozwijana bez etykiety wystąpiła w 11% sklepów, między innymi przy wyborze wariantu i sortowaniu produktów. Pole formularza bez etykiety (16%) to z kolei najczęściej zapis do newslettera albo formularz kontaktowy, a nie sama karta produktu.

W co najmniej 13% sklepów karuzela ukrywała slajdy przed czytnikiem ekranu, ale zostawiała w nich linki dostępne z klawiatury. Użytkownik przechodzi wtedy Tabem przez elementy, których nie widzi. Zakładki trzeba oprzeć na spójnych rolach ARIA bez zagnieżdżania, a ukrytym slajdom odebrać fokus.

Blokadę powiększania wykryłem w 31% sklepów. Prawie zawsze powodował ją zapis maximum-scale=1.0, user-scalable=no w znaczniku viewport motywu.

Słabowidzący klient na telefonie nie powiększy wtedy tekstu, ceny ani pól formularza. Responsywny układ tego nie rozwiązuje, bo dopasowanie strony do ekranu i możliwość jej powiększenia to dwie osobne rzeczy.

Naprawa zajmuje chwilę: usunięcie ograniczeń maximum-scale i user-scalable ze znacznika viewport. Po zmianie warto sprawdzić, czy menu i przyciski działają po powiększeniu.

Obrazek bez tekstu alternatywnego wystąpił w 35% sklepów. Axe traktuje to jako błąd krytyczny, bo osoba korzystająca z czytnika ekranu traci informację przekazaną wyłącznie obrazem.

W przykładach, które dało się rozpoznać, najczęściej były to ikony wgrane jako obrazki (co najmniej 11 sklepów) i logotypy, a rzadziej zdjęcia produktów. Samo uzupełnienie pola nie gwarantuje poprawy: automat wykryje brak opisu, ale nie oceni, czy opis ma sens.

Zdjęcia produktów potrzebują opisów wynikających z ich funkcji, a obrazy czysto dekoracyjne pustego atrybutu alt, żeby czytnik je pominął. W WooCommerce poprawia się to w danych mediów i w szablonie, który generuje obrazki na liście i karcie produktu.

Page builder słabo różnicował wynik. Błąd krytyczny wystąpił w 67% spośród 67 sklepów z Elementorem, w 77% spośród 22 sklepów z Divi i w 63% spośród 16 sklepów bez buildera.

Próba sklepów bez buildera jest mała, więc nie traktuję tych liczb jako rankingu narzędzi. Wskazują raczej, że problem siedzi w połączeniu motywu, wtyczek i treści, a nie w samym edytorze.

Zmiana edytora nie naprawi nazw przycisków, kontrastu cen ani etykiet formularzy. Trzeba znaleźć komponent, który generuje wadliwy kod, poprawić go i sprawdzić wszystkie miejsca, w których jest używany.

Automatyczny skan szybko pokazuje powtarzalne naruszenia, ale nie potwierdza zgodności sklepu. W tym badaniu nie objął koszyka ani kasy, a to tam klient podaje dane i płaci.

Rozsądna kolejność to najpierw błędy krytyczne i poważne w szablonach, potem ręczne przejście całej ścieżki zakupowej klawiaturą. Zakres wymagań opisałem we wpisie o WCAG 2.1 AA, a pełny audyt WCAG łączy skan z testami klawiaturą i czytnikiem ekranu.

Po naprawie warto co jakiś czas sprawdzać te same szablony, bo aktualizacje motywu i wtyczek zmieniają generowany kod. Dlatego dostępność powinna być częścią bieżącej opieki nad sklepem na WordPressie, a przy budowie nowego sklepu WooCommerce warto uwzględnić ją od początku.