Dostępny sklep WooCommerce: WCAG w ścieżce zakupowej

W zleceniu audytu wpisz wersję WCAG, poziom i zakres ekranów. Dla rozwijanego sklepu można przyjąć WCAG 2.2 AA jako cel techniczny. Nie sprowadzaj zgodności do wybranych kilku kryteriów. Problemy potrafią występować dopiero po zmianie wariantu, odrzuceniu płatności lub otwarciu panelu dostawy.

W Polsce obowiązki wynikają z ustawy o dostępności niektórych produktów i usług. Obejmuje ona wskazane usługi konsumenckie, w tym handel elektroniczny; wyłącza usługi oferowane lub świadczone przez mikroprzedsiębiorców. Nie oznacza to automatycznego wyłączenia wszystkich obowiązków dotyczących produktów takiej firmy. Zakres konkretnej działalności trzeba ustalić oddzielnie.

Wykaz Ministerstwa Cyfryzacji, odczytany we wrześniu 2026 roku, wskazuje EN 301 549 V3.2.1 i trwającą aktualizację. Nie utożsamiaj pozytywnego wyniku kilku testów WCAG z potwierdzeniem wszystkich wymagań PAD.

Lista do badania powinna obejmować katalog, wyszukiwarkę, produkt, koszyk, checkout, logowanie i stany błędów. Dodaj elementy zewnętrzne, które klient musi obsłużyć. Zapisz też, czy sklep korzysta z klasycznego checkoutu, bloków WooCommerce czy własnej implementacji. Poprawka dla jednego wariantu nie musi działać w drugim.

Odłóż mysz i spróbuj odnaleźć produkt. Sprawdź przejście przez menu, wyszukiwarkę, filtry oraz listę wyników. Tab i Shift+Tab przechodzą między wieloma kontrolkami, ale wybrane komponenty mają własne wzorce obsługi strzałkami, Enterem lub spacją. Instrukcja powinna odpowiadać faktycznie użytemu elementowi.

Zwróć uwagę na widoczność fokusu. Po każdym kroku powinno być jasne, który element zareaguje na aktywację. Usunięty outline bez zastępstwa utrudnia orientację. Sprawdź także, czy stały nagłówek, pasek zgód albo przycisk na dole ekranu nie zasłania aktywnej kontrolki.

Menu otwierane najechaniem wymaga dostępnego sposobu obsługi z klawiatury. Jeśli pojawia się dodatkowa treść po najechaniu lub fokusie, trzeba ocenić jej zamykanie, dostępność po przesunięciu wskaźnika i utrzymanie widoczności zgodnie z kryterium 1.4.13. Nie zakładaj, że sam efekt rozwijania spełnia te warunki.

W raporcie zapisuj pełną drogę do błędu: ekran, użyte klawisze, oczekiwane zachowanie i wynik. Opis 'menu niedostępne' nie mówi wykonawcy, czy problemem jest brak dojścia, niewidoczny fokus, czy zamykanie panelu w trakcie nawigacji. Dobrze opisany błąd łatwiej później odtworzyć i odebrać.

Otwarcie modalnego okna wymaga przewidywalnej zmiany miejsca pracy. Fokus powinien trafić do jego wnętrza, a zawartość tła nie może zachowywać się jak równocześnie dostępna część aktywnego dialogu. Przechodzenie Tabem wewnątrz otwartego modala jest prawidłowe. Pułapka powstaje wtedy, gdy użytkownik nie potrafi go zamknąć lub opuścić zgodnie z jego działaniem.

Sprawdź dostępną nazwę okna, przycisk zamknięcia i klawisz Escape. Po zamknięciu fokus zwykle wraca do elementu wywołującego; jeśli ten zniknął, potrzebne jest logiczne następne miejsce. Szczegóły wzorca opisuje WAI w dokumentacji dialogu modalnego.

Nie każdy mini-koszyk jest modalem. Szuflada, panel rozwijany i nowa strona mogą wymagać innej obsługi. Najpierw ustal zachowanie komponentu, potem dobierz semantykę i test. Dodanie atrybutu ARIA bez poprawienia interakcji nie rozwiązuje problemu.

