Praktyczne wyjaśnienie standardu WCAG po polsku: co oznacza, co sprawdzić i jak myśleć o dostępności bez żargonu.
Przewodnik praktyczny
WCAG to zestaw zasad, które pomagają tworzyć strony, aplikacje i treści cyfrowe dostępne dla różnych osób. Chodzi między innymi o osoby niewidome, słabowidzące, Głuche, z niepełnosprawnością ruchową, poznawczą albo o osoby korzystające z telefonu, klawiatury, czytnika ekranu, powiększenia lub napisów.
Ten przewodnik nie jest oficjalnym tłumaczeniem standardu. To robocza mapa dla osób, które chcą zrozumieć sens WCAG i szybciej przejść od przepisu do praktycznego działania.
Użytkownik musi móc odebrać informację co najmniej jednym zmysłem. Jeżeli ktoś nie widzi obrazu, potrzebuje tekstu alternatywnego. Jeżeli ktoś nie słyszy filmu, potrzebuje napisów.
Użytkownik musi móc obsłużyć interfejs. Strona ma działać klawiaturą, fokus ma być widoczny, a elementy nie mogą blokować drogi dalej.
Treść i działanie strony mają być przewidywalne. Formularz powinien mówić, czego wymaga, gdzie jest błąd i co zrobić, żeby go poprawić.
Kod powinien być napisany tak, żeby dobrze współpracował z przeglądarkami i technologiami wspomagającymi. Przycisk ma być przyciskiem, a pole formularza ma mieć nazwę.
Poniżej znajdziesz wszystkie kryteria A i AA z WCAG 2.2 opisane prostym językiem. To nie jest oficjalne tłumaczenie standardu, tylko praktyczne wyjaśnienie do nauki, audytu i rozmowy z zespołem.
Jeżeli coś nie jest tekstem, a przekazuje informację, musi mieć tekstową alternatywę.
Co sprawdzić? Alt obrazów, nazwy ikon, przyciski graficzne, wykresy, CAPTCHA i elementy dekoracyjne.
Jeżeli publikujesz samo nagranie audio albo samo wideo bez dźwięku, użytkownik potrzebuje alternatywy w innym formacie.
Co sprawdzić? Transkrypcję dla audio i opis tekstowy albo ścieżkę audio dla samego obrazu.
Nagranie z dźwiękiem musi mieć napisy. To nie jest tylko zapis wypowiedzi. Napisy powinny obejmować też ważne dźwięki, na przykład śmiech, alarm, muzykę albo dźwięk telefonu, jeśli wpływają na zrozumienie treści.
Co sprawdzić? Czy napisy są zsynchronizowane, kompletne i opisują istotne dźwięki, a nie tylko dialog.
Jeżeli ważna informacja jest widoczna tylko w obrazie filmu, osoba niewidoma musi dostać ją w audiodeskrypcji albo w pełnej alternatywie tekstowej.
Co sprawdzić? Czy opisano ważne działania, napisy na ekranie, zmianę miejsca, gesty i inne informacje widoczne w filmie.
Transmisje na żywo z dźwiękiem powinny mieć napisy na żywo, żeby osoby niesłyszące mogły śledzić wydarzenie.
Co sprawdzić? Czy webinar, konferencja albo streaming ma napisy na żywo i czy są czytelne oraz wystarczająco aktualne.
Nagrania wideo powinny mieć audiodeskrypcję, jeżeli bez obrazu nie da się zrozumieć ważnych informacji.
Co sprawdzić? Czy osoba słuchająca filmu bez patrzenia na ekran wie, co się dzieje i co jest pokazywane.
To, co widać jako strukturę, powinno być zapisane w kodzie. Nagłówek ma być nagłówkiem, lista listą, a etykieta pola etykietą.
Co sprawdzić? Nagłówki, listy, tabele, grupy pól, etykiety, komunikaty i relacje między elementami.
Jeżeli kolejność treści ma znaczenie, powinna być logiczna także w kodzie i przy odczycie przez technologie wspomagające.
Co sprawdzić? Kolejność DOM, odczyt czytnikiem ekranu, formularze, karty, układy wielokolumnowe i komponenty po zmianie CSS.
Instrukcja nie może zależeć wyłącznie od koloru, kształtu, położenia, dźwięku albo wielkości.
Co sprawdzić? Polecenia typu „kliknij zielony przycisk”, „wybierz element po prawej” albo „po usłyszeniu sygnału”.
Strona lub aplikacja nie powinna wymuszać pionowego albo poziomego ułożenia ekranu, jeśli nie jest to konieczne.
Co sprawdzić? Widok na telefonie i tablecie po obróceniu urządzenia.
Pola zbierające dane osobowe powinny mieć określony cel, żeby przeglądarka i technologie wspomagające mogły pomagać użytkownikowi.
Co sprawdzić? Atrybuty autocomplete przy polach takich jak imię, e-mail, telefon, adres i kod pocztowy.
Kolor nie może być jedynym sposobem przekazania informacji.
Co sprawdzić? Błędy formularza, statusy, wykresy, linki w tekście i oznaczenia aktywnych elementów.
Jeżeli dźwięk startuje automatycznie i trwa dłużej niż 3 sekundy, użytkownik musi móc go zatrzymać albo wyciszyć.
Co sprawdzić? Autoodtwarzanie audio, wideo z dźwiękiem, reklamy, tła muzyczne i komunikaty głosowe.
Tekst musi mieć wystarczający kontrast względem tła, żeby był czytelny dla osób słabowidzących.
Co sprawdzić? Tekst zwykły, tekst duży, linki, przyciski, placeholdery i tekst na zdjęciach lub gradientach.
Użytkownik może powiększyć tekst do 200%, a treść nadal powinna być dostępna i czytelna.
Co sprawdzić? Powiększenie w przeglądarce, ucinanie tekstu, nachodzenie elementów i znikające funkcje.
Tekst powinien być prawdziwym tekstem, a nie obrazkiem, chyba że jest to konieczne.
Co sprawdzić? Banery, grafiki promocyjne, przyciski, infografiki i zrzuty ekranu z tekstem.
Po powiększeniu albo na wąskim ekranie użytkownik nie powinien przewijać zwykłej treści w dwóch kierunkach.
Co sprawdzić? Widok 320 px szerokości, zoom 200%, menu, tabele, formularze i karty.
Ważne elementy interfejsu i grafiki informacyjne muszą być widoczne także bez idealnego wzroku.
Co sprawdzić? Obramowania pól, fokus, ikony, checkboxy, radio buttony, wykresy i stany elementów.
Użytkownik może zwiększyć odstępy w tekście, a treść nadal nie powinna się rozsypać.
Co sprawdzić? Wysokość linii, odstępy akapitów, odstępy liter i wyrazów przy nadpisaniu CSS.
Dymki, podpowiedzi i rozwijane treści muszą dać się zobaczyć, utrzymać i zamknąć bez pułapek.
Co sprawdzić? Tooltipy, menu, podpowiedzi formularzy i treści pojawiające się po hoverze lub fokusie.
Wszystko, co da się zrobić myszą, powinno dać się zrobić klawiaturą.
Co sprawdzić? Tab, Shift+Tab, Enter, Spacja, strzałki i Escape w menu, formularzach, modalach i komponentach.
Użytkownik nie może utknąć fokusem w żadnym miejscu strony.
Co sprawdzić? Czy da się wejść i wyjść z menu, okien, odtwarzaczy, kalendarzy i osadzonych widżetów.
Skrót uruchamiany jednym znakiem może przeszkadzać osobom używającym mowy, klawiatur alternatywnych albo przypadkowych naciśnięć.
Co sprawdzić? Czy skrót można wyłączyć, zmienić albo uruchamiać tylko po fokusie na konkretnym elemencie.
Jeżeli użytkownik ma limit czasu, powinien móc go wyłączyć, wydłużyć albo dostać ostrzeżenie.
Co sprawdzić? Sesje, testy, koszyki, formularze, rezerwacje i automatyczne wylogowanie.
Ruchome, migające lub automatycznie aktualizowane treści nie mogą odbierać kontroli użytkownikowi.
Co sprawdzić? Slajdery, karuzele, animacje, paski wiadomości, liczniki i automatyczne odświeżanie.
Treści nie powinny błyskać w sposób, który może wywołać napad fotogenny.
Co sprawdzić? Animacje, reklamy, efekty świetlne, wideo i gry.
Użytkownik powinien móc ominąć powtarzające się elementy, na przykład menu, i przejść do głównej treści.
Co sprawdzić? Skip-link, punkty orientacyjne, strukturę nagłówków i kolejność fokusu.
Każda strona powinna mieć tytuł, który mówi, gdzie użytkownik jest.
Co sprawdzić? Element title, unikalność tytułów i sens tytułu po otwarciu wielu kart.
Fokus powinien przechodzić przez stronę w kolejności, która jest logiczna i przewidywalna.
Co sprawdzić? Kolejność tabulacji, modale, menu, formularze, sticky header i elementy ukrywane CSS-em.
Użytkownik powinien rozumieć, dokąd prowadzi link, z samego tekstu linku albo z jego najbliższego kontekstu.
Co sprawdzić? Linki „więcej”, „tutaj”, „czytaj dalej”, ikony-linki i powtarzalne linki w kartach.
Do strony w serwisie powinno dać się dojść więcej niż jedną drogą.
Co sprawdzić? Menu, wyszukiwarkę, mapę strony, listy kategorii, linki wewnętrzne i stopkę.
Nagłówki i etykiety powinny jasno opisywać treść albo funkcję.
Co sprawdzić? H1-H6, label formularzy, nazwy sekcji, przyciski i powtarzalne komponenty.
Osoba korzystająca z klawiatury musi widzieć, który element jest aktualnie aktywny.
Co sprawdzić? Linki, przyciski, pola, checkboxy, menu, karty, skip-link i elementy niestandardowe.
Element z fokusem nie może być całkowicie zasłonięty przez sticky header, baner, modal albo pasek cookie.
Co sprawdzić? Przechodzenie klawiaturą po stronie, zwłaszcza przy przyklejonym menu i automatycznym przewijaniu do fokusu.
Funkcja obsługiwana gestem złożonym powinna mieć prostszą alternatywę.
Co sprawdzić? Przeciąganie, szczypanie, rysowanie ścieżki i gesty wielopunktowe.
Użytkownik powinien mieć szansę uniknąć przypadkowego uruchomienia akcji po dotknięciu albo kliknięciu.
Co sprawdzić? Czy akcja uruchamia się dopiero po puszczeniu przycisku, albo czy da się ją anulować lub cofnąć.
Widoczny tekst elementu powinien być częścią jego nazwy dostępnej.
Co sprawdzić? Przyciski i linki z aria-label, ikonami, skróconymi nazwami albo tekstem ukrytym.
Funkcja uruchamiana ruchem urządzenia albo gestem użytkownika musi mieć alternatywę i możliwość wyłączenia.
Co sprawdzić? Potrząsanie telefonem, obracanie, machanie i inne akcje zależne od ruchu.
Jeżeli coś wymaga przeciągania, powinno dać się wykonać prostszym kliknięciem, dotknięciem albo kontrolką.
Co sprawdzić? Suwaki, sortowanie kart, przeciąganie plików, mapy i elementy typu drag and drop.
Elementy klikalne powinny być wystarczająco duże albo mieć wystarczająco dużo wolnej przestrzeni wokół.
Co sprawdzić? Małe ikony, linki obok siebie, przyciski w tabelach, kontrolki mobilne i elementy w nagłówku.
Strona powinna informować technologie, w jakim języku jest napisana.
Co sprawdzić? Atrybut lang w html i zgodność języka z realną treścią strony.
Fragment w innym języku powinien być oznaczony, żeby czytnik ekranu poprawnie go wymówił.
Co sprawdzić? Cytaty, nazwy, dłuższe fragmenty po angielsku i przełączniki językowe.
Samo wejście fokusem na element nie powinno nagle zmieniać kontekstu.
Co sprawdzić? Czy fokus nie wysyła formularza, nie otwiera nowej strony, nie zmienia widoku bez decyzji użytkownika.
Zmiana wartości pola nie powinna zaskakiwać użytkownika zmianą strony, chyba że został o tym uprzedzony.
Co sprawdzić? Selecty, checkboxy, filtry, formularze wieloetapowe i automatyczne przekierowania.
Powtarzające się menu i nawigacja powinny działać w tej samej kolejności na różnych stronach.
Co sprawdzić? Header, stopkę, menu boczne, kolejność linków i wersje mobilne.
Ta sama funkcja powinna być nazywana i oznaczana tak samo w całym serwisie.
Co sprawdzić? Przyciski, ikony, etykiety, komunikaty, linki do tych samych działań i komponenty powtarzalne.
Jeżeli serwis ma pomoc kontaktową, powinna być dostępna w przewidywalnym miejscu.
Co sprawdzić? Link kontaktowy, formularz pomocy, czat, dane telefonu i sekcję pomocy na różnych stronach.
Jeżeli użytkownik popełni błąd, strona musi jasno wskazać, gdzie jest problem.
Co sprawdzić? Puste pola wymagane, błędny e-mail, za krótki tekst, format telefonu i błędy po wysłaniu formularza.
Użytkownik powinien wiedzieć, co wpisać, w jakim formacie i które pola są wymagane.
Co sprawdzić? Label, legend, opis pola, instrukcje, oznaczenie wymaganych pól i przykłady formatów.
Jeżeli da się podpowiedzieć poprawkę błędu, formularz powinien to zrobić.
Co sprawdzić? Komunikaty typu „wpisz adres e-mail w formacie nazwa@example.com” zamiast samego „błąd”.
Przy ważnych danych, decyzjach prawnych albo finansowych użytkownik powinien móc sprawdzić, poprawić albo potwierdzić działanie.
Co sprawdzić? Zamówienia, płatności, deklaracje, dane urzędowe, usuwanie konta i operacje nieodwracalne.
Użytkownik nie powinien przepisywać tych samych informacji w tym samym procesie, jeśli system już je zna.
Co sprawdzić? Formularze wieloetapowe, dane kontaktowe, adresy, logowanie i pola powtarzane po błędzie.
Logowanie nie powinno wymagać zadania poznawczego, którego użytkownik nie może wykonać, na przykład zapamiętywania hasła bez wsparcia.
Co sprawdzić? Możliwość wklejenia hasła, menedżery haseł, alternatywy dla CAPTCHA i logowanie bez łamigłówek.
Element interaktywny musi mówić technologiom wspomagającym, jak się nazywa, czym jest i jaki ma stan.
Co sprawdzić? Przyciski, linki, pola, listy rozwijane, przełączniki, zakładki, modale i komponenty niestandardowe.
Ważne komunikaty po akcji powinny być przekazane czytnikowi ekranu bez przenoszenia fokusu.
Co sprawdzić? Komunikaty „dodano do koszyka”, wyniki filtrowania, błędy, sukcesy, liczniki i status wysyłki formularza.
W WCAG 2.2 kryterium 4.1.1 Parsowanie zostało usunięte. Nadal warto pisać poprawny HTML, ale w audytach WCAG 2.2 nie traktujemy 4.1.1 jako aktywnego kryterium sukcesu.
