WCAG w WordPressie i WooCommerce: motyw, wtyczki i workflow poprawek

Dostępność WordPressa i WooCommerce rzadko rozbija się o sam system. O tym, czy serwis spełnia wytyczne WCAG, decydują przede wszystkim motyw, page builder, wtyczki i treści dodawane przez redakcję, czyli elementy, które wybierasz i konfigurujesz Ty albo Twój wykonawca.

Pokazujemy, gdzie w serwisie i sklepie na WordPressie zwykle powstają bariery, jak je znaleźć i jak poprawiać je tak, żeby nie wracały po aktualizacji.

WCAG w WordPressie i WooCommerce: skąd biorą się błędy

Rdzeń WordPressa jest rozwijany z uwzględnieniem dostępności, a edytor blokowy generuje zwykle prosty, semantyczny kod: prawdziwe nagłówki, listy i obrazy z polem na tekst alternatywny. Problemy pojawiają się w kolejnych warstwach.

Wybór motywu i tag accessibility-ready

W katalogu motywów WordPress.org możesz filtrować motywy tagiem accessibility-ready. Dostają go motywy, które przeszły dodatkowy przegląd podstawowych wymagań dostępności, m.in. obsługi klawiatury, widocznego fokusu, linku „przejdź do treści”, kontrastu i struktury nagłówków.

Zanim kupisz lub zainstalujesz motyw, przejdź jego demo według tej listy:

• Po pierwszym naciśnięciu klawisza Tab pojawia się link „Przejdź do treści”.
• Fokus jest wyraźnie widoczny na każdym linku i przycisku (2.4.7 Focus Visible – widoczny fokus).
• Podmenu otwiera się z klawiatury, nie tylko po najechaniu myszą.
• Przycisk menu mobilnego ma nazwę i informuje, czy menu jest rozwinięte.
• Przy powiększeniu 200% i szerokości 320 px CSS nic się nie ucina ani nie nakłada (1.4.4 Resize Text – powiększanie tekstu, 1.4.10 Reflow – dopasowanie treści).
• Tekst, linki i przyciski mają wystarczający kontrast kolorów, także po zmianie palety na firmową.

Page buildery: wygoda, która ma swoją cenę

Page builder pozwala zbudować stronę bez programisty, ale łatwo nim stworzyć kod, który wygląda dobrze, a działa źle. Typowe problemy:

• Nagłówki dobierane pod wygląd. H2 wybrany, bo „ma ładny rozmiar”, psuje strukturę dokumentu (1.3.1 Info and Relationships – informacje i relacje). Poziom ustawiaj według hierarchii, a rozmiar zmieniaj stylem.
• Klikalne kontenery. Kafelek zrobiony z elementu div z obsługą kliknięcia nie jest osiągalny klawiszem Tab (2.1.1 Keyboard – obsługa z klawiatury) i nie ma roli (4.1.2 Name, Role, Value – nazwa, rola, wartość).
• Zakładki, akordeony i karuzele bez obsługi klawiatury i bez informacji, czy sekcja jest rozwinięta.
• Ikony zamiast tekstu, np. linki do mediów społecznościowych bez nazwy. Czytnik ekranu przeczyta wtedy samo „link” albo adres URL zamiast nazwy serwisu.

Każdy typ widżetu sprawdź raz na stagingu, zanim użyjesz go w całym serwisie, i ogranicz liczbę ich rodzajów.

Wtyczki: formularze, slidery, popupy i cookies

Formularze

Sprawdź, czy wtyczka tworzy widoczne etykiety powiązane z polami (3.3.2 Labels or Instructions – etykiety lub instrukcje), a błędy pokazuje tekstem przy polu i ogłasza czytnikowi ekranu (3.3.1 Error Identification – wskazanie błędu). Jeśli chroni formularz zagadką CAPTCHA, poszukaj zabezpieczenia, które nie wymaga działania od użytkownika.

Slidery i karuzele

Automatycznie przewijana karuzela potrzebuje sposobu na zatrzymanie, np. przycisku pauzy (2.2.2 Pause, Stop, Hide – wstrzymanie, zatrzymanie, ukrycie). Strzałki potrzebują nazw, a slajdy poza ekranem nie powinny przejmować fokusu. Często najlepszym rozwiązaniem jest statyczny baner z jednym komunikatem.

Popupy

Okno z newsletterem czy rabatem powinno po otwarciu przejąć fokus, trzymać go w środku, zamykać się klawiszem Esc i oddawać fokus tam, gdzie był wcześniej. Najprościej oprzeć je na natywnym elemencie dialog otwieranym metodą showModal(), który blokuje resztę strony i obsługuje Esc:

<dialog aria-labelledby="popup-tytul">
  <h2 id="popup-tytul">Zapisz się do newslettera</h2>
  <!-- treść i formularz -->
  <form method="dialog">
    <button>Zamknij</button>
  </form>
</dialog>

Cały wzorzec opisuje W3C w ARIA Authoring Practices Guide.

Baner cookies

Wtyczka zgód powinna działać z klawiatury i przy powiększeniu 400% oraz nie zasłaniać elementu z fokusem. Szczegóły opisujemy w artykule o dostępności sklepu internetowego.

Bloki koszyka i zamówienia w WooCommerce

WooCommerce pozwala zbudować koszyk i zamówienie na dwa sposoby: klasycznymi shortcode’ami ([woocommerce_cart], [woocommerce_checkout]) albo blokami koszyka i zamówienia (Cart i Checkout). Bloki są aktywnie rozwijane, ale nie zwalniają z testów. Najwięcej problemów wnoszą rozszerzenia, które dokładają do zamówienia własne elementy:

