Dostępność (WCAG 2.2) w 2026: Czy twoja strona WordPress jest legalna?

Od 28 czerwca 2025 roku Europejski Akt o Dostępności (EAA), czyli dyrektywa (UE) 2019/882, realnie wpływa na obowiązki właścicieli sklepów, aplikacji i serwisów działających w UE. W Polsce wdraża go ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze.

Dla deweloperów WordPress i właścicieli stron praktycznym punktem odniesienia jest WCAG 2.2 na poziomie AA. Ten tekst pokazuje, które kryteria WCAG 2.2 najczęściej psują motywy WordPress, co dokładnie mówią dyrektywa i polska ustawa oraz jak testować stronę przed każdym wydaniem. Nie zastępuje porady prawnej dla twojego przypadku.

Oficjalne źródła: rekomendacja WCAG 2.2, tekst dyrektywy 2019/882, tekst polskiej ustawy i podręcznik dostępności WordPress.

#Kogo obejmuje Europejski Akt o Dostępności

Wcześniej przepisy o dostępności dotyczyły głównie sektora publicznego. EAA rozszerza wymagania na sektor prywatny, ale tylko na wymienione kategorie. Art. 2 ust. 2 dyrektywy wskazuje usługi świadczone konsumentom po 28 czerwca 2025 r.:

• usługi łączności elektronicznej;
• usługi zapewniające dostęp do audiowizualnych usług medialnych;
• elementy usług transportu pasażerskiego lotniczego, autobusowego, kolejowego i wodnego (strony, aplikacje mobilne, bilety elektroniczne, informacje o podróży);
• usługi bankowości detalicznej;
• książki elektroniczne i specjalne oprogramowanie do nich;
• usługi handlu elektronicznego.

Dyrektywa definiuje handel elektroniczny jako usługi świadczone na odległość przez strony internetowe i aplikacje mobilne, na indywidualne żądanie konsumenta, w celu zawarcia umowy konsumenckiej. Sklep WooCommerce sprzedający konsumentom w UE mieści się w tej definicji. Strona firmy doradczej obsługującej wyłącznie inne firmy, bez zawierania umów z konsumentami online, nie występuje na liście.

#Jakie wyjątki przewiduje dyrektywa

• Mikroprzedsiębiorstwa świadczące usługi (art. 4 ust. 5) są zwolnione z wymagań dostępności usług. Dyrektywa definiuje mikroprzedsiębiorstwo jako zatrudniające mniej niż 10 osób, z rocznym obrotem lub sumą bilansową nieprzekraczającą 2 mln euro. Zwolnienie nie obejmuje produktów.
• Zasadnicza zmiana i nieproporcjonalne obciążenie (art. 14): wymagania stosuje się tylko w zakresie, w jakim nie zmieniają zasadniczo charakteru usługi i nie nakładają nieproporcjonalnego obciążenia. Podmiot musi przeprowadzić taką ocenę, udokumentować ją i przechowywać wyniki przez pięć lat.
• Wyłączone treści (art. 2 ust. 4): m.in. nagrane wcześniej media i pliki biurowe opublikowane przed 28 czerwca 2025 r. oraz treści stron trzecich, których podmiot nie finansuje, nie tworzy i nie kontroluje.

#Terminy z dyrektywy

Dyrektywa nie podaje kwot kar. Art. 30 zobowiązuje państwa do sankcji skutecznych, proporcjonalnych i odstraszających, uwzględniających wagę naruszenia, liczbę niezgodnych produktów lub usług i liczbę poszkodowanych osób.

#Jak Polska wdrożyła EAA i jakie grożą kary

Polska ustawa z 26 kwietnia 2024 r. została ogłoszona w Dz.U. 2024 poz. 731 i co do zasady weszła w życie 28 czerwca 2025 r. Najważniejsze dla właściciela strony WordPress:

• Wyłączenia (art. 4): ustawy nie stosuje się m.in. do usług oferowanych lub świadczonych przez mikroprzedsiębiorców ani do treści, które nie są finansowane i tworzone przez dany podmiot i nie znajdują się pod jego kontrolą.
• Kary (art. 73): karze pieniężnej podlega m.in. usługodawca, który nie zapewnia spełniania wymagań dostępności usług. Kara wynosi do dziesięciokrotności przeciętnego wynagrodzenia miesięcznego w gospodarce narodowej za poprzedni rok, nie więcej niż 10% obrotu z poprzedniego roku obrotowego.
• Kto nakłada kary: Prezes Zarządu PFRON lub właściwy organ nadzoru rynku, w drodze decyzji. Wysokość zależy od zakresu i wagi naruszenia, liczby niezgodnych produktów lub usług i liczby osób, na które naruszenie wpływa.

