Audyt dostępności WordPress WCAG AA: co sprawdzić zanim przyjdzie kontrola

Od 28 czerwca 2025 roku dostępność cyfrowa przestała być tylko dobrą praktyką dla firm - stała się obowiązkiem prawnym wynikającym z Europejskiego Aktu o Dostępności (EAA), który Polska wdrożyła ustawą z 26 kwietnia 2024 roku. Jeśli prowadzisz sklep internetowy, aplikację mobilną lub serwis usługowy objęty tą regulacją, a Twoja strona WordPress nie przeszła jeszcze audytu dostępności WCAG AA, to masz problem - lub przynajmniej poważne ryzyko.

Piszę to z perspektywy kogoś, kto w ciągu ostatnich kilku miesięcy dostał kilkanaście zapytań od klientów właśnie w tym temacie. Część z nich dopiero dowiedziała się o EAA. Część miała przekonanie, ze ich WordPress jakoś spełnia wymogi, bo jest nowoczesny. Żaden z tych serwisów nie był gotowy bez żadnych poprawek. Oto co faktycznie trzeba sprawdzić.

Kogo dotyczy EAA i WCAG AA

Zanim zaczniesz audyt, ustal czy w ogóle jesteś objęty regulacją. Ustawa implementująca EAA dotyczy podmiotów prywatnych z sektorów: handel elektroniczny, bankowość detaliczna, transport pasażerski, telekomunikacja, audiowizualne usługi medialne i e-booki. Mikroprzedsiębiorcy (do 10 pracowników, do 2 mln EUR obrotu rocznego) są z tego wyłączeni.

Jeśli Twój sklep WooCommerce przekracza te progi albo obsługujesz któryś z wymienionych sektorów, obowiązuje Cię zgodność z WCAG 2.1 AA (lub 2.2, który jest aktualizacją standardu). Kary za brak zgodności mogą sięgać 100 000 EUR lub 4% rocznego obrotu - w zależności która kwota jest wyższa. Nie jestem prawnikiem ani doradcą prawnym, więc w kwestiach interpretacji przepisów polecam konsultację z kancelarią, ale sam standard techniczny WCAG to mój chleb powszedni.

Co to jest audyt dostępności WordPress WCAG i co obejmuje

Audyt dostępności to systematyczne sprawdzenie serwisu pod kątem czterech zasad WCAG: postrzegalności (czy treść jest dostępna dla różnych zmysłów), funkcjonalności (czy można obsługiwać stronę bez myszy), zrozumiałości (czy interfejs jest przewidywalny i jasny) i solidności (czy działa z technologiami wspomagającymi takimi jak czytniki ekranu).

W przypadku WordPress audyt obejmuje: motyw i jego szablony, bloki Gutenberga lub page builder (Elementor, Bricks itp.), wtyczki formularzy (Contact Form 7, Gravity Forms), WooCommerce jeśli jest, wszelkie pop-upy, slidery i mega-menu oraz kod JavaScript odpowiedzialny za interaktywność.

Checklista WCAG 2.2 AA dla WordPress: co sprawdzić punkt po punkcie

Poniżej zebrałem praktyczną checklisty opartą na najczęstszych błędach, jakie widzę na stronach WordPress klientów. To nie jest kompletna lista 78 kryteriów WCAG 2.2 - to 20 punktów, które odpowiadają za 80% problemów.

Kontrast kolorów: najczęstszy błąd na stronach firmowych

W praktyce kontrast to ten błąd, który widzę najczęściej. Designerzy często wybierają jasne szarości na białym tle albo tekst na kolorowych sekcjach hero - i to wygląda świetnie na mocnym monitorze w biurze, ale nie spełnia wymogów dla osób niedowidzących.

Zasada jest prosta: tekst normalny (do ok. 18px niepogrubiony) potrzebuje stosunku kontrastu co najmniej 4,5:1. Tekst duży i pogrubiony - co najmniej 3:1. Element interfejsu jak obramowanie inputa czy ikona też 3:1. Najlepiej sprawdzać narzędziem Chrome DevTools (zakładka Accessibility w inspekcji elementu) lub wtyczką Colour Contrast Analyser.

