WCAG 2.2 dla WordPressa – jak spełnić wymóg dostępności w 2026

Od czerwca 2025 w UE obowiązuje European Accessibility Act (EAA). W praktyce: wszystkie strony e-commerce, banki, ubezpieczenia, transport, e-booki MUSZĄ spełniać WCAG 2.2 poziom AA. Mandat: do 100 000 zł lub 2% rocznych obrotów. Pokażę Ci, jak to ogarnąć w WordPressie bez przepisywania strony od zera.

W skrócie

• WCAG 2.2 to standard dostępności W3C — definiuje, jak ludzie z niepełnosprawnościami mają używać Twojej strony.
• Poziom AA to wymóg prawny — to nie „nice-to-have”, to prawo.
• W praktyce: kontrast min. 4,5:1, focus indicator, klawiatura, alt teksty, ARIA labels.
• Czas wdrożenia w WordPressie: 1–3 tygodnie dla witryny do 200 podstron.

Co dokładnie zmieniło się w WCAG 2.2

WCAG 2.0 (2008) → WCAG 2.1 (2018) → WCAG 2.2 (2023) — najnowsza wersja.

WCAG 2.2 dodaje 9 nowych kryteriów (vs. 2.1):

1. Focus Not Obscured (Minimum) — focus musi być widoczny, nie zasłonięty
2. Focus Not Obscured (Enhanced) — całkowicie widoczny, nie częściowo
3. Focus Appearance — minimalny rozmiar i kontrast indicatora
4. Dragging Movements — drag&drop musi mieć alternatywę (klik)
5. Target Size — element interaktywny min. 24×24 px (mobilna 44×44)
6. Consistent Help — link do pomocy w tym samym miejscu na każdej stronie
7. Redundant Entry — nie zmuszaj użytkownika do wpisywania tych samych danych ponownie
8. Accessible Authentication (Minimum) — login bez „kognicji” (puzzle CAPTCHA są out)
9. Accessible Authentication (Enhanced) — bez nawet pamiętania hasła (one-time codes, passkeys)

Trzy poziomy zgodności

• A — minimum (większość stron już ma)
• AA — wymóg prawny (EAA, polskie prawo dla sektora publicznego)
• AAA — najwyższy, nie wymagany dla biznesu

Cel: poziom AA.

Kluczowe wymagania — 12 punktów do zrobienia

1. Kontrast tekstu min. 4,5:1

Tekst na tle musi mieć kontrast 4,5:1 dla rozmiaru < 18 pt, 3:1 dla większego.

Test: WebAIM Contrast Checker — wpisz hex tekstu i tła.

Najczęstsze błędy:
– Szary tekst #999 na białym tle = kontrast 2,8:1 (FAIL)
– Białe na pomarańczowym #FFA500 = kontrast 1,9:1 (FAIL)
– Różne kontrasty w light vs dark mode

