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

W czerwcu 2025 roku krajobraz cyfrowy zmienił się na zawsze. Europejski Akt o Dostępności (EAA) wszedł w pełne życie, czyniąc dostępność internetową wymogiem prawnym dla prawie wszystkich firm cyfrowych 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 standardem jest WCAG 2.2 Poziom AA. Ten przewodnik (2000+ słów) wyjaśnia dokładnie, co zmieniło się w 2026 roku i jak upewnić się, że Twój motyw nie łamie prawa.

1. Eaa: Dlaczego rok 2025 był punktem zwrotnym

Wcześniej prawa dotyczące dostępności dotyczyły głównie Sektora 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 ze szkodami wizerunkowymi wynikającymi z wykluczenia 15% globalnej populacji.

2. WCAG 2.2: Wyjaśnienie nowych kryteriów

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. Semantyczny HTML: Fundament

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. Pułapka „nakładek” (overlays)

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. Testowanie: Automatyczne vs. Ręczne

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

Przepływ pracy testowania

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. 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.

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