• wybór punktu odbioru tylko na mapie, bez wyszukiwarki i listy obsługiwanej klawiaturą,
• dodatkowe pola (NIP, uwagi, zgody) bez etykiet albo z błędami, których czytnik ekranu nie ogłasza,
• pola płatności osadzone w ramce iframe bez tytułu i nazw pól,
• zmiana metody dostawy, która przelicza sumę bez komunikatu o nowej kwocie (4.1.3 Status Messages – komunikaty o stanie).

Niezależnie od wybranej drogi przetestuj cały proces z włączonymi wtyczkami dostaw i płatności: klawiaturą, z powiększeniem i czytnikiem ekranu.

Typowe problemy w sklepach na WooCommerce

Swatche najłatwiej naprawić, wracając do natywnych pól radio. Dają obsługę strzałkami, rolę i stan zaznaczenia bez ani jednej linijki ARIA, a widoczna nazwa pomaga osobom, które słabo rozróżniają kolory:

<fieldset>
  <legend>Kolor</legend>
  <input type="radio" id="kolor-granatowy" name="kolor" value="granatowy">
  <label for="kolor-granatowy">Granatowy</label>
  <input type="radio" id="kolor-bordowy" name="kolor" value="bordowy">
  <label for="kolor-bordowy">Bordowy</label>
</fieldset>

Próbkę koloru dodaj stylem przy etykiecie. Jeśli ukrywasz samo kółko pola radio, zadbaj o widoczny fokus na etykiecie.

Dlaczego nakładki (overlaye) nie rozwiązują problemu

Wtyczki „jednego skryptu” dodają panel z przyciskami kontrastu czy powiększenia i bywają reklamowane jako szybka droga do zgodności z WCAG. Nie działają jednak tak, jak obiecują:

• Nakładka nie naprawia kodu. Pole bez etykiety, klikalny div czy pułapka klawiatury w koszyku zostają na miejscu.
• Dubluje funkcje, które użytkownik już ma. Osoby słabowidzące korzystają z powiększenia w przeglądarce i systemie, a niewidome z własnego czytnika ekranu.
• Może kolidować z technologiami asystującymi, np. zmieniając atrybuty elementów w sposób, który wprowadza czytnik ekranu w błąd.
• Nie zapewnia zgodności z WCAG. Liczy się to, jak działa strona, a nie to, czy ma panel z przyciskami.

Budżet na nakładkę lepiej wydać na poprawki w motywie i szablonach, które zostają w kodzie. O granicach automatyzacji piszemy w porównaniu automatycznego testu WCAG i audytu manualnego.

Workflow poprawek: staging, motyw potomny, retest

1. Staging. Pracuj na kopii serwisu z tymi samymi wersjami motywu i wtyczek, a nie na działającym sklepie.
2. Test. Przeskanuj główne szablony testem automatycznym, a potem przejdź kluczowe ścieżki klawiaturą, z powiększeniem i czytnikiem ekranu, tak jak w instrukcji jak sprawdzić stronę pod kątem WCAG. Zapisz wyniki jako punkt odniesienia.
3. Poprawki w motywie potomnym. Style, funkcje i nadpisane szablony WooCommerce trzymaj w motywie potomnym, żeby aktualizacja motywu nadrzędnego ich nie skasowała:

   wp-content/themes/moj-motyw-child/
   ├── style.css        ← style, np. fokus
   ├── functions.php    ← funkcje, np. autocomplete
   └── woocommerce/
       └── global/
           └── quantity-input.php  ← szablon pola ilości

   Wyraźny fokus często załatwia kilka linijek CSS:

   :focus-visible {
     outline: 3px solid #1a4fa0;
     outline-offset: 2px;
   }

4. Retest po aktualizacjach. Po aktualizacji WordPressa, WooCommerce, motywu lub wtyczek powtórz test kluczowych ścieżek. W panelu WooCommerce → Status sprawdź, czy nadpisane szablony nie są oznaczone jako nieaktualne.
5. Utrzymanie. Dopisz dostępność do kryteriów wyboru nowych wtyczek i przeszkol redakcję z nagłówków oraz tekstów alternatywnych.

Szybki, orientacyjny sygnał przed aktualizacją i po niej da Ci bezpłatny skan wstępny. Sprawdza on jednak tylko podstawowe elementy jednej strony, więc nie zastąpi przejścia ścieżki zakupowej klawiaturą.

Najczęstsze pytania

Czy muszę zmieniać motyw, jeśli ma problemy z dostępnością?

Nie zawsze. Pojedyncze problemy, takie jak niewidoczny fokus, niski kontrast czy brak etykiet, zwykle poprawisz w motywie potomnym. Zmiana motywu ma sens, gdy błędy tkwią w fundamentach: nawigacji, strukturze szablonów i komponentach, których nie da się rozsądnie nadpisać.

Czy są wtyczki, które realnie pomagają w dostępności?

Tak, ale to narzędzia wspierające pracę zespołu, a nie „naprawiacze” całej strony, np. wtyczki przypominające o brakującym tekście alternatywnym. Każdą i tak sprawdź testem, bo rozwiązują pojedyncze problemy, a nie dostępność serwisu jako całości.

Jak sprawdzić wtyczkę pod kątem dostępności przed wdrożeniem?

Zainstaluj ją najpierw na stagingu i przejdź jej elementy klawiaturą: sprawdź widoczność fokusu, etykiety, komunikaty i działanie przy powiększeniu. Warto też zapytać autora o znane problemy z dostępnością i o to, czy wtyczka była testowana z czytnikiem ekranu.

Czy edytor blokowy wystarczy, żeby treści były dostępne?

Edytor pomaga, bo generuje semantyczne nagłówki, listy i obrazy z polem na tekst alternatywny. O efekcie decyduje jednak redakcja: logiczna kolejność nagłówków, sensowne opisy obrazów, opisowe linki i napisy do filmów.