W poradniku quick view WooCommerce znajdziesz szerszy kontekst wyboru tej funkcji. Przy odbiorze dostępności sprawdź produkt z wariantami i błędem dodania do koszyka, a nie tylko najprostszy podgląd. To właśnie dodatkowy stan często ujawnia utratę fokusu lub brak czytelnego komunikatu.

Pole powinno mieć zrozumiałą etykietę, którą użytkownik widzi i którą technologia wspomagająca potrafi powiązać z kontrolką. Placeholder nie jest trwałym zastępstwem. Typowym rozwiązaniem jest label z atrybutem for wskazującym id pola; istnieją też inne poprawne techniki, opisane w poradniku etykiet formularzy WAI.

Sprawdź pola obowiązkowe, format danych i podpowiedzi. Sam czerwony kolor nie wystarcza do wskazania błędu. Komunikat powinien nazywać problem i, gdy można, sposób poprawy. Powiązanie z polem, na przykład przez aria-describedby, pomaga odczytać wyjaśnienie we właściwym miejscu.

Przetestuj kilka pomyłek jednocześnie: brak wymaganej wartości, niewłaściwy format i niedostępną metodę dostawy. Po nieudanej próbie użytkownik powinien odnaleźć błędy, poprawić je i kontynuować bez niepotrzebnej utraty danych. Sprawdź, czy podsumowanie błędów i komunikaty przy polach nie przeczą sobie.

Zwróć uwagę na autocomplete przy danych osobowych oraz adresowych, zgodnie z zakresem kryterium 1.3.5. Jeśli sklep zna już dane potrzebne w następnym kroku tego samego procesu, nie powinien bez uzasadnienia zmuszać do ich ponownego wpisywania. Przy finalizacji zamówienia zapewnij możliwość sprawdzenia i poprawienia danych w ramach sposobów spełnienia kryterium 3.3.4.

Tekst alternatywny dobiera się do funkcji obrazu. Zdjęcie pokazujące istotny szczegół produktu może potrzebować opisu, a obraz dekoracyjny lub redundantny odpowiednio pustego alt. Nazwa pliku nie wyjaśnia cechy towaru. Pomocne jest drzewo decyzji WAI dla obrazów.

Na karcie produktu sprawdź galerię, powiększenie oraz podpisy. Klient powinien móc przejść między zdjęciami i zamknąć podgląd. Swatch koloru wymaga dostępnej nazwy i informacji o wyborze. Sam kolor nie może być jedynym sposobem oznaczenia wariantu, błędu lub niedostępności.

Tekst zwykły wymaga kontrastu co najmniej 4,5:1, a duży 3:1 według kryterium 1.4.3, z jego warunkami i wyjątkami. Duży tekst oznacza co najmniej 18 punktów lub 14 punktów przy pogrubieniu. Oceń ceny, promocje, opisy pól i tekst przycisków, także w stanach interakcji.

Dla informacji wizualnej potrzebnej do rozpoznania kontrolek i ich stanów istotne jest kryterium 1.4.11. Nie oznacza ono, że każde dekoracyjne obramowanie musi mieć kontrast 3:1. Liczy się to, co jest potrzebne do identyfikacji elementu; szczegóły wyjaśnia dokumentacja kontrastu nietekstowego. Sprawdź osobno kontur pola, ikonę oraz wskaźnik fokusu.

Zmiana zawartości bez przeładowania strony może pozostać niezauważona przez osobę używającą czytnika. Nie zakładaj jednak, że każda instalacja WooCommerce ma ten błąd. Zbadaj konkretny motyw, dodatki i wariant koszyka: dodanie produktu, przeliczenie ilości, kupon oraz brak zapasu.

Komunikat statusu powinien być możliwy do ogłoszenia bez zabierania fokusu. Typowym rozwiązaniem jest role=status lub odpowiedni region aria-live. Wyjaśnienie kryterium 4.1.3 rozróżnia statusy od innych zmian interfejsu. Nie każda aktualizacja DOM wymaga kolejnego komunikatu.

Posłuchaj, czy ogłoszenie ma kontekst. Sama liczba bez informacji, że chodzi o koszyk, może być niezrozumiała. Z drugiej strony czytanie całego podsumowania po każdej drobnej zmianie utrudnia pracę. Warto sprawdzić tempo i powtarzalność informacji w rzeczywistym scenariuszu.