Naprawa: ciemniej szary (#333+ na białym), inny accent color, dodanie obrysu/cienia.

2. Każdy obraz ma alt attribute

<!-- ŹLE -->
<img src="logo.png">

<!-- DOBRZE -->
<img src="logo.png" alt="Websky Studio - logo">

W WordPressie: dodaj alt podczas wgrywania medii. Wtyczka Alt Text Generator może auto-generować alty AI dla istniejących obrazów.

Wyjątek: dekoracyjne obrazy mogą mieć alt="" (pusty) — screen reader je zignoruje.

3. Focus indicator widoczny

Każdy interaktywny element (link, button, input) musi widocznie pokazywać focus przy nawigacji klawiaturą (Tab).

Domyślny focus przeglądarki często jest wystarczający. Jeśli motyw go usuwa CSS-em (outline: none), jest źle — przywróć:

:focus-visible {
  outline: 3px solid #0066ff;
  outline-offset: 2px;
}

4. Cała strona obsługiwalna klawiaturą

Test: odłącz mysz. Spróbuj:
– Przejść Tab po wszystkich elementach
– Wypełnić formularz
– Kupić produkt
– Otworzyć i zamknąć modale

Wszystko musi działać. Dropdown menu otwierane tylko na hover = FAIL — dodaj otwieranie na focus/Enter.

5. Skip link na początku strony

Pierwszy element strony to link „Przejdź do treści głównej” (widoczny przy fokusie):

<a href="#main" class="skip-link">Przejdź do treści głównej</a>

Pozwala omijać menu osobom używającym screen readera.

6. Logiczna hierarchia nagłówków

H1 raz na stronę → H2 sekcje → H3 podsekcje. Nie przeskakuj poziomów (H1 → H4 = źle).

Wtyczka Headers Order (darmowa) sprawdzi i ostrzeże o błędach.

7. Formularze z <label>

Każde pole input ma label (widoczny lub aria-label):

<label for="email">Adres e-mail</label>
<input type="email" id="email" name="email" required>

Bez tego screen reader nie wie, czego dotyczy pole.

8. Komunikaty błędów dostępne

Po wysłaniu formularza z błędem:
– Komunikat błędu w pobliżu pola (nie tylko górze strony)
– Kolor + ikona + tekst (nie tylko kolor — daltoniści nie zobaczą)
– aria-invalid="true" na polu z błędem
– Focus przeniesiony na pierwszy błąd

9. Wideo z napisami (closed captions)

Każde wideo z mową musi mieć napisy. YouTube oferuje auto-napisy, ale sprawdź ich poprawność (auto-napisy często psują polskie diakrytyki).

Dla self-hosted wideo — plik .vtt z napisami:

<video controls>
  <source src="film.mp4" type="video/mp4">
  <track kind="captions" src="napisy.vtt" srclang="pl" label="Polski">
</video>

10. Struktura semantyczna HTML

Używaj właściwych tagów:
– <nav> dla nawigacji
– <main> dla treści głównej
– <header>, <footer>, <article>, <section>
– <button> dla przycisków, <a> dla linków (NIE odwrotnie)

WordPress core już to robi dobrze. Custom motywy często łamią — sprawdź swój.

11. Target size min. 24×24 px

Każdy klikalny element musi mieć min. 24×24 px (44×44 dla mobilnej). Ikony social media 16×16 w stopce = FAIL.

Naprawa: dodaj padding wokół ikony, nie zwiększając samej grafiki.

12. Brak migotania

Żadne animacje migoczące częściej niż 3× na sekundę (epileptyczne ryzyko). Sprawdź wszystkie:
– Loading spinnery
– Hover effects
– Animowane GIFy
– Wideo z efektami strobe

Wtyczki WordPress, które pomagają

WP Accessibility (darmowa)

Naprawia podstawowe błędy:
– Skip link
– Sprawdza alt teksty
– Rozjaśnia kontrast focus indicator
– Ukrywa role redundancy

Accessibility Checker (freemium)

Skanuje każdą stronę i pokazuje błędy WCAG. Free do 25 stron, pro od 49 USD/rok.

One Click Accessibility (darmowa)

Dodaje „widget” z opcjami: większy tekst, czytelne fonty, wysoki kontrast. Uwaga: to nie zastępuje prawdziwej dostępności — to tylko „vanity feature” dla audytora.

WCAG 2.2 (oryginalna)

Wtyczka oficjalna od WordPressa, lekka, dobra na start.

Audyt dostępności — jak go zrobić

Narzędzia automatyczne

• axe DevTools (Chrome extension, darmowe) — najsensowniejsze automatyczne narzędzie
• WAVE (WebAIM, darmowe online) — wizualny raport błędów
• Lighthouse (wbudowany Chrome) — audit Accessibility

Limit narzędzi automatycznych: wykrywają 30% błędów. Resztę musi sprawdzić człowiek.

Audyt manualny

1. Przejdź stronę klawiaturą (Tab, Enter, Esc, strzałki)
2. Sprawdź screen readerem (NVDA dla Windows — darmowy)
3. Sprawdź kontrast wszystkich tekstów
4. Sprawdź mobile — target size, touch zoom
5. Wyłącz CSS — czy strona dalej ma sens?

Profesjonalny audit

Pełny audit WCAG 2.2 AA u zewnętrznej firmy: 5 000–15 000 zł dla witryny do 100 podstron. Z certyfikatem zgodności do okazania w przypadku kontroli.

Plan wdrożenia w 3 tygodnie

Tydzień 1: Analiza
– Audyt automatyczny (axe, WAVE)
– Spisanie wszystkich błędów
– Priorytetyzacja: krytyczne → ważne → drobne

Tydzień 2: Naprawa krytyczna
– Kontrast tekstów
– Alt teksty (auto-gen z AI + manualnie ważnych)
– Focus indicators
– Skip link
– Klawiatura

Tydzień 3: Naprawa drobnych + dokumentacja
– ARIA labels
– Logical heading order
– Formularze z label
– Test screen reader
– Statement of accessibility (oświadczenie o dostępności na stronie)

Co dalej

W tym tygodniu:

1. Zainstaluj axe DevTools w Chrome
2. Otwórz swoją stronę → DevTools → axe → Run scan
3. Spisz top 10 błędów
4. Zaplanuj naprawę

Robimy audyty WCAG 2.2 + naprawę błędów — w 2 tygodnie sprawiamy, że Twoja strona spełnia wymogi EAA. Cena pakietu od 2 500 zł netto. Napisz do nas.