Jeśli sprzedajesz także za granicę, każdy kraj ma własną ustawę. Porównanie znajdziesz w tekście o karach i obowiązkach w różnych krajach. Skrót dla pięciu rynków:

#Na jakiej normie technicznej opiera się EAA

EAA nie wymienia WCAG. Załącznik I wymaga, by strony i aplikacje mobilne były dostępne w spójny i odpowiedni sposób, czyli postrzegalne, funkcjonalne, zrozumiałe i kompatybilne: to te same cztery zasady, na których zbudowano WCAG. Art. 15 dodaje domniemanie zgodności dla usług zgodnych z normami zharmonizowanymi opublikowanymi w Dzienniku Urzędowym UE.

WordPress wybrał już wersję. Standardy kodowania dostępności mówią, że kod włączany do ekosystemu WordPress, w tym rdzeń, serwisy WordPress.org i oficjalne wtyczki, ma spełniać WCAG 2.2 na poziomie AA, a nowe interfejsy edycji powinny uwzględniać ATAG 2.0.

WCAG 3.0 na razie tego celu nie zmienia. To wciąż szkic roboczy W3C (Working Draft, 10 września 2026), a W3C zaznacza, że nie zastępuje on WCAG 2, której różne kraje będą wymagać jeszcze długo. W proponowanym modelu strona jest zgodna, gdy spełnia wszystkie wymagania podstawowe (core requirements), a powyżej są poziomy raportowania Bronze, Silver i Gold, nad którymi grupa robocza wciąż dyskutuje. Léonie Watson z TetraLogical (15 października 2026) opisuje ten próg zgodności jako mniej więcej równoważny WCAG 2.2 na poziomie AA, choć nie identyczny. Europejska norma EN 301 549 V3.2.1 (ETSI, marzec 2021) utożsamia swoje wymagania dla stron WWW z WCAG 2.1 na poziomie AA, więc celem pozostaje poziom AA według WCAG 2.x.

#Co zmieniło się między WCAG 2.1 a WCAG 2.2

WCAG 2.2 zostało rekomendacją W3C 5 października 2023 r., a obecne wydanie ma datę 12 grudnia 2024 r. Według strony What’s new in WCAG 2.2 dodaje dziewięć kryteriów sukcesu:

Do celu AA liczy się sześć z nich. Trzy kryteria AAA są przydatne jako wskazówki projektowe.

#Dlaczego WCAG 2.2 usunęło kryterium 4.1.1

Kryterium 4.1.1 Parsowanie (Parsing) usunięto jako przestarzałe. W3C wyjaśnia, że technologie wspomagające nie parsują już HTML samodzielnie, tylko korzystają z przeglądarki, a błędy, które wcześniej oblewały 4.1.1, dziś oblewają 1.3.1 Informacje i relacje albo 4.1.2 Nazwa, rola, wartość. Przepisy krajowe oparte na WCAG 2.1 mogą nadal go wymagać.

#Jak spełnić nowe kryteria WCAG 2.2 w motywie WordPress

#2.4.11 Fokus niezasłonięty (minimum, AA)

Gdy komponent otrzymuje fokus klawiatury, nie może być całkowicie zasłonięty przez treść dodaną przez autora. Wersja AAA (2.4.12) wymaga, by nie była zasłonięta żadna jego część.

• Problem: przechodzisz Tabem w dół strony. Element otrzymuje fokus, ale przyklejony nagłówek albo baner cookies go zasłania. Użytkownik wie, że fokus jest gdzieś, ale nie widzi gdzie.
• Naprawa: użyj scroll-padding-top na elemencie html, aby elementy z fokusem przewijały się do widocznego obszaru poniżej przyklejonego nagłówka.

html {
  scroll-padding-top: 80px; /* Wysokość przyklejonego nagłówka */
}

Baner cookies zostaw w kolejności tabulacji, z widocznym przyciskiem zamknięcia, i unikaj overflow: hidden na kontenerach, które przycinają obramowanie fokusu.

#2.4.7 Widoczny fokus i 2.4.13 Wygląd fokusu

Wiele motywów usuwa outline dla wyglądu i niczym go nie zastępuje. To oblewa 2.4.7 Widoczny fokus, które nadal jest na poziomie AA. Kryterium 2.4.13 (AAA) daje mierzalny cel projektowy: obszar wskaźnika ma być co najmniej taki jak obwód o grubości 2 pikseli CSS wokół komponentu bez fokusu, z kontrastem co najmniej 3:1 między tymi samymi pikselami w stanie z fokusem i bez niego.