Zmiana ceny po wybraniu wariantu nie jest automatycznie niedozwoloną zmianą kontekstu. Trzeba ocenić, czy wybór nie przenosi niespodziewanie użytkownika i czy nazwa, rola, wartość oraz stan kontrolki pozostają dostępne. Dotyczy to również wyboru ilości i gwiazdek w recenzjach klientów, które często są własnymi komponentami.

Otwórz kluczowe ekrany przy powiększeniu i w wąskim widoku. Sprawdź, czy treść oraz kontrolki nie znikają, a przewijanie pozwala dotrzeć do każdego kroku. Odbiór powinien obejmować również długą nazwę produktu, komunikat błędu i rozwiniętą listę dostawy. Prosty pusty formularz może nie ujawnić problemu układu.

W WCAG 2.2 poziom AA obejmuje między innymi kryterium 2.4.11: aktywny element nie może być całkowicie zasłonięty przez treść stworzoną przez autora. Sprawdź więc pasek cookies, stałe menu i komunikat promocyjny podczas przechodzenia przez checkout.

Kryterium 2.5.8 dotyczy wielkości celów wskaźnika: zasadniczo 24 na 24 piksele CSS, z określonymi wyjątkami, w tym dotyczącymi odstępów. Nie traktuj tej liczby jako nakazu powiększenia każdego linku w akapicie. Dokumentacja rozmiaru celu pozwala dobrać właściwy test dla ikon, przycisków i drobnych kontrolek ilości.

Przy logowaniu sprawdź możliwość użycia menedżera haseł i wklejania danych. Nowe kryterium 3.3.8 ogranicza bariery związane z wymaganiem testu funkcji poznawczych podczas uwierzytelniania, przy przewidzianych sposobach spełnienia i wyjątkach. Szczegóły opisuje dostępne uwierzytelnianie WAI. Sam komunikat, że hasło jest silne, nie sprawdza dostępności logowania.

Etykieta accessibility-ready jest punktem wyjścia do oceny motywu. Nie potwierdza dostępności dodanych produktów, formularzy i integracji. Także builder nie przesądza sam o wyniku. Sprawdź komponenty, z których rzeczywiście korzysta sklep, oraz ich zachowanie po konfiguracji.

Przy wyborze motywu WordPress uwzględnij możliwość poprawiania szablonów i aktualizacji nadpisań. Poprawka wykonana bezpośrednio w pliku dostawcy może zniknąć przy aktualizacji. Potrzebna jest trwała metoda wdrożenia oraz ponowny test po zmianie.

Tabela pomaga zorganizować próbę, lecz nie jest pełną listą wymagań. W raporcie zapisz przeglądarkę, czytnik, wersje elementów sklepu i stan danych. Dzięki temu można rozpoznać, czy poprawkę rzeczywiście sprawdzono w tym samym scenariuszu.

Zacznij od przeglądu klawiaturą i wybranego czytnika ekranu, na przykład NVDA lub VoiceOver. Dołóż narzędzie automatyczne, które pomoże znaleźć część problemów w kodzie. Wynik automatu nie rozstrzyga sensu opisu obrazu, logiczności procesu ani tego, czy klient potrafi poprawić zamówienie.

Pełną finalizację sprawdzaj w środowisku testowym z płatnością sandbox i wyłączonymi rzeczywistymi wysyłkami wiadomości. Nie wprowadzaj sztucznych konwersji do produkcyjnej analityki. Przy zewnętrznej bramce ustal z dostawcą sposób przetestowania także odmowy, anulowania i powrotu do sklepu.

Każdej poprawce przypisz kryterium odbioru oraz osobę odpowiedzialną za retest. Otwarty wcześniej problem nie znika tylko dlatego, że zmieniono wtyczkę. Nakładka dostępności również nie jest samodzielnym dowodem zgodności całego sklepu.

Jeżeli potrzebujesz zaplanować zakres badania i napraw, sprawdź usługę dostępności WCAG oraz wdrożenia sklepów internetowych. W kontakcie z KC Mobile wskaż motyw, typ checkoutu i integracje uczestniczące w zakupie. To pozwoli ustalić konkretną ścieżkę do sprawdzenia, zamiast ograniczać rozmowę do wyniku jednego skanera.