Web Content Accessibility Guidelines (WCAG) to międzynarodowy standard dostępnych treści internetowych publikowany przez Web Accessibility Initiative (WAI) działającą w ramach W3C. Aktualna wersja, WCAG 2.2, uzyskała status oficjalnej rekomendacji W3C 5 października 2023 roku. Zawiera 86 sprawdzalnych kryteriów sukcesu uporządkowanych w ramach 4 zasad i 13 wytycznych, a każde kryterium przypisano do jednego z trzech poziomów zgodności: A, AA lub AAA. W praktyce liczy się poziom AA, bo to do niego przepisy na całym świecie przywiązują swoje wymagania. W UE zharmonizowana norma EN 301 549 odwołuje się do WCAG 2.1 na poziomie AA, co czyni go technicznym punktem odniesienia dla European Accessibility Act i niemieckiej ustawy BFSG. WCAG 2.2 dokłada do wersji 2.1 dziewięć nowych kryteriów sukcesu, dotyczących między innymi minimalnych rozmiarów celów, widocznego fokusu klawiatury i logowania bez zagadek poznawczych, a jednocześnie usuwa przestarzałe kryterium parsowania 4.1.1.
Kto publikuje Web Content Accessibility Guidelines?
WCAG pochodzi od World Wide Web Consortium (W3C), tej samej organizacji, która standaryzuje HTML i CSS, a konkretnie od jej inicjatywy Web Accessibility Initiative. Wytyczne mają długą historię: WCAG 1.0 pojawiło się w 1999 roku, WCAG 2.0 w 2008 i przez całą dekadę pozostawało punktem odniesienia, WCAG 2.1 wyszło w 2018 roku ze szczególnym uwzględnieniem urządzeń mobilnych i osób słabowidzących, a WCAG 2.2 opublikowano w październiku 2023 roku.
Wersje z rodziny 2.x są z założenia wstecznie kompatybilne. Strona zgodna z WCAG 2.2 AA jest zgodna także z 2.1 AA i 2.0 AA. To istotne, bo przepisy zwykle pozostają w tyle za najnowszą wersją, a budowanie pod kątem 2.2 zabezpiecza Cię na obu frontach.
Cztery zasady WCAG: postrzegalność, funkcjonalność, zrozumiałość, solidność
Każde kryterium sukcesu wisi przy jednej z czterech zasad, zapamiętywanych jako akronim POUR:
- Perceivable, postrzegalność: użytkownicy muszą móc odebrać treść. Przykłady: tekstowe alternatywy dla obrazów, napisy do filmów, wystarczający kontrast kolorów.
- Operable, funkcjonalność: użytkownicy muszą móc obsłużyć interfejs. Przykłady: wszystko działa z klawiatury, użytkownik dostaje dość czasu, nic nie miga w sposób grożący napadem padaczki, a cele kliknięcia są dość duże, by w nie trafić.
- Understandable, zrozumiałość: treść i obsługa muszą być zrozumiałe. Przykłady: czytelny język, przewidywalna nawigacja, pomocne komunikaty o błędach w formularzach.
- Robust, solidność: treść musi niezawodnie działać z obecnymi i przyszłymi programami użytkownika, w tym z czytnikami ekranu. Przykład: komunikaty o statusie, które technologia asystująca potrafi odczytać.
Zasady są celowo niezależne od technologii. Dotyczą bloga na WordPressie tak samo jak aplikacji w React czy pliku PDF.
Porównanie poziomów zgodności WCAG A, AA i AAA
| Poziom | Kryteria w WCAG 2.2 | Znaczenie | Typowe przykłady |
|---|---|---|---|
| A | 31 | Absolutne minimum. Ich niespełnienie odcina całe grupy użytkowników. | Tekst alternatywny obrazów, obsługa z klawiatury, brak pułapek klawiaturowych |
| AA | 24 | Standardowy cel, przywoływany przez przepisy na całym świecie. | Kontrast 4,5:1, widoczny fokus, spójna nawigacja, podpowiedzi przy błędach |
| AAA | 31 | Najwyższy poziom, dla większości witryn aspiracyjny. | Kontrast 7:1, język migowy do filmów, wymagania dotyczące poziomu czytelności |
Zgodność jest kumulatywna: AA oznacza, że spełniasz wszystkie kryteria poziomu A i wszystkie poziomu AA. Samo W3C stwierdza, że pełnej zgodności AAA nie należy wymagać jako ogólnej polityki, bo części kryteriów AAA po prostu nie da się spełnić dla każdego rodzaju treści. Nikt nie oczekuje tłumaczenia na język migowy na stronie piekarni. Pojedyncze kryteria AAA i tak warto wdrażać tam, gdzie pasują, a szczególnie popularny jest podwyższony współczynnik kontrastu.
Ile kryteriów sukcesu ma WCAG 2.2?
WCAG 2.2 zawiera 86 kryteriów sukcesu: 31 na poziomie A, 24 na poziomie AA i 31 na poziomie AAA. Dla porównania WCAG 2.1 miało ich 78. Rachunek się zgadza, bo wersja 2.2 dodaje dziewięć nowych kryteriów i usuwa jedno: 4.1.1 Parsing, relikt czasów, gdy zepsuty kod HTML potrafił naprawdę wywrócić czytnik ekranu. Nowoczesne przeglądarki i technologie asystujące parsują HTML tak samo, więc kryterium stało się zbędne.
Co nowego w WCAG 2.2? Dziewięć nowych kryteriów sukcesu
Uzupełnienia w wersji 2.2 skupiają się na użytkownikach z ograniczeniami motorycznymi i poznawczymi, a szczerze mówiąc, większość z nich to po prostu dobry UX:
- 2.4.11 Focus Not Obscured (Minimum), AA: element z fokusem nie może być całkowicie zasłonięty przez przyklejone nagłówki, banery cookie czy widżety czatu.
- 2.4.12 Focus Not Obscured (Enhanced), AAA: element z fokusem nie może być zasłonięty w ogóle, nawet częściowo.
- 2.4.13 Focus Appearance, AAA: wskaźnik fokusu musi spełniać minimalne wymagania co do rozmiaru i kontrastu.
- 2.5.7 Dragging Movements, AA: wszystko, co działa przez przeciąganie, potrzebuje alternatywy obsługiwanej prostymi kliknięciami lub dotknięciami.
- 2.5.8 Target Size (Minimum), AA: cele kliknięcia i dotknięcia muszą mieć co najmniej 24 na 24 piksele CSS albo dość odstępu wokół siebie.
- 3.2.6 Consistent Help, A: opcje pomocy, takie jak linki kontaktowe czy czat, muszą pojawiać się w tym samym miejscu na każdej podstronie.
- 3.3.7 Redundant Entry, A: nie zmuszaj użytkownika do wpisywania tych samych informacji dwa razy w ramach jednego procesu. Adres dostawy taki sam jak rozliczeniowy powinien być polem wyboru, a nie drugim formularzem.
- 3.3.8 Accessible Authentication (Minimum), AA: logowanie nie może zależeć od zagadki poznawczej. Przepisywanie zniekształconych znaków czy rozwiązywanie gier pamięciowych odpada, a menedżery haseł i wklejanie muszą działać.
- 3.3.9 Accessible Authentication (Enhanced), AAA: ta sama zasada bez wyjątków, które dopuszcza jeszcze 3.3.8.
Jaki poziom WCAG jest wymagany przez prawo?
W UE zharmonizowana norma EN 301 549 definiuje wymagania techniczne zarówno dla przepisów sektora publicznego, jak i dla European Accessibility Act, a obecnie odwołuje się do WCAG 2.1 na poziomie AA. To czyni 2.1 AA formalnym prawnym punktem odniesienia dla niemieckiej ustawy BFSG i BITV 2.0. Spodziewana jest aktualizacja EN 301 549 do WCAG 2.2 i właśnie dlatego budowanie już dziś pod kątem 2.2 jest wyborem pragmatycznym: spełniasz jednocześnie obecny wymóg i ten prawdopodobny przyszły.
Gdzie indziej obraz wygląda podobnie. W Stanach Zjednoczonych Departament Sprawiedliwości sfinalizował w 2024 roku przepis wymagający od władz stanowych i lokalnych spełniania WCAG 2.1 AA w ramach ADA Title II, a sądy rutynowo posługują się WCAG jako punktem odniesienia w prywatnych pozwach opartych na ADA. Jeśli masz zapamiętać z tego rozdziału jedną rzecz, niech będzie to ta: gdy prawo mówi dostępny, ma na myśli poziom WCAG AA.
Jak kryteria sukcesu WCAG wyglądają w praktyce?
Trzy przykłady pokazują, jak konkretne potrafią być te kryteria. Kryterium 1.4.3 Contrast (Minimum) wymaga współczynnika kontrastu co najmniej 4,5:1 między zwykłym tekstem a tłem i 3:1 dla dużego tekstu. Ten szary tekst w stopce, #999999 na #ffffff? Nie przechodzi, ma 2,85:1. Kryterium 2.1.1 Keyboard wymaga, aby cała funkcjonalność działała bez myszki, i właśnie na tym po cichu wykładają się autorskie listy rozwijane oraz slidery obrazów. A kryterium 1.1.1 Non-text Content to klasyczna zasada tekstu alternatywnego:
<!-- Obraz informacyjny: opisz, co przedstawia -->
<img src="warehouse.jpg" alt="Pracownik skanujący paczki w magazynie">
<!-- Obraz dekoracyjny: puste alt, aby czytniki ekranu go pominęły -->
<img src="divider.svg" alt="">Każde kryterium w oficjalnym dokumencie odsyła do technik i przykładów niepowodzeń, a szybki przewodnik po WCAG pozwala filtrować wszystkie 86 kryteriów według poziomu i technologii, co jest znacznie wygodniejsze niż czytanie specyfikacji od deski do deski.
Jak przetestować zgodność z WCAG 2.2?
Zacznij od narzędzi automatycznych: WAVE, axe DevTools, Lighthouse albo wbudowane testy dostępności w InspectWP w kilka sekund wychwycą brakujące atrybuty alt, problemy z kontrastem, brakujące etykiety i błędy strukturalne. Pamiętaj jednak o ograniczeniach. Testy automatyczne wykrywają w sposób pewny gdzieś od jednej trzeciej do połowy naruszeń WCAG, bo wiele kryteriów wymaga ludzkiej oceny. Maszyna zobaczy, że obraz ma tekst alternatywny, ale nie oceni, czy ten tekst faktycznie go opisuje.
Uzupełnij więc obraz ręcznie: odłącz myszkę i przejdź całą witrynę klawiaturą, przeprowadź sesję z czytnikiem ekranu NVDA (darmowy) lub VoiceOver, powiększ stronę do 200 procent i przejdź od początku do końca najważniejszą ścieżkę użytkownika, zwykle zamówienie albo kontakt. Jeśli możesz, włącz w testy osoby z niepełnosprawnościami. W dziesięć minut znajdą problemy, których nie ujawni żadna lista kontrolna z audytu.
Co po WCAG 2.2? Krótko o WCAG 3.0
W3C pracuje nad WCAG 3.0, napisanym od zera standardem z nowym modelem oceny, który odchodzi od binarnej logiki zaliczone albo niezaliczone. Jest w fazie szkicu od lat i szkicem pozostanie jeszcze przez kolejne, a W3C wprost mówi, że przez długi czas nie zastąpi wersji 2.2. Dla planowania oznacza to jedno: celem jest WCAG 2.2 AA, a wersja 3.0 nie powinna dziś zmieniać Twoich planów.
Jak InspectWP sprawdza kryteria WCAG?
InspectWP zawiera automatyczne testy dostępności w raportach z analizy witryny i przypisuje typowe naruszenia do stojących za nimi kryteriów WCAG: brakujące teksty alternatywne, niewystarczający kontrast kolorów, pola formularzy bez etykiet, brak języka dokumentu czy zaburzona hierarchia nagłówków. Każde znalezisko ma ocenę wagi, więc najpierw naprawisz blokery poziomu A, a potem będziesz piął się w stronę AA. W połączeniu z zaplanowanymi raportami zamienia to dostępność z jednorazowego audytu w coś, co faktycznie masz pod kontrolą, a tego właśnie oczekuje od Ciebie European Accessibility Act.