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

Od czerwca 2025 roku Europejski Akt o Dostępności (EAA) zaczął realnie wpływać na obowiązki właścicieli sklepów, aplikacji i stron internetowych działających w UE.

To już nie jest tylko „miło to mieć” (nice to have). To odpowiednik RODO. Brak zgodności grozi znacznymi karami i procesami sądowymi.

Dla deweloperów WordPress i właścicieli stron punktem odniesienia jest WCAG 2.2 Poziom AA. Ten tekst pokazuje, co trzeba sprawdzić w motywie, koszyku, formularzach i treści, żeby ograniczyć ryzyko prawne.

#1. Kogo obejmuje EAA i jakie grożą kary?

Wcześniej prawa dotyczące dostępności dotyczyły głównie Sektóra Publicznego (Rząd/Uczelnie). EAA rozszerzyło to na E-commerce, Bankowość, Transport i E-booki.

• Zasięg: Jeśli sprzedajesz koszulkę klientowi we Francji, Twój proces zakupu (checkout) musi być dostępny.
• Kara: Grzywny różnią się w zależności od kraju, ale mogą być surowe, w połączeniu że szkodami wizerunkowymi wynikającymi z wykluczenia 15% globalnej populacji.

#2. Jakie nowe kryteria wprowadza WCAG 2.2?

WCAG 2.2 nadbudowało 2.1, dodając 9 nowych kryteriów. Najbardziej krytyczne dla motywów WordPress to:

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

• Problem: Tabujesz w dół strony. Element otrzymuje fokus, ale Twój „Sticky Header” lub „Baner Ciasteczkowy” go zasłania. Użytkownik wie, że gdzieś jest, ale nie widzi gdzie.
• Naprawa: Użyj CSS scroll-padding-top na elemencie html, aby upewnić się, że elementy z fokusem przewijają się do widocznego obszaru poniżej przyklejonego nagłówka.

#2.5.8 Rozmiar celu (target size, minimum, AA)

• Zasada: Interaktywne cele (przyciski) muszą mieć co najmniej 24x24 piksele CSS.
• Rzeczywistość: Te malutkie „X” do zamykania popupów? Są nielegalne. Powiększ je. Dotknięcia palcem są nieprecyzyjne.

#3.3.8 Dostępne uwierzytelnianie (AA)

• Zasada: Nie zmuszaj użytkowników do rozwiązywania łamigłówek (CAPTCHA) ani zapamiętywania haseł bez pomocy.
• Wpływ na WordPress: Wspieraj menedżery haseł (nie blokuj wklejania w polach haseł) i używaj „Magic Links” lub WebAuthn (Biometria) tam, gdzie to możliwe.

#3. Jak używać semantycznego HTML dla dostępności?

90% problemów z dostępnością rozwiązuje się poprzez pisanie poprawnego HTML.

• Punkty Orientacyjne (Landmarks): Używaj <main>, <nav>, <aside>, <footer>. Użytkownicy czytników ekranowych skaczą między tymi regionami. Nie top wszystkiego w zupie <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ę. Używaj CSS do rozmiaru.
• Przyciski vs. Linki:
  • Idzie do nowego adresu URL? Użyj <a>.
  • Zmienia coś na obecnej stronie (otwiera menu)? Użyj <button>.
  • Nigdy nie używaj <div onClick="...">. Jest niewidoczny dla klawiatur.

#4. 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. Unikaj ich.

• Fałszywe Bezpieczeństwo: Twierdzą, że uczynią Cię zgodnym natychmiast za pomocą jednej linii JS. Nie zrobią tego. Nie mogą naprawić błędów semantycznego HTML.
• Tarcie Użytkownika: Niewidomi użytkownicy mają już swoje czytniki ekranowe. Nie potrzebują Twojej nakładki ingerującej w ich narzędzia.
• Ryzyko Prawne: W USA firmy używające nakładek były pozywane częściej, ponieważ dowodzi to, że wiedziały o problemie, ale wybrały rozwiązanie typu „plaster”.

#5. Jak testować dostępność automatycznie i ręcznie?

Nie możesz zautomatyzować dostępności w 100%.

#Test dostępności w trzech krokach

1. Automatyczne (30%): Użyj axe-core lub audytu Lighthouse „Accessibility”. To wyłapuje brakujący tekst alt i niski kontrast.
2. Ręczne Klawiaturą (50%): Odłącz myszkę. Czy możesz nawigować po całym menu, otwierać podmenu i wypełnić formularz kontaktowy używając tylko klawiszy Tab, Enter i Spacji? Jeśli nie, oblewasz.
3. Czytnik Ekranowy (20%): Włącz VoiceOver (Mac) lub NVDA (Windows). Zamknij oczy. Czy rozumiesz, co się dzieje?

#6. Jak tworzyć dostępne formularze w WordPress?

Contact Form 7 i Gravity Forms są popularne, ale często źle skonfigurowane.

• Etykiety (Labels): Każdy input potrzebuje <label>. Placeholdery NIE są etykietami (znikają, gdy piszesz).
• Komunikaty Błędów: „Znaleziono błąd” jest bezużyteczne. „W adresie e-mail brakuje symbolu @” jest dostępne.
• Zarządzanie Fokusem: Gdy użytkownik wysyła formularz i jest błąd, programowo przenieś fokus klawiatury do pierwszego błędnego pola, aby mógł go naprawić natychmiast.

#7. Podsumowanie

Dostępność jest często przedstawiana jako ograniczenie. W rzeczywistości jest wskaźnikiem jakości. Dostępny kod jest czystszy, bardziej robustny i lepszy dla SEO. W 2026 roku budowanie inkluzywnego internetu to nie tylko prawo, to jedyny profesjonalny sposób pracy.

Sektory z prawnym 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.

Potrzebujesz Audytu Dostępności? WPPoland świadczy usługi remediacji WCAG 2.2 dla enterprise.

Po stronie wdrożenia ten temat trzymamy pod powiązaną usługę.