Przejdź do treści
SEOMaster SEOMaster

WCAG 2.2 — praktyczna checklista dostępności strony

Dostępność sprawdza się warstwami: automat znajduje powtarzalne błędy, klawiatura ujawnia problemy obsługi, a czytnik ekranu pokazuje, czy interfejs ma sens bez obrazu. Ta checklista prowadzi przez wszystkie trzy.

Autor: Redakcja SEOMaster · opublikowano 21.08.2026 · aktualizacja 27.08.2026

Audyt WCAG 2.2: od automatu do testu realnego zadania

Znajdź swoją sytuację, wykonaj decyzję i potwierdź ją dowodem.

  1. JeśliAutomat wykrywa błądZróbNapraw kod, nazwę kontrolki, kontrast lub semantykę

    Sprawdź: Powtórny skan nie zgłasza regresji na żadnym reprezentatywnym szablonie

  2. JeśliAutomat nie pokazuje krytycznych błędówZróbPrzejdź kluczowe zadanie wyłącznie klawiaturą

    Sprawdź: Fokus jest widoczny i logiczny, a wszystkie kontrolki działają bez myszy

  3. JeśliScenariusz klawiaturowy działaZróbWykonaj go czytnikiem ekranu

    Sprawdź: Nagłówki, etykiety, komunikaty i kolejność mają zrozumiały sens

  4. JeśliCzytnik pozwala ukończyć zadanieZróbSprawdź powiększenie 200% i wąski ekran

    Sprawdź: Treść nie znika, nie nachodzi na siebie i nie wymaga przewijania w dwóch kierunkach

Pełny audyt WCAG nie kończy się zielonym wynikiem Lighthouse. Automat potrafi znaleźć brakujące etykiety, część problemów kontrastu i błędy ARIA, ale nie oceni, czy tekst alternatywny ma sens ani czy kolejność fokusu odpowiada zadaniu użytkownika. Dlatego zaczynamy od automatu, a kończymy testem ręcznym.

WCAG — co dokładnie oznacza poziom AA — pełna definicja w słowniku

Warstwa 1: szybki test automatyczny

1. Uruchom skan reprezentatywnych stron

Sprawdź co najmniej stronę główną, formularz kontaktowy, stronę z ofertą lub produktem oraz jeden długi artykuł. Jeden poprawny szablon nie dowodzi, że pozostałe typy stron są dostępne.

https://seomaster.live/test-dostepnosci-strony

2. Napraw obrazy bez poprawnego alt

Obraz informacyjny potrzebuje opisu przekazującego jego funkcję. Dekoracja powinna mieć jawne alt="". Nie kopiuj nazwy pliku i nie zaczynaj od słów „obraz przedstawia”.

<img src="wykres.webp" alt="Wzrost ruchu organicznego z 1200 do 1900 wizyt od stycznia do marca">
<img src="ornament.svg" alt="">

Tekst alternatywny — zasady i przykłady — pełna definicja w słowniku

3. Nadaj nazwy polom i kontrolkom

Każde pole formularza potrzebuje widocznej etykiety połączonej przez for/id. Przycisk z samą ikoną potrzebuje dostępnej nazwy. Najpierw używaj natywnego HTML; ARIA nie naprawia elementu, który z natury jest źle dobrany.

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

<button type="button" aria-label="Zamknij okno">×</button>

ARIA — kiedy pomaga, a kiedy szkodzi — pełna definicja w słowniku

Warstwa 2: test wyłącznie klawiaturą

4. Odłóż mysz i przejdź cały scenariusz

Używaj Tab, Shift+Tab, Enter, Spacji i Escape. Fokus musi być zawsze widoczny, kolejność logiczna, a menu, dialogi i formularze muszą dać się obsłużyć bez wskaźnika.

5. Sprawdź początek strony i skip link

Pierwszy Tab powinien odsłonić link prowadzący do głównej treści. Po aktywacji fokus ma znaleźć się w obszarze main, a nie wrócić na początek dokumentu.

Skip link — mały element o dużym wpływie — pełna definicja w słowniku

6. Zmierz kontrast i widoczność fokusu

Dla zwykłego tekstu poziom AA wymaga co najmniej 4,5:1, a dla dużego 3:1. Sprawdź również obramowanie fokusu, tekst na zdjęciach, placeholdery i stany błędu — nie tylko główny akapit.

Kontrast — progi WCAG i typowe pułapki — pełna definicja w słowniku

Warstwa 3: czytnik ekranu i powiększenie

7. Przejdź stronę czytnikiem ekranu

Na Windows zacznij od NVDA, na macOS i iOS od VoiceOver. Sprawdź listę nagłówków i punktów orientacyjnych, potem wykonaj realne zadanie: znajdź cenę, wyślij formularz albo dodaj produkt do koszyka.

Drzewo dostępności — to, co naprawdę czyta czytnik — pełna definicja w słowniku

8. Powiększ do 200 procent

Treść nie może znikać, nachodzić na siebie ani wymagać przewijania w dwóch kierunkach. Nie blokuj zoomu w viewport. Przy wąskim ekranie sprawdź także orientację poziomą.

Jak zapisać wynik audytu

  • Adres i typ strony.
  • Krok prowadzący do błędu.
  • Kryterium WCAG i poziom.
  • Dowód: selektor, zrzut lub krótki opis z czytnika.
  • Wpływ na użytkownika.
  • Proponowana poprawka i osoba odpowiedzialna.
  • Data ponownego testu.

Najważniejsza reguła: Nie zapisuj „wynik dostępności 92”. Zapisuj bariery, scenariusze i dowody. Liczba jest użyteczna do monitorowania regresji automatycznych, ale nie mówi, czy człowiek może wykonać zadanie.

Kiedy test jest zakończony

  • Automat nie zgłasza krytycznych naruszeń na żadnym typie strony.
  • Pełny scenariusz da się wykonać klawiaturą.
  • Nagłówki i punkty orientacyjne mają sens w czytniku ekranu.
  • Strona działa przy powiększeniu 200%.
  • Każda poprawka ma ponowny test i zapisany dowód.

Najczęstsze pytania

Czy Lighthouse wystarczy do audytu WCAG?

Nie. Jest dobrym automatem do wykrywania części naruszeń i regresji, ale nie zastępuje testu klawiaturą, czytnikiem ekranu ani oceny sensu treści.

Jaki poziom WCAG wybrać?

Dla większości projektów praktycznym celem jest WCAG 2.2 AA. Poziom A to minimum, a AAA nie jest przeznaczony jako ogólny wymóg dla całych serwisów.

Ile stron trzeba sprawdzić?

Nie ma jednej liczby. Wybierz każdy unikalny szablon i kluczowy scenariusz użytkownika, a do tego kilka stron z treścią tworzonych ręcznie.

Jak często powtarzać audyt?

Po zmianie szablonu, komponentów formularza lub nawigacji oraz regularnie w CI dla reguł automatycznych. Pełny test ręczny warto powtarzać przy większym wydaniu.

Źródła i dokumentacja

Pojęcia z tego poradnika

Wszystkie poradniki · Cała Wiedza · Uruchom test dostępności