Na jednym z projektów dla klienta z Poznania musieliśmy przejrzeć dosłownie każdą sekcję strony, bo designer użył koloru wiodącego (#E8A020, taki pomarańcz) zarówno jako tła jak i na białych przyciskach - kontrast wynosił zaledwie 2,8:1. Zmiana odcienia o 15% w kierunku ciemniejszego rozwiązała sprawę bez widocznej zmiany brandingu.

Nawigacja klawiaturą i fokus: problemy niewidoczne na pierwszy rzut oka

Zamknij mysz i spróbuj obsłużyć swoją stronę tylko klawiszem Tab. Menu działa? Możesz otworzyć i zamknąć modal? Możesz wypełnić formularz kontaktowy i go wysłać? Jeśli tak - to dobry znak. Jeśli fokus ginie gdzieś w menu albo zatrzymuje się na niewidocznym elemencie, masz problem.

Najczęstszą przyczyną jest CSS: outline: 0 lub outline: none dodane globalnie przez developera albo motyw, żeby pozbyć się domyślnej niebieskiej ramki. To jest błąd dostępności. Fokus można ostylować estetycznie - np. przez outline: 2px solid #0066cc z outline-offset: 2px - ale nie wolno go ukrywać.

Drugą pułapką są mega-menu i slide-in navbary budowane czystym CSS bez prawidłowych atrybutów ARIA. Czytnik ekranu nie wie, że jest podmenu, jeśli nie ma role="menu", aria-haspopup i aria-expanded.

Formularze i ARIA: gdzie WordPress najczęściej zawodzi

Contact Form 7 to najpopularniejsza wtyczka formularzy w WordPress i jedna z bardziej problematycznych pod kątem dostępności. Domyślnie generuje komunikaty błędów przez klasy CSS i treść span - ale bez poprawnych ról ARIA czytnik ekranu może tego nie odczytać. Lepszym wyborem jest Gravity Forms z włączonym trybem dostępności lub WPForms z prawidłowymi etykietami.

Checklista dla formularzy WordPress:

• każdy input ma label for="id_inputu" lub aria-label
• pola wymagane mają aria-required="true"
• komunikaty błędów mają role="alert" lub są powiązane przez aria-describedby
• placeholder nie zastępuje etykiety (po wpisaniu tekstu etykieta znika - błąd)
• checkboxy i radio buttons mają opisowe labels, nie tylko kody
• formularz daje się wysłać klawiszem Enter z dowolnego pola

WooCommerce checkout ma własne problemy - szczególnie w połączeniu z Germanized i niestandardowymi polami. Testowałem to na kilku projektach dla klientów DE i każdorazowo były poprawki w etykietach pól adresowych.

Darmowe vs płatne narzędzia do testowania WCAG

Do szybkiej weryfikacji przed zleceniem audytu: zainstaluj axe DevTools i uruchom na każdej kluczowej podstronie (strona główna, kontakt, produkty, checkout). Zrób zrzut wyników. To da Ci rozeznanie co do skali problemu i ułatwi rozmowę z audytorem.

Co daje profesjonalny audyt, czego nie zrobi automat

Narzędzia automatyczne to punkt wyjścia, nie koniec. Czego nie wykryją nigdy:

• czy tekst alternatywny obrazu faktycznie opisuje jego treść (można wpisać alt="obraz" i automat to przepuści)
• czy kolejność odczytu przez czytnik ekranu ma sens logiczny
• czy formularz zachowuje się poprawnie po błędzie walidacji
• czy animacje powodują problemy dla osób z epilepsją fotogenną
• czy instrukcje nie opierają się wyłącznie na kolorze (kliknij zielony przycisk)
• czy treść jest zrozumiała przy powiększeniu 400%
• czy interaktywne widżety (slider, accordion, tabs) działają z czytnikiem ekranu

Profesjonalny audyt dostępności WCAG w Polsce kosztuje od ok. 999 PLN netto dla prostego serwisu wizówkowego do 5000-12000 PLN netto dla rozbudowanego sklepu WooCommerce. Efektem jest raport z listą błędów podzielonych na krytyczne, ważne i drobne, z dokładnymi wskazaniami w kodzie i propozycjami naprawy. Taki raport to też dokumentacja na wypadek kontroli.

Jeśli prowadzisz stronę internetową firmy lub sklep i dopiero zaczynasz temat dostępności, dobrym pierwszym krokiem jest właśnie taki audyt - zanim zaczniesz wdrażać poprawki na oślep. Bez wiedzy co jest zepsute, możesz naprawić widoczne błędy i przeoczyć te, które mają największy wpływ na użytkowników z niepełnosprawnościami.

Jak wygląda audyt w praktyce: mój workflow

Kiedy biorę się za audyt dostępności strony WordPress dla klienta, zaczynam od skanu automatycznego trzema narzędziami: axe, Lighthouse i WAVE. Porównuję wyniki, bo każde z nich łapie trochę inne rzeczy. Potem przechodzę przez stronę klawiaturą na dużym monitorze i na małym ekranie. Na koniec odpalam NVDA (darmowy czytnik ekranu Windows) i słucham kluczowych podstron.

Najczęstsze błędy, które widzę niezależnie od projektu:
1. Brak lub nieprawidłowy alt na obrazach (szczególnie logo, banery promocyjne w WooCommerce)
2. Kontrast tekstu na kolorowych sekcjach hero i CTA
3. Brak widocznego fokusa na linkach w nawigacji
4. Formularze Contact Form 7 bez powiązania label-input
5. Linki "czytaj więcej" bez kontekstu (każdy brzmi tak samo dla czytnika ekranu)

Do powiązanych artykułów warto zajrzeć też do omówienia kosztów strony dla JDG gdzie piszę o tym co wchodzi w ceny projektów, oraz do analizy co daje freelancer vs agencja jeśli zastanawiasz się komu zlecić zarówno audyt jak i poprawki.

Kiedy zlecić profesjonalny audyt, a kiedy zrobić to samemu

Jeśli masz prosty serwis firmowy (5-10 podstron, jeden formularz kontaktowy, brak sklepu) - zainstaluj axe DevTools, przejdź przez stronę klawiaturą i popraw to co znajdziesz. Dobre motywy WordPress jak Blocksy czy GeneratePress mają już dostępność na przyzwoitym poziomie.

Jeśli masz sklep WooCommerce z dziesiątkami podstron, checkoutem, formularzami rejestracji i dynamicznym JavaScript - samodzielny audyt nie wystarczy do celów prawnych. Potrzebujesz raportu od kogoś, kto zna się na dostępności i może podpisać się pod dokumentacją. Ceny zaczynają się od ok. 1500-2000 PLN netto dla mniejszych serwisów.

Jeśli chcesz dowiedzieć się więcej o tym czym różnią się podejścia do budowania stron pod kątem prawnym i technicznym, zajrzyj też do artykułu o wpływie AI na strony firmowe w 2026 - tam też poruszam temat jak algorytmy interpretują dostępność w kontekcie indeksowania.

Zlecasz projekt lub chcesz omówić audyt dostępności swojej strony? Napisz przez formularz kontaktowy - sprawdzam serwis zanim wydam wycenę.