Audyt WCAG WordPress: praktyczna kontrola dostępności strony krok po kroku

Audyt WCAG WordPress obejmuje szablony, bloki, nawigację, formularze, multimedia, treści i komponenty dostarczane przez wtyczki. WCAG to wytyczne dostępności treści internetowych, które określają kryteria oceny między innymi percepcji, obsługi i zrozumiałości serwisu.

Skan przesiewowy wykrywa część problemów możliwych do rozpoznania w kodzie, na przykład brak nazwy przycisku. Pełny audyt sprawdza również kontekst: czy link prowadzi tam, gdzie zapowiada, czy błąd formularza jest zrozumiały i czy użytkownik może ukończyć zadanie bez myszy. Oficjalna pomoc WAVE wskazuje, że brak wykrytych błędów nie potwierdza dostępności strony; sprawdziliśmy ją w październiku 2026.

Zakres zapisujemy jako listę widoków oraz funkcji. W serwisie WordPress uwzględniamy:

• stronę główną, kategorię i pojedynczy wpis lub produkt;
• menu desktopowe i mobilne w stanie zamkniętym oraz otwartym;
• formularz przed wysłaniem, po błędzie walidacji i po potwierdzeniu;
• popup zgód, wyszukiwarkę, galerię i elementy dynamiczne;
• bloki treści oraz widoki dostępne po zalogowaniu.

Jeśli planujesz kontrolę dostępności, zakres i sposób zamówienia opisuje poradnik o audycie WCAG.

Do audytu przygotuj adresy reprezentatywnych widoków, dostęp do stref wymagających logowania oraz listę zadań użytkownika. Sama strona główna nie wystarczy, jeśli formularz, sklep i panel klienta korzystają z innych szablonów albo wtyczek.

Dla każdego widoku zapisz stan początkowy, czynność użytkownika i oczekiwany rezultat. Formularz sprawdź po poprawnym wypełnieniu, z pustym polem wymaganym, błędnym adresem e-mail i komunikatem błędu zwróconym przez serwer. Menu mobilne sprawdź przed otwarciem, po otwarciu, podczas nawigacji klawiaturą oraz po zamknięciu.

Przed kontrolą zbierz adresy stron, role użytkowników, dane testowe bez danych osobowych, listę wtyczek obsługujących interakcje oraz informację, czy testujesz kopię czy stronę produkcyjną. Zapisz również wersję motywu i wtyczek. Taki zapis pozwala odtworzyć stan, gdy aktualizacja zmieni działanie komponentu.

Skan automatyczny uruchom osobno dla każdego reprezentatywnego widoku i stanu, ponieważ narzędzie analizuje aktualnie wyrenderowaną stronę. axe DevTools sprawdza reguły dostępności w przeglądarce, WAVE pokazuje błędy i ostrzeżenia na stronie, a Lighthouse generuje raport audytów dostępności w Chrome DevTools.

W Chrome otwórz DevTools, wybierz Lighthouse, zaznacz kategorię Accessibility i wygeneruj raport. WAVE uruchom rozszerzeniem przeglądarki dla stron dynamicznych lub chronionych logowaniem. W axe DevTools otwórz panel rozszerzenia, uruchom skan i zapisz nazwę reguły, wskazany element oraz dowód. Opisy tych funkcji znajdują się w dokumentacji producentów axe, WAVE i Chrome sprawdzonej w październiku 2026.

Narzędzia automatyczne szybko ujawniają powtarzalne problemy, ale ich wynik wymaga oceny człowieka.

W raporcie zapisz narzędzie, datę, adres, stan strony, regułę oraz decyzję po weryfikacji. Oddziel potwierdzony błąd od ostrzeżenia wymagającego oceny, ponieważ część wskazań może dotyczyć ukrytego komponentu albo nietypowego stanu.

Test klawiaturą sprawdza, czy użytkownik może przejść przez kontrolki i wykonać zadanie bez myszy. Odśwież stronę, nie używaj myszy i przechodź przez interfejs klawiszami Tab, Shift+Tab, Enter, Spacja oraz strzałkami odpowiednimi dla danego komponentu.

Sprawdź, czy fokus jest widoczny, porusza się w logicznej kolejności, nie znika za popupem i wraca do elementu, który otworzył okno. Otwórz menu, przejdź po pozycjach, uruchom wyszukiwarkę i wywołaj błąd formularza. WCAG 2.2 zawiera kryterium Focus Not Obscured, które dotyczy zasłonięcia elementu z fokusem przez treść utworzoną przez autora.

