WCAG w sklepie internetowym: jak zadbać o dostępną ścieżkę zakupową

Dostępność sklepu internetowego najłatwiej ocenić tam, gdzie klient wydaje pieniądze: na ścieżce od wyszukiwarki do potwierdzenia zamówienia. Jeśli osoba korzystająca z klawiatury, czytnika ekranu lub powiększenia utknie na filtrze, wyborze rozmiaru albo formularzu adresu, zakup po prostu się nie odbędzie.

Poniżej znajdziesz typowe bariery na kolejnych etapach zakupów, powiązane kryteria WCAG, sposoby naprawy i checklistę, którą przekażesz zespołowi lub wykonawcy.

Ścieżka zakupowa: mapa typowych barier

Sklep składa się z kilku powtarzalnych szablonów, więc jedna poprawka w karcie produktu działa na wszystkich produktach naraz. Tabela pokazuje przykładowe bariery na każdym etapie zakupów.

Wyszukiwarka, filtry i lista produktów

• Wyszukiwarka potrzebuje etykiety (może być wizualnie ukryta) i przycisku z nazwą, np. „Szukaj”, nawet jeśli widać na nim tylko ikonę lupy. Podpowiedzi powinny działać z klawiatury, zwykle strzałkami.
• Filtry grupuj w fieldset z opisem w legend, np. „Rozmiar”. Jeśli zaznaczenie pola przeładowuje stronę, uprzedź o tym albo dodaj przycisk „Pokaż wyniki”. Po odświeżeniu listy ogłoś liczbę wyników (4.1.3 Status Messages – komunikaty o stanie).
• Suwak ceny uzupełnij polami „od” i „do”. Kryterium 2.5.7 Dragging Movements – alternatywa dla przeciągania wymaga, by funkcję dało się obsłużyć bez przeciągania.
• Kafelek produktu ma nazwę w linku i zdjęcie z sensownym tekstem alternatywnym. Jeśli zdjęcie i nazwa są w jednym linku, alt może być pusty, żeby czytnik nie powtarzał nazwy.
• Przyciski „Dodaj do koszyka” rozróżnij dla czytnika ekranu, np. ukrytym tekstem z nazwą produktu.
• Cenę przed obniżką opisz tekstem, bo wiele czytników ekranu domyślnie nie informuje o przekreśleniu.

Karta produktu i warianty

Karta produktu to najbardziej interaktywny szablon sklepu: galeria, warianty, ilość, stan magazynowy, zakładki z opisem i opiniami.

• Warianty kolorów potrzebują nazw tekstowych, np. „Granatowy”. Zaznaczony wariant oznacz nie tylko kolorem, a obramowanie wyboru powinno mieć kontrast co najmniej 3:1 (1.4.11 Non-text Contrast – kontrast elementów nietekstowych).
• Stan magazynowy opisz słowami, a nie samą zieloną lub czerwoną kropką (1.4.1 Use of Color – kolor nie może być jedynym nośnikiem informacji).
• Tabele rozmiarów publikuj jako tabele HTML, a nie jako obrazek.
• Powiększenie zdjęcia po najechaniu musi dać się zamknąć, np. klawiszem Esc, i nie może znikać, gdy przesuwasz nad nie kursor (1.4.13 Content on Hover or Focus – treść wyświetlana po najechaniu lub fokusie).

Po kliknięciu „Dodaj do koszyka” osoba korzystająca z czytnika ekranu musi usłyszeć potwierdzenie, inaczej może kliknąć jeszcze raz. Wystarczy pusty kontener z rolą status, obecny w kodzie od początku, do którego skrypt wstawia tekst:

<div role="status" class="cart-notice">Dodano do koszyka: Kurtka zimowa, rozmiar M</div>

Koszyk, checkout i płatności

Koszyk

Pole ilości potrzebuje etykiety, a przyciski „+” i „−” nazw, np. „Zwiększ ilość”. Każdy z nich powinien mieć co najmniej 24 × 24 piksele CSS albo odpowiedni odstęp od sąsiednich. Zmianę ilości, usunięcie produktu i wynik wpisania kodu rabatowego ogłaszaj tak samo jak dodanie do koszyka.