W motywach blokowych zdefiniuj styl :focus-visible w theme.json albo w małym arkuszu ładowanym w edytorze i na froncie.

#2.5.7 Ruchy przeciągania (AA)

Każda funkcja obsługiwana przeciąganiem musi dać się wykonać jednym wskaźnikiem bez przeciągania, chyba że przeciąganie jest niezbędne. Dotyczy to sortowanych menu, suwaków i kreatorów w stylu tablicy. Gutenberg ma alternatywy dla wielu interakcji; własne bloki reagujące tylko na przeciąganie potrzebują przycisków lub pól.

#2.5.8 Rozmiar celu (minimum, AA)

Cele wskaźnika muszą mieć co najmniej 24 na 24 piksele CSS. Kryterium przewiduje pięć wyjątków:

• Odstęp: mniejszy cel przechodzi, jeśli okrąg o średnicy 24 pikseli CSS wyśrodkowany na nim nie przecina innego celu ani okręgu innego małego celu.
• Odpowiednik: ta sama funkcja jest dostępna w innej kontrolce na stronie, która spełnia wymóg.
• W tekście: cel stoi w zdaniu albo jego rozmiar ogranicza wysokość linii tekstu.
• Kontrola przeglądarki: rozmiar ustala przeglądarka, a autor go nie zmienia.
• Niezbędne: konkretna prezentacja jest niezbędna albo wymagana prawem.

W praktyce sprawdź małe „X” w popupach, strzałki paginacji, rzędy ikon społecznościowych, checkboxy i kontrolki karuzel. Naprawisz je przez padding, min-width i min-height bez zmiany wizualnego rozmiaru ikony.

#3.2.6 Spójna pomoc (A)

Jeśli mechanizmy pomocy powtarzają się na wielu stronach, muszą występować w tej samej kolejności względem reszty treści. Kryterium obejmuje dane kontaktowe człowieka, mechanizm kontaktu z człowiekiem, opcję samopomocy i w pełni automatyczny kanał kontaktu, np. chatbota. W WordPressie trzymaj link do wsparcia lub widżet czatu w tej samej części szablonu na każdej stronie.

#3.3.7 Zbędne wprowadzanie danych (A)

Dane, które użytkownik już podał w tym samym procesie, muszą wypełniać się automatycznie albo być dostępne do wyboru. Wyjątki to sytuacje, gdy ponowne wpisanie jest niezbędne, wymagane ze względów bezpieczeństwa albo poprzednia wartość przestała być ważna. W WooCommerce wystarczy pole „adres rozliczeniowy taki sam jak adres wysyłki”.

#3.3.8 Dostępne uwierzytelnianie (minimum, AA)

Żaden krok logowania nie może wymagać testu funkcji poznawczych, np. zapamiętania hasła albo rozwiązania łamigłówki, chyba że ten krok oferuje co najmniej jedno z poniższych: alternatywną metodę bez takiego testu, mechanizm pomagający użytkownikowi (np. menedżer haseł), test rozpoznawania obiektów albo rozpoznanie treści nietekstowej dostarczonej wcześniej przez użytkownika. Wersja AAA (3.3.9) usuwa dwa ostatnie wyjątki.

• Wpływ na WordPress: nie blokuj wklejania w polach haseł i kodów jednorazowych, żeby działały menedżery haseł. Tam, gdzie produkt na to pozwala, używaj linków logowania wysyłanych e-mailem albo WebAuthn i kluczy dostępu. Sprawdź skrypty wtyczek członkowskich blokujące wklejanie i zewnętrzne zapory antybotowe.

#Jak używać semantycznego HTML w motywach WordPress

Większość trwałych poprawek to po prostu poprawny HTML, bez wtyczek i nakładek.

• Punkty orientacyjne (landmarks): używaj <main>, <nav>, <aside>, <footer>. Użytkownicy czytników ekranu skaczą między tymi regionami. Nie chowaj wszystkiego w zupie z <div>.
• Nagłówki: h1 do h6 to hierarchia, a nie wybór stylu. Nie przeskakuj z h2 do h4 tylko dlatego, że chcesz mniejszą czcionkę. Rozmiar ustawiaj w CSS.
• Przyciski i linki:
  • Prowadzi do nowego adresu URL? Użyj <a>.
  • Zmienia coś na obecnej stronie (otwiera menu)? Użyj <button>.
  • Nigdy nie używaj <div onClick="...">. Nie dostaje fokusu z klawiatury, a czytnik nie ogłasza go jako elementu interaktywnego.
• Obrazy: obraz niosący treść dostaje alt, obraz dekoracyjny pusty alt.

