WordPress a WCAG: jak sprawdzić motyw, wtyczki i treści, żeby strona była dostępna

Sam WordPress nie jest ani dostępny, ani niedostępny. Rdzeń systemu i panel administracyjny są rozwijane z myślą o dostępności, a edytor bloków pozwala dodawać teksty alternatywne i poprawne nagłówki. To, czy gotowa strona spełni WCAG, zależy od trzech rzeczy, na które wpływa właściciel: motywu, wtyczek i sposobu, w jaki redakcja dodaje treści. Każda z nich potrafi zepsuć zgodność, nawet jeśli dwie pozostałe są w porządku.

Motyw: fundament, którego nie naprawi wtyczka

• Struktura nagłówków: logo nie jest nagłówkiem H1 na każdej podstronie, a tytuł wpisu jest.
• Nawigacja klawiaturą: menu rozwijane otwiera się z klawiatury, a fokus jest widoczny na każdym linku.
• Link „przejdź do treści”: pierwszy element strony, pozwalający pominąć menu.
• Kontrast i rozmiar tekstu: kolory motywu spełniają wymagania, opisane w tekście o kontraście WCAG.
• Dopasowanie do telefonu: treść mieści się przy szerokości 320 pikseli bez przewijania w bok.

W katalogu WordPressa motywy, które przeszły podstawowy przegląd dostępności, mają oznaczenie „accessibility-ready”. To dobry punkt wyjścia, ale nie gwarancja: przegląd obejmuje motyw w wersji domyślnej, a nie po zmianach kolorów, układu i wtyczek konstruktorów stron.

Wtyczki, które najczęściej psują dostępność

Nakładki „dostępności”: dlaczego nie wystarczą

Wtyczki dodające przycisk z ikoną wózka, który powiększa tekst albo zmienia kolory, kuszą obietnicą zgodności jednym kliknięciem. Nie naprawiają jednak przyczyn: brakujących etykiet pól, złej kolejności fokusa, obrazów bez opisów czy menu, którego nie da się otworzyć klawiaturą. Osoby korzystające z czytników ekranu mają zwykle własne ustawienia, a nakładka potrafi z nimi kolidować. Nakładka może być dodatkiem, ale nie zastępuje poprawionej strony.

Treści: tu dostępność wygrywa albo przegrywa codziennie

• Tekst alternatywny: opisuje to, co obraz przekazuje, a nie nazwę pliku. Obraz dekoracyjny dostaje pusty opis.
• Nagłówki według struktury, a nie wyglądu: H2 dla sekcji, H3 dla podsekcji, bez pomijania poziomów dla efektu wizualnego.
• Linki opisujące cel: „pobierz cennik (PDF)” zamiast „kliknij tutaj”.
• Filmy z napisami: także wtedy, gdy film osadzony jest z serwisu zewnętrznego.
• Dokumenty do pobrania: PDF-y też podlegają WCAG, opisuję je w tekście o dostępnych PDF-ach.

Najskuteczniejsza praktyka to krótka instrukcja dla osób dodających treści i blokady w edytorze: np. ostrzeżenie przy próbie publikacji obrazu bez tekstu alternatywnego. Bez tego strona przechodzi audyt w dniu wdrożenia, a po pół roku znów ma te same błędy.

WordPress, WooCommerce i europejski akt o dostępności

Sklep na WooCommerce, który podlega europejskiemu aktowi o dostępności, musi mieć dostępny cały proces zakupu: listę produktów, kartę produktu, koszyk, checkout i konto klienta. To właśnie checkout najczęściej ma problemy, bo składa się z pól dodawanych przez różne wtyczki płatności i dostawy. Zakres obowiązków opisuję w tekście o europejskim akcie o dostępności, a podstawy w tekście WCAG co to jest.

Źródła: Podręcznik dostępności WordPress i WCAG 2.2, rekomendacja W3C.