WCAG 2.2 — nowy standard dostępności cyfrowej

WCAG 2.2 to nie sugestia, a twardy wymóg prawny i biznesowy. Od 28 czerwca 2025 roku wszystkie nowe strony i aplikacje podmiotów publicznych w UE muszą spełniać standard WCAG 2.2 na poziomie AA. Jeśli myślisz, że to tylko „dobra praktyka” dla niewidomych, popełniasz błąd kosztujący utratę klientów, pozycji w Google i ryzyko pozwów.

Czym jest WCAG 2.2?

WCAG (Web Content Accessibility Guidelines) to międzynarodowy standard dostępności cyfrowej. Wersja 2.2, opublikowana w październiku 2023 przez W3C, zastępuje WCAG 2.1. Nie jest to rewolucja, ale ewolucja – dodaje 9 nowych kryteriów sukcesu (głównie na poziomie A i AA) i usuwa jedno. Główne zmiany dotyczą ułatwień dla osób z niepełnosprawnościami poznawczymi, motorycznymi i wzrokowymi.

Kogo dotyczy obowiązek?

Nie tylko sektor publiczny. Dyrektywa UE (EAA – European Accessibility Act) nakłada obowiązek na:

Podmioty publiczne (urzędy, szkoły, szpitale) – od 28 czerwca 2025.
Firmy prywatne świadczące usługi kluczowe (banki, e-commerce, telekomunikacja, transport) – od 28 czerwca 2025.
Wszystkie firmy zatrudniające powyżej 10 osób i oferujące produkty/usługi online – od 28 czerwca 2030.

Kary? W Polsce – nawet 10 000 zł za brak deklaracji dostępności, a w UE – do 5% rocznego obrotu.

Kluczowe wymagania WCAG 2.2 (co musisz wdrożyć)

1. Focus Order i Focus Appearance (2.4.11 i 2.4.12 – poziom AA)

Każdy element interaktywny (link, przycisk, pole formularza) musi mieć wyraźny wskaźnik fokusu (np. gruba, kontrastowa obwódka).
Kolejność fokusu (Tab) musi być logiczna – nie możesz skakać z nagłówka do stopki.
Przykład błędu: Przycisk „Dodaj do koszyka” znika po naciśnięciu Tab, bo ma outline: none w CSS.

2. Drag Movements (2.5.7 – poziom AA)

Funkcje przeciągania (drag & drop) muszą mieć alternatywę jednym kliknięciem (np. przyciski „Przenieś w górę/dół”).
Przykład: Sortowanie produktów w koszyku – nie możesz wymagać przeciągania. Daj przyciski strzałek.

3. Target Size (2.5.8 – poziom AA)

Elementy klikalne (linki, przyciski) muszą mieć min. 24x24 px (z tolerancją dla małych elementów w linii tekstu).
Przykład błędu: Ikona koszyka ma 16x16 px i jest nieklikalna na telefonie.

4. Accessible Authentication (3.3.7 i 3.3.8 – poziom AA)

Logowanie nie może opierać się wyłącznie na rozpoznawaniu obrazków (CAPTCHA) ani na zapamiętywaniu haseł (np. „wpisz 3. literę hasła”).
Rozwiązanie: Użyj alternatyw jak magic link, kod SMS, lub CAPTCHA oparta na checkboxie.

5. Consistent Help (3.2.6 – poziom A)

Jeśli masz czat lub pomoc, musi być w tym samym miejscu na każdej podstronie.

Najczęstsze błędy dostępności na stronach (i jak je naprawić)