ARIA uzupełnia HTML tam, gdzie natywny HTML nie wystarcza. Prawdziwy <button> jest lepszy niż role="button" na elemencie span.

#Które bloki Gutenberga najczęściej oblewają testy dostępności

Bloki rdzenia i edytor blokowy z wersji na wersję lepiej obsługują klawiaturę, ale to nie czyni dostępną każdej opublikowanej strony. Wzorce, które wciąż zawodzą:

• Bloki Grupa i Okładka z tekstem o niskim kontraście na zdjęciu. Sprawdź kontrast po zastosowaniu palety motywu.
• Blok Nawigacja z mega menu otwieranym tylko najechaniem myszą. Dodaj otwieranie kliknięciem lub Enterem i zamykanie Escape.
• Własne bloki z interaktywnymi widżetami bez elementów, które mogą dostać fokus, albo z błędnym aria-expanded.
• Wzorce z marketplace’ów ze źle zagnieżdżonymi nagłówkami lub zdublowanym h1.

Dla autorów: przed publikacją sprawdź kolejność nagłówków w widoku listy i używaj natywnych bloków Obrazek i Galeria, żeby pole alt pozostało edytowalne. Dla twórców motywów: testuj zarówno płótno edytora witryny, jak i HTML na froncie, bo nie zawsze są identyczne.

#Jak testować klasyczne i blokowe motywy WordPress

Klasyczne motywy PHP oblewają testy, gdy szablony mają na sztywno niedostępne menu albo style.css usuwa style fokusu. Układy hybrydowe (motyw klasyczny z blokowymi częściami szablonu) wymagają tych samych testów przyklejonych elementów i fokusu w szablonach PHP i HTML.

Motywy blokowe (theme.json, części szablonu) centralizują kolory i typografię, co pomaga w kontraście, jeśli paleta ma proporcje AA. Ułatwiają też wypuszczenie globalnego przyklejonego nagłówka, który łamie 2.4.11 na każdej stronie: naprawiasz go raz, w części szablonu nagłówka.

WooCommerce i wtyczki formularzy działają na motywie. Checkout, konto i formularz kontaktowy wymagają osobnego testu klawiaturą.

#Czego wymaga tag accessibility-ready dla motywu WordPress

Katalog motywów WordPress.org nadaje tag accessibility-ready dopiero po dodatkowym przeglądzie. Podręcznik zespołu motywów wymienia 18 obowiązkowych wymagań:

1. link „przejdź do treści”;
2. regiony z sensownymi rolami i nazwami;
3. pełna obsługa klawiaturą;
4. kontrolki z dostępną nazwą, rolą i stanem;
5. pola formularzy z etykietami;
6. nagłówki o sensownej strukturze;
7. podkreślone linki w tekście;
8. brak niejednoznacznych tekstów linków;
9. wystarczający kontrast tekstu i kontrolek;
10. tekst alternatywny obrazów i grafik;
11. dostępne audio, wideo i animacje;
12. obsługa przepływu treści, powiększania i zmiany odstępów tekstu;
13. brak nieoczekiwanych zmian kontekstu;
14. brak linków otwierających nowe okna lub karty bez ostrzeżenia;
15. dostępna treść pojawiająca się po najechaniu lub fokusie;
16. deklaracja dostępności;
17. zakaz polecania lub wymagania niedostępnych wtyczek;
18. obsługa tekstu tylko dla czytników ekranu.

Tag nie certyfikuje twojej strony, bo wtyczki, wzorce i treść mogą zepsuć sprawdzony motyw. Daje sprawdzoną bazę i listę kontrolną dla własnych motywów.

#Czy nakładki dostępności (overlays) działają

Widziałeś je: mała ikona człowieka w kółku w rogu, która otwiera menu do zmiany kontrastu lub rozmiaru czcionki.

Nie traktuj ich jako sposobu na zgodność.

• Fałszywe bezpieczeństwo: obiecują zgodność dzięki jednej linii JavaScriptu, ale nie naprawiają semantycznego HTML motywu.
• Utrudnienie dla użytkownika: niewidomi użytkownicy mają już skonfigurowane czytniki ekranu. Nakładka może kolidować z ich narzędziami.
• Ryzyko regulacyjne: 22 kwietnia 2025 r. amerykańska Federalna Komisja Handlu (FTC) zatwierdziła ostateczny nakaz, zgodnie z którym accessiBe ma zapłacić milion dolarów. FTC uznała twierdzenia, że widżet może uczynić każdą stronę zgodną z WCAG, za fałszywe, wprowadzające w błąd lub nieuzasadnione.

