WCAG 2.2 opisuje kryteria sukcesu zorganizowane wokół czterech zasad: postrzegalności, funkcjonalności, zrozumiałości i solidności. Poziom AA jest najczęściej przyjmowanym celem dla stron usługowych. Wymagania prawne zależą od rodzaju podmiotu i usługi, dlatego kwestii zgodności nie należy rozstrzygać samym artykułem.
Z perspektywy wdrożenia dostępność poprawia także ogólną jakość. Czytelne etykiety, rozsądne cele dotykowe, logiczne nagłówki i komunikaty błędów pomagają użytkownikom w słońcu, w stresie, na małym telefonie albo przy wolniejszym łączu.
Semantyczny HTML i struktura dokumentu
Używaj prawdziwych elementów header, nav, main, footer, button, a i form zgodnie z ich rolą. Klikalny div wymaga ręcznego odtworzenia zachowania klawiatury i zwykle jest gorszy niż natywny przycisk. Strona powinna mieć logiczny H1 oraz hierarchię nagłówków opisującą sekcje, a nie wielkość fontu.
Dodaj link pomijający nawigację, poprawny język dokumentu i opisowe tytuły stron. Landmarki powinny być jednoznaczne, szczególnie gdy występuje kilka nawigacji. ARIA stosuj tylko wtedy, gdy natywny HTML nie wystarcza. Błędna rola może zaszkodzić bardziej niż jej brak.
Klawiatura, fokus i elementy interaktywne
- Przejdź całą stronę klawiszem Tab od początku do końca.
- Sprawdź, czy kolejność fokusu odpowiada kolejności wizualnej i logicznej.
- Otwórz i zamknij menu, modal, akordeon oraz ustawienia cookies bez myszy.
- Upewnij się, że fokus jest wyraźny na ciemnym i jasnym tle.
- Po zamknięciu modalu zwróć fokus do elementu, który go otworzył.
- Nie twórz pułapek klawiatury i nie ukrywaj fokusu stylem outline: none.
WCAG 2.2 dodaje między innymi kryteria dotyczące zasłoniętego fokusu i minimalnego rozmiaru celu na poziomie AA. Baner cookies nie powinien przykrywać aktualnie używanego elementu bez możliwości obsługi. Na mobile przyciski muszą mieć rozsądny obszar dotyku i odstęp.
Kontrast, powiększenie i reflow
Tekst powinien zachowywać wymagany kontrast względem tła, a ważne elementy graficzne i stan fokusu muszą być rozpoznawalne. Sam kolor nie może być jedynym sposobem oznaczenia błędu lub aktywnego pola. Czerwone obramowanie warto uzupełnić ikoną, komunikatem i powiązaniem programistycznym.
Sprawdź stronę przy powiększeniu 200 i 400 procent oraz w wąskim widoku odpowiadającym 320 pikselom CSS. Treść nie powinna wymagać poziomego przewijania, poza elementami, które rzeczywiście go potrzebują, jak duża tabela. Tabele należy umieścić w kontrolowanym kontenerze z przewijaniem i widocznym nagłówkiem.
Dostępny formularz kontaktowy
| Element | Wymaganie | Przykład błędu |
|---|---|---|
| Etykieta | Widoczna i programowo powiązana | Placeholder jako jedyny opis |
| Wymagane pole | Informacja tekstowa i required | Tylko czerwona gwiazdka |
| Błąd | Konkretny komunikat przy polu | Ogólne coś poszło nie tak |
| Sukces | Komunikat odczytywany przez technologię wspomagającą | Zmiana koloru bez tekstu |
| Zgoda | Zrozumiała treść i osobne pole | Domyślnie zaznaczony checkbox |
Po błędzie zachowaj wpisane dane i przenieś fokus do podsumowania lub pierwszego błędnego pola. Komunikat powinien mówić, jak poprawić wartość. Dla telefonu i e-maila ustaw odpowiedni autocomplete oraz inputmode, aby ułatwić wprowadzanie na urządzeniu mobilnym.
Obrazy, ikony, animacje i multimedia
Alt opisuje funkcję lub informację obrazu w danym kontekście. Dekoracyjna grafika powinna mieć pusty alt, a przycisk z samą ikoną potrzebuje dostępnej nazwy. Nie powtarzaj w alt tekstu widocznego obok. Zrzut wykresu wymaga krótkiego opisu oraz danych lub wniosków w treści.
Film z mową potrzebuje napisów, a ważna informacja wizualna może wymagać audiodeskrypcji. Animacje wywołane interakcją powinny respektować prefers-reduced-motion. Migające treści są szczególnie ryzykowne i zwykle nie mają uzasadnienia na stronie firmowej.
Test automatyczny to początek, nie koniec
Lighthouse, axe lub WAVE wykrywają między innymi brakujące nazwy, część problemów kontrastu i niepoprawne atrybuty. Nie ocenią jednak, czy alt ma sens, kolejność fokusu jest logiczna, komunikat błędu jest pomocny, a tekst zrozumiały. Dlatego wynik 100 nie oznacza pełnej zgodności.
Minimalny zestaw manualny obejmuje klawiaturę, powiększenie, mobile, tryb wysokiego kontrastu i próbę popularnym czytnikiem ekranu. W ważnym serwisie warto zaangażować osoby korzystające z technologii wspomagających. Ich doświadczenie ujawnia bariery, których checklista nie przewiduje.
Jak włączyć dostępność do procesu projektu?
- Projekt: kontrasty, stany, fokus, błędy i wielkości celów dotykowych.
- Content: język, nagłówki, linki, alt i transkrypcje.
- Development: semantyka, klawiatura, ARIA, reflow i komunikaty.
- QA: automat plus scenariusze manualne na kilku urządzeniach.
- Publikacja: szybki regres kluczowych ścieżek i formularza.
- Utrzymanie: kontrola po zmianie komponentu, treści lub zewnętrznej wtyczki.
W centrum badań i zasobów tej strony znajduje się skrócona checklista WCAG do wykorzystania podczas odbioru projektu.
Najczęstsze pytania
Czy wynik Lighthouse 100 oznacza zgodność z WCAG?
Nie. Automat sprawdza tylko część kryteriów i nie ocenia wielu aspektów kontekstu oraz użyteczności.
Czy każda grafika musi mieć opisowy alt?
Nie. Grafika dekoracyjna powinna mieć pusty alt. Opis jest potrzebny, gdy obraz przekazuje informację lub pełni funkcję.
Czy WCAG 2.2 zastąpiło WCAG 2.1?
WCAG 2.2 jest nowszą rekomendacją W3C i zawiera kryteria wcześniejszych wersji z określonymi zmianami. Przy nowych projektach warto przyjmować 2.2.
Czy dostępność dotyczy tylko osób niewidomych?
Nie. Obejmuje potrzeby wzrokowe, ruchowe, słuchowe, poznawcze i sytuacyjne oraz różne sposoby obsługi urządzeń.
Źródła i dokumentacja
Dokumentację źródłową sprawdzono 20 lipca 2026 r. Linki prowadzą do materiałów pierwotnych lub oficjalnych instrukcji.
Historia aktualizacji
- publikacja poradnika, weryfikacja źródeł, FAQ i linkowania wewnętrznego.
Zobacz checklisty, zasady redakcyjne i pliki do pobrania używane przy audytach.
Otwórz centrum zasobówhttps://pawlinaltd.pl/blog/wcag-2-2-checklista-strony-firmowej/