Brak etykiet w formularzach – pola bez <label> lub z placeholder jako jedyną wskazówką. Fix: Każde <input> musi mieć <label for="id">.
Kontrast tekstu – szary tekst na białym tle (np. #999 na #FFF). Fix: Minimalny współczynnik 4.5:1 dla tekstu normalnego, 3:1 dla dużego.
Linki „więcej” lub „tutaj” – nie mówią, dokąd prowadzą. Fix: „Zobacz ofertę laptopów Dell” zamiast „Kliknij tutaj”.
Brak nagłówków (H1-H6) – strona to jedna ściana tekstu. Fix: Użyj semantycznych nagłówków w logicznej hierarchii.
Filmy bez napisów – brak transkrypcji lub napisów dla niesłyszących. Fix: Dodaj napisy (SRT) i transkrypcję tekstową.

Jak sprawdzić zgodność z WCAG 2.2?

Nie polegaj na jednym narzędziu. Proces to połączenie automatyzacji i ręcznego testu.

Krok 1: Automatyczne skanery

WAVE (darmowe rozszerzenie do Chrome) – szybko znajdzie błędy kontrastu, brak etykiet, puste linki.
axe DevTools – integruje się z przeglądarką i podaje konkretne reguły WCAG.
Lighthouse (wbudowany w Chrome DevTools) – daje ogólny wynik, ale nie wykrywa wszystkiego.

Krok 2: Ręczne testy (obowiązkowe)

Nawigacja klawiaturą – przejdź całą stronę używając tylko Tab, Shift+Tab i Enter. Sprawdź, czy widzisz fokus.
Czytnik ekranu – NVDA (darmowy na Windows) lub VoiceOver (wbudowany w Mac). Sprawdź, czy czyta nagłówki, linki i formularze.
Test kontrastu – użyj Colour Contrast Analyser (darmowy) dla każdej pary kolorów.

Krok 3: Raport i audyt

Zrób listę kryteriów WCAG 2.2 (poziom A i AA) i zaznacz, które przechodzą.
Praktyczna rada: Nie próbuj naprawić wszystkiego naraz. Zacznij od kryteriów poziomu A (najbardziej krytyczne), potem AA.

Związek z SEO – dlaczego dostępność to Twój ranking

Google nie mówi tego wprost, ale dostępność i SEO to dwie strony tego samego medalu.

Nagłówki (H1-H6) – pomagają robotom Google zrozumieć strukturę strony. Brak nagłówków = gorsze indeksowanie.
Tekst alternatywny (alt) – obrazy bez alt są dla Google niewidoczne. Dobry alt to sygnał tematyczny.
Linki opisowe – „Dowiedz się więcej o kredytach hipotecznych” działa lepiej niż „Kliknij tutaj” – Google analizuje anchor text.
Szybkość ładowania – dostępność wymaga lekkiego kodu (np. poprawne użycie ARIA nie spowalnia strony). Google nagradza szybkie strony.
Mobile-first – WCAG 2.2 wymaga responsywności i dużych celów dotykowych. To samo robi Google od 2019 roku.

Przykład z życia: Strona sklepu z butami miała błąd kontrastu (szary tekst na białym) i brak etykiet w filtrze rozmiarów. Po naprawie – wzrost CTR z wyników wyszukiwania o 12% w ciągu 3 miesięcy. Dlaczego? Użytkownicy z dysleksją i słabym wzrokiem przestali od razu zamykać stronę.

Podsumowanie dla praktyka

WCAG 2.2 to nie biurokracja. To konkretne reguły, które:

Chronią przed karami (do 5% obrotu w UE).
Zwiększają konwersję (nawet 20% użytkowników ma jakieś ograniczenie – wzrok, słuch, motoryka).
Poprawiają SEO (lepsza struktura, szybsze ładowanie, wyższy CTR).

Zacznij od audytu automatycznego (WAVE) i testu klawiatury. To zajmie Ci 30 minut, a pokaże 80% błędów. Resztę – czytnik ekranu i kontrast – zrób w ciągu jednego popołudnia. Nie czekaj na 2030 rok.

To temat, który najwięcej daje, gdy potraktujesz go jako część dostępność cyfrowa zgodna z wcag, a nie odosobnioną ciekawostkę — bo dopiero w systemie pojedyncze elementy zaczynają się sumować.

Masz pytania do tego artykułu lub chcesz żebym spojrzał na Twój sklep?

Napisz do mnie →