Test NVDA wykonaj w przeglądarce, na przykład Firefox. W trybie przeglądania klawisz H przechodzi po nagłówkach, F po polach formularza, a B po przyciskach. Sprawdź, czy czytnik odczytuje etykietę pola, jego wymagany stan i komunikat błędu; NVDA+Spacja przełącza tryb przeglądania i tryb fokusu. Skróty opisuje przewodnik użytkownika NVDA sprawdzony w październiku 2026.

Z naszych wdrożeń wynika, że formularz i menu wymagają sprawdzenia także po interakcji. Dowód powinien więc pokazywać otwarty popup, aktywną walidację lub stan po wysłaniu formularza, a nie tylko ekran początkowy.

Kontrast zwykłego tekstu według kryterium WCAG 1.4.3 powinien wynosić co najmniej 4,5:1, a tekstu dużego co najmniej 3:1. Wymagania dla elementów interfejsu, takich jak obramowanie pola lub ikona stanu, sprawdzamy osobno według kryteriów kontrastu nietekstowego.

Zmierz kolory względem rzeczywistego tła, także w przyciskach, linkach, placeholderach i komunikatach błędu. Nie przekazuj informacji wyłącznie kolorem: pole błędne powinno otrzymać tekstowy komunikat powiązany z kontrolką. Kryterium WCAG 2.2 Understanding Contrast Minimum opisuje te progi i zostało sprawdzone w październiku 2026.

Nagłówki powinny odzwierciedlać hierarchię treści, a nie tylko wygląd. W edytorze blokowym ustaw poziom bloku Nagłówek zgodnie ze strukturą strony. Tekst alternatywny opisuje rolę grafiki w danym kontekście: zdjęcie produktu identyfikuje produkt, a grafika dekoracyjna może mieć pusty tekst alternatywny.

Nazwy linków i przycisków powinny wskazywać cel działania. Zamiast kilku linków "więcej" użyj nazw opisujących ich cele. Widoczne etykiety pól oraz konkretne instrukcje błędu pomagają użytkownikowi poprawić formularz.

Miejsce naprawy zależy od źródła problemu: treści, ustawień, motywu, wtyczki albo własnego kodu. Najpierw zapisz komponent i widok, w którym błąd występuje, a dopiero potem zmieniaj konfigurację.

Wskazane miejsce jest pierwszym tropem diagnozy, a nie pewnym wskazaniem autora błędu.

Dokumentacja WooCommerce opisuje wsparcie nawigacji klawiaturą i komunikatów formularzy, ale motyw lub rozszerzenia mogą zmieniać ich zachowanie. Po aktualizacji komponentu ponów test na widokach, które z niego korzystają.

Najpierw napraw błędy blokujące wykonanie zadania, takie jak wysłanie formularza, nawigacja menu lub przejście do płatności. Priorytet ustal według wpływu na użytkownika, zasięgu problemu, dostępności obejścia i nakładu wdrożenia.

Priorytet wynika z wpływu na zadanie i zasięgu problemu, a nie z samego wyniku narzędzia.

Zapisz oddzielnie wpływ i przewidywany koszt. Nie obniżaj priorytetu tylko dlatego, że błąd dotyczy jednej strony, jeśli blokuje ona główną ścieżkę kontaktu albo zakupu.

Poprawę potwierdza ponowny test tego samego widoku, stanu, urządzenia i scenariusza, w którym wykryto błąd. Zachowaj dowód przed i po zmianie oraz wersję motywu lub wtyczki objętej wdrożeniem.

Przykładowy wpis do macierzy audytu może wyglądać tak.

W tym przykładzie status opisuje problem wymagający poprawki, a dowód pozwala drugiej osobie odtworzyć test.

Po naprawie powtórz skan automatyczny i test ręczny związany z problemem. Przy poprawce fokusu przejdź menu klawiaturą, a przy poprawce etykiety sprawdź odczyt pola i walidację w NVDA. Sprawdź również inne widoki korzystające z tego samego komponentu.

Zalecamy ponowną kontrolę po aktualizacji motywu, wtyczki formularza, popupu albo bloku WooCommerce. Jeśli potrzebujesz oceny SEO i użyteczności, zakres audytu cyfrowego KC Mobile obejmuje analizę tych obszarów.

• Jak przygotować stronę internetową pod dostępność cyfrową WCAG
• Audyt strony mobilnej: lista kontroli UX, szybkości i konwersji
• WCAG accessibility in UX/UI: jak przełożyć zasady na interfejs
• Dlaczego audyt strony mobilnej nie działa? Jak znaleźć przyczynę i ją sprawdzić