WCAG nie musi być przytłaczające. Podstawowe usprawnienia — kontrast, skip-linki, nagłówki, opisy alternatywne — da się wdrożyć w kilka dni. Konkretny plan od audytora dostępności.
WCAG nie musi być przytłaczające
Pełna specyfikacja WCAG 2.2 to 86 kryteriów sukcesu rozłożonych na trzy poziomy (A, AA, AAA). Dla kogoś, kto widzi ją po raz pierwszy, wygląda jak mur. Ale podstawowe usprawnienia — te, które eliminują największe bariery — da się wdrożyć w kilka dni, nawet w istniejącej aplikacji. Nie trzeba przebudowywać całego serwisu, żeby znacząco poprawić doświadczenie osób z niepełnosprawnościami. Trzeba wiedzieć, od czego zacząć.
Ten artykuł to lista konkretnych usprawnień, które wdrażamy u klientów w ramach audytów WCAG — uporządkowanych od najprostszych do bardziej złożonych.
Kogo dotyczy dostępność cyfrowa
Zanim przejdziemy do technikaliów — warto powiedzieć wprost, że WCAG nie dotyczy wyłącznie osób z trwałą niepełnosprawnością. Dostępność obejmuje znacznie szerszy kontekst:
- Osoby z zaburzeniami wzroku (niedowidzenie, daltonizm, zaćma, jaskra).
- Osoby z zaburzeniami słuchu (niedosłyszący, głusi).
- Osoby z ograniczeniami ruchowymi (nieprecyzyjne ruchy, brak możliwości użycia myszy, obsługa jedną ręką).
- Osoby z trudnościami poznawczymi (dysleksja, ADHD, zaburzenia koncentracji).
- Osoby w tymczasowej sytuacji — złamana ręka, brak okularów, jasne słońce na ekranie, praca w hałasie.
- Osoby korzystające ze starszego sprzętu, wolnego połączenia, nietypowej przeglądarki.
Ustawa o dostępności cyfrowej z 4 kwietnia 2019 roku wymaga od podmiotów publicznych spełnienia WCAG 2.1 na poziomie AA. Europejski Akt o Dostępności (dyrektywa 2019/882) rozszerza te wymagania na sektor prywatny od 2025 roku. Nawet jeśli Twoja firma nie podlega jeszcze tym regulacjom, klienci i partnerzy publiczni coraz częściej stawiają zgodność WCAG jako warunek współpracy.
Kontrast — pierwszy i najłatwiejszy krok
Zbyt niski kontrast to najczęstszy problem, jaki spotykamy w audytach. Modny jasnoszary tekst na białym tle wygląda elegancko w Figmie, ale na monitorze biurowym w jasnym pokoju staje się nieczytelny.
| Element / Poziom WCAG | AA | AAA |
|---|---|---|
| Standardowy tekst | 4,5:1 | 7:1 |
| Duży tekst | 4,5:1 | 3:1 |
| Elementy sterujące | 3:1 | — |
Sprawdzenie kontrastu trwa dosłownie 30 sekund — wystarczy narzędzie online takie jak WebAIM Contrast Checker. Poprawka to zmiana jednego koloru w CSS. Stosunek wysiłku do efektu jest tu najlepszy ze wszystkich usprawnień.
Tryb wysokiego kontrastu
Dla osób słabowidzących standardowe kontrasty na poziomie AAA mogą nadal nie wystarczać. Tryb hi-contrast to osobna warstwa interfejsu, która:
- Stosuje maksymalnie kontrastowe barwy (np. biały lub żółty na czarnym).
- Redukuje animacje i efekty graficzne, które rozpraszają uwagę.
- Usuwa ozdobniki, gradienty i cienie — zostaje sama treść i nawigacja.
Po stronie CSS reagujemy na preferencje użytkownika za pomocą @media (prefers-contrast: more) i @media (forced-colors: active). Więcej o trybach wyświetlania pisaliśmy w artykule o Light Mode, Dark Mode, Sepia i Hi-Contrast.
Nawigacja — żeby użytkownik się nie zgubił
Nawigacja w kontekście dostępności to nie tylko menu. To cały zestaw mechanizmów, które pomagają użytkownikowi zorientować się, gdzie jest i dokąd może pójść:
- Skip-link — ukryty link „Przejdź do treści" na początku strony, widoczny po naciśnięciu Tab. Pozwala pominąć powtarzalną nawigację i od razu dotrzeć do treści. WCAG wymaga tego wprost (kryterium 2.4.1).
- Czytelna struktura nagłówków — H1 raz, H2 dla sekcji, H3 dla podsekcji. Czytnik ekranu pozwala przechodzić po nagłówkach, więc logiczna hierarchia to spis treści dla niewidomego użytkownika.
- Mapa witryny — osobna strona z listą wszystkich sekcji. Przydatna dla użytkowników, którzy wolą przeszukać strukturę niż nawigować po menu.
- Breadcrumbs — ścieżka nawigacyjna informująca o położeniu w hierarchii strony.
- Wyszukiwarka — z obsługą klawiaturową i czytelnym wynikiem. Dla wielu użytkowników szybsze niż przechodzenie przez menu.
Opisy alternatywne obrazów i mediów
Zdjęcia, schematy, diagramy, infografiki — każdy element wizualny powinien mieć opis alternatywny. W HTML to kilka atrybutów i znaczników:
alt— krótki opis treści obrazu (nie „zdjęcie", nie „obrazek", ale co jest na zdjęciu i dlaczego jest tu umieszczone).title— opcjonalny dymek z dodatkową informacją (nie zastępuje alt).<figure>+<figcaption>— semantyczne opakowanie dla obrazu z podpisem, rozpoznawane przez czytniki ekranu.<picture>— element pozwalający serwować różne wersje obrazu, z zachowaniem jednego alt.
Przy materiałach wideo konieczne są napisy (kryterium WCAG 1.2.2) i transkrypcja audio. Automatyczne napisy z YouTube czy Teams to dobry punkt wyjścia, ale język polski wymaga ręcznej korekty — nazwy własne i terminy branżowe są regularnie przekręcane.
Responsywność i dostępność niezależna od urządzenia
WCAG nie mówi wprost o RWD, ale kilka kryteriów pośrednio tego wymaga — np. kryterium 1.4.10 (Reflow) nakazuje, żeby treść była czytelna bez poziomego przewijania przy szerokości 320 CSS px. W praktyce oznacza to responsywny layout.
Z naszego doświadczenia: aplikacje testowane tylko na desktopie często mają na mobile zbyt małe przyciski, nachodzące na siebie elementy i formularze, w których label odjeżdża poza widoczny obszar. Testowanie na prawdziwym telefonie z włączonym powiększeniem tekstu (zwykle 200%) ujawnia te problemy szybciej niż symulator w przeglądarce.
Pułapki, których warto unikać
- „Wtyczka i gotowe" — nakładki dostępności (accessibility overlays) to rozwiązania, które obiecują zgodność WCAG jednym tagiem JavaScript. W praktyce nie naprawiają struktury HTML, nie dodają brakujących atrybutów ARIA i często wchodzą w konflikt z natywnymi czytnikami ekranu. Europejska organizacja osób niewidomych (EBU) i wiele organizacji zajmujących się dostępnością publicznie je krytykują.
- „Wyłączenie CSS-ów" — oferowanie osobnej, uproszczonej wersji strony bez stylów to traktowanie użytkowników z niepełnosprawnościami jak obywateli drugiej kategorii. WCAG mówi o jednej wersji, dostępnej dla wszystkich.
- „Usunięcie treści" — okrajanie zawartości strony, żeby uniknąć kosztów jej dostosowania. Efekt: użytkownicy z niepełnosprawnościami dostają mniej informacji. To zaprzeczenie idei dostępności.
Od czego zacząć — plan na pierwszy tydzień
- Zmierz kontrasty na głównych stronach. Poprawa: 1–2 godziny pracy w CSS.
- Dodaj skip-link na początku każdej strony. Poprawa: 30 minut.
- Sprawdź hierarchię nagłówków — H1 raz, H2/H3 w logicznej kolejności. Poprawa: godzina.
- Uzupełnij alt w obrazach — skup się na kluczowych stronach (strona główna, oferta, formularze). Poprawa: 1–3 godziny.
- Przetestuj klawiaturą — przejdź przez główne ścieżki użytkownika samym Tabem. Wyłącz mysz na 10 minut.
- Uruchom audytor — Lighthouse (zakładka Accessibility), axe DevTools lub WAVE. Automatyczne narzędzia wykrywają ok. 30–40% problemów, ale to najszybszy sposób na znalezienie nisko wiszących owoców.
Dostępność cyfrowa to proces, nie jednorazowa poprawka. Ale te sześć kroków da widoczną poprawę w ciągu tygodnia. Jeśli chcesz iść dalej — pełny audyt WCAG obejmuje testowanie z czytnikami ekranu, nawigację klawiaturą, responsywność, multimedia i zgodność z ustawą. Porozmawiajmy o tym, czego potrzebuje Twój projekt.
Źródła
- W3C WCAG 2.2 — pełna specyfikacja wytycznych dotyczących dostępności treści internetowych.
- Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej — tekst ustawy w bazie ISAP.
- WebAIM Contrast Checker — narzędzie online do sprawdzania kontrastu tekstu i tła.
- W3C — How to Meet WCAG (Quick Reference) — interaktywny przewodnik po kryteriach WCAG z możliwością filtrowania.
- axe DevTools (Deque) — rozszerzenie przeglądarki do automatycznego testowania dostępności.
LinkedIn/desi9n-pl 
FB/desi9npl 
@desi9n.pl