Formularz zamówienia

• Każde pole ma widoczną etykietę, bo placeholder znika przy wpisywaniu.
• Pola adresowe mają atrybuty autocomplete, dzięki którym przeglądarka podpowie dane (1.3.5 Identify Input Purpose – określenie celu pola).
• Adres dostawy można skopiować z adresu rozliczeniowego jednym polem wyboru (3.3.7 Redundant Entry – bez ponownego wpisywania danych).
• Przed złożeniem zamówienia klient widzi podsumowanie i może poprawić dane (3.3.4 Error Prevention (Legal, Financial, Data) – zapobieganie błędom w transakcjach).
• Punkt odbioru da się wybrać bez mapy: przez wyszukiwanie po adresie lub kodzie pocztowym i listę obsługiwaną klawiaturą.
• Jeśli obowiązuje limit czasu, klient dostaje ostrzeżenie i może go wydłużyć.

Logowanie i konto

Kryterium 3.3.8 w praktyce oznacza: nie blokuj wklejania haseł i kodów jednorazowych, nie utrudniaj pracy menedżerom haseł i nie każ rozwiązywać zagadek bez alternatywy. Pomagają też przycisk „Pokaż hasło” i możliwość zakupu bez zakładania konta.

Płatność u operatora

Bramka płatnicza nie jest Twoim kodem, ale dla klienta to wciąż Twój sklep. Przetestuj w trybie testowym operatora przekierowanie, wybór metody, komunikat o nieudanej płatności i powrót do sklepu. Bariery zgłoś operatorowi, a klientom zostaw alternatywną metodę płatności.

Potwierdzenia e-mail

Wiadomość z zamówieniem powinna przekazywać dane tekstem, a nie grafiką. Linki potrzebują opisowych nazw, np. „Sprawdź status zamówienia” zamiast „kliknij tutaj”.

Baner cookies: częsta pierwsza bariera

Baner zgód wyświetla się przed wszystkim innym. Jeśli jest niedostępny, klient nie dotrze nawet do oferty. Najczęstsze problemy:

• baner jest na końcu kodu, więc z klawiatury trudno do niego dotrzeć;
• przyciski mają zbyt niski kontrast kolorów (1.4.3 Contrast (Minimum) – kontrast minimalny wymaga 4,5:1 dla zwykłego tekstu);
• przełączniki kategorii zgód nie mają roli ani stanu, więc czytnik ekranu nie powie, czy zgoda jest włączona (4.1.2 Name, Role, Value – nazwa, rola, wartość);
• przy powiększeniu 400% baner zajmuje cały ekran, a do przycisków nie da się przewinąć (1.4.10 Reflow – dopasowanie treści do szerokości 320 px CSS);
• przyklejony pasek całkowicie zasłania element z fokusem (2.4.11 Focus Not Obscured (Minimum) – fokus nie może być zasłonięty).

Umieść baner na początku kodu, a jeśli blokuje stronę, potraktuj go jak okno dialogowe i przenieś na niego fokus. Użyj prawdziwych przycisków i pól wyboru. Gotowy moduł zgód testuj jak każdy inny element sklepu.

Komunikaty błędów i CAPTCHA

Dobry komunikat błędu mówi tekstem, które pole jest źle wypełnione i jak je poprawić (3.3.1 Error Identification oraz 3.3.3 Error Suggestion – podpowiedź korekty). Powiąż go z polem, żeby czytnik ekranu odczytał go razem z etykietą:

<label for="kod">Kod pocztowy</label>
<input id="kod" name="kod" autocomplete="postal-code"
       aria-invalid="true" aria-describedby="kod-blad">
<p id="kod-blad">Wpisz kod w formacie 00-000.</p>

Przy dłuższym formularzu dodaj nad nim podsumowanie błędów z linkami do pól i przenieś na nie fokus po wysłaniu.

CAPTCHA często blokuje osoby niewidome, słabowidzące i z niepełnosprawnościami poznawczymi. Kryterium 1.1.1 wymaga dla niej opisu celu i alternatywnych form dla różnych zmysłów, a 3.3.8 ogranicza zagadki przy logowaniu. Lepiej chronić formularze bez angażowania klienta: polem-pułapką ukrytym także przed czytnikami ekranu, limitem prób i weryfikacją po stronie serwera. Problem szerzej opisuje dokument W3C Inaccessibility of CAPTCHA.