Jedyna realna droga to dostępny kod od początku albo naprawa istniejącego kodu.

#Jak testować dostępność WordPressa przed każdym wydaniem

Nie zautomatyzujesz dostępności w 100%. Narzędzia automatyczne to pierwszy krok, ale nie widzą większości pułapek klawiaturowych i wielu przypadków zasłoniętego fokusu.

#Test dostępności w trzech krokach

1. Automatycznie: użyj axe-core lub audytu dostępności w Lighthouse na stronie głównej, archiwum, wpisie, wyszukiwarce, formularzu i checkoucie. Wyłapie brakujący tekst alt, niski kontrast i błędne atrybuty ARIA. Można go uruchamiać przy każdym wdrożeniu w CI.
2. Ręcznie klawiaturą: odłącz mysz. Czy przejdziesz całe menu, otworzysz podmenu i wyślesz formularz kontaktowy, używając tylko Tab, Enter i Spacji? Sprawdź, czy fokus jest widoczny, kolejność tabulacji logiczna, a modale zamykają się klawiszem Escape.
3. Czytnikiem ekranu: włącz VoiceOver (Mac) lub NVDA (Windows) na tej samej ścieżce. Czy formularze mają opisowe etykiety, a zmiany stanu są ogłaszane?

Powtarzaj testy po aktualizacji motywu, wtyczek zmieniających znaczniki i po edycji szablonów w edytorze witryny. Wiele regresji przychodzi z commitem CSS, który ustawia outline: none.

Narzędzia pasujące do pracy z WordPressem: axe DevTools w przeglądarce, WAVE od WebAIM, Pa11y w wierszu poleceń w CI oraz wtyczka Accessibility Checker w edytorze.

#Jak tworzyć dostępne formularze w WordPress

Contact Form 7, Gravity Forms i własne formularze podlegają tym samym zasadom.

• Etykiety: każde pole potrzebuje <label> powiązanego programowo. Placeholdery nie są etykietami, bo znikają podczas pisania.
• Komunikaty błędów: „Znaleziono błąd” jest bezużyteczne. „W adresie e-mail brakuje znaku @” jest dostępne. Powiąż komunikat z polem przez aria-describedby.
• Zarządzanie fokusem: gdy formularz wraca z błędem, przenieś fokus klawiatury do pierwszego błędnego pola albo do podsumowania z linkami do pól.
• Pola wymagane: używaj atrybutu required, a nie samej czerwonej gwiazdki.
• Wklejanie: nie blokuj wklejania w polach haseł i kodów jednorazowych.

#Jak zapewnić dostępność WooCommerce i headless WordPress

Checkout WooCommerce musi działać od początku do końca z klawiatury: dodanie do koszyka, zmiana ilości, kupon, płatność i potwierdzenie. Tabele porównawcze produktów potrzebują prawdziwego <table> z <th> i atrybutem scope. Komunikaty koszyka powinny używać aria-live="polite", żeby czytnik ogłosił dodanie produktu bez przerywania użytkownikowi.

Frontendy headless w React, Next.js lub Astro mają problem, którego nie znają motywy klasyczne: zmiana trasy w aplikacji jednostronicowej nie przeładowuje strony. Po każdej zmianie trasy przenieś fokus do treści głównej, ogłoś nowy tytuł przez region aria-live i zaktualizuj document.title. Renderowanie po stronie serwera pomaga, bo treść jest w początkowym HTML jeszcze przed uruchomieniem JavaScriptu.

#Lista kontrolna WCAG 2.2 AA dla stron WordPress

• Widoczne style :focus-visible w całym motywie, nigdy niezasłonięte nagłówkiem ani banerem.
• Cele 24 na 24 piksele CSS albo z odstępem dopuszczonym przez 2.5.8.
• Alternatywa bez przeciągania dla każdej kontrolki przeciąganej.
• Pomoc w tej samej kolejności na wszystkich szablonach.
• Brak ponownego wpisywania tych samych danych w jednym procesie.
• Logowanie, które przyjmuje wklejone hasła i kody.
• Spisana ocena z art. 14, jeśli powołujesz się na nieproporcjonalne obciążenie.

Sektory z ustawowym obowiązkiem dostępności mają tu najwięcej do stracenia: strony internetowe dla urzędów i strony dla szpitali muszą spełniać WCAG od pierwszego dnia.

Jeśli potrzebujesz audytu dostępności WCAG szablonów, bloków albo ścieżki zakupowej, zaczynamy od udokumentowanego audytu szablonów, które faktycznie publikujesz, a nie od instalacji nakładki. Szerszą ocenę zgodności z przepisami UE opisuje audyt zgodności EU.