Checklista WCAG dla sklepu internetowego

• Całą ścieżkę od wyszukiwarki do złożenia zamówienia przejdziesz samą klawiaturą, a fokus jest zawsze widoczny.
• Wyszukiwarka, filtry i pola formularzy mają etykiety.
• Zmiana filtra nie przenosi nieoczekiwanie na górę strony, a liczba wyników jest ogłaszana.
• Warianty mają nazwy tekstowe, a wybór i niedostępność nie są sygnalizowane tylko kolorem.
• Zwykły tekst ma kontrast co najmniej 4,5:1, a obramowania pól i ikony 3:1.
• Dodanie do koszyka, zmiana ilości i kod rabatowy dają komunikat słyszalny w czytniku ekranu.
• Przyciski w koszyku mają nazwy i rozmiar co najmniej 24 × 24 piksele CSS lub odpowiedni odstęp.
• Pola adresowe mają atrybuty autocomplete, a adresu nie trzeba wpisywać dwa razy.
• Błędy są opisane tekstem przy polu, z podpowiedzią, jak je poprawić.
• Logowanie pozwala wkleić hasło i kod, bez zagadek do rozwiązania.
• Punkt odbioru wybierzesz bez przeciągania mapy.
• Baner cookies działa z klawiatury i przy powiększeniu 400%.
• Płatność u operatora i powrót do sklepu zostały przetestowane.

Pierwszy obraz sytuacji da Ci bezpłatny skan wstępny jednej strony, np. karty produktu. Etapy wymagające zalogowania lub pełnego koszyka sprawdź ręcznie według instrukcji jak sprawdzić stronę pod kątem WCAG, a jeśli sklep działa na WordPressie, przeczytaj też o dostępności WordPressa i WooCommerce.

Dostępność sklepu internetowego a Europejski Akt o Dostępności

Od 28 czerwca 2025 r. usługi handlu elektronicznego są objęte polską ustawą wdrażającą Europejski Akt o Dostępności. Mikroprzedsiębiorcy świadczący usługi są z tych wymagań wyłączeni. W praktyce celem jest WCAG 2.1 na poziomie AA, a lepiej od razu WCAG 2.2 AA. Sklep objęty przepisami podaje też w regulaminie lub równoważnym dokumencie informacje o tym, jak spełnia wymagania dostępności.

To skrót, a nie porada prawna. Szczegóły, wyjątki i plan działania znajdziesz w artykule o Europejskim Akcie o Dostępności.

Najczęstsze pytania

Czy sklep może mieć osobną, „dostępną” wersję dla osób z niepełnosprawnościami?

WCAG dopuszcza w wyjątkowych sytuacjach tzw. alternatywną wersję zgodną, ale utrzymanie dwóch równoległych wersji sklepu jest trudne i łatwo o rozbieżności w ofercie, cenach czy stanach magazynowych. Lepszym celem jest jeden sklep, z którego wygodnie korzystają wszyscy.

Czy dostępność sklepu wpływa na SEO?

Częściowo te same elementy pomagają obu stronom: poprawne nagłówki, opisowe linki, teksty alternatywne i przejrzysta struktura strony. Dostępność warto jednak robić z myślą o klientach, a korzyści w wyszukiwarce traktować jako efekt uboczny.

Jak często sprawdzać dostępność sklepu?

Po każdej większej zmianie: nowym motywie, wtyczce płatności lub dostaw, przebudowie karty produktu czy aktualizacji, która zmienia checkout. Dobrą praktyką jest też krótki test ścieżki zakupowej klawiaturą przed każdym wdrożeniem.

Kto w sklepie odpowiada za dostępność?

Za kod motywu i wtyczek zwykle odpowiada programista lub agencja, za opisy produktów i teksty alternatywne osoby dodające treści, a za wybór operatorów płatności i dostaw właściciel sklepu. Warto wyznaczyć jedną osobę, która koordynuje te obszary i pilnuje testów.