WCAG: dostępność strony, czyli jak nie wykluczać użytkowników

Osoba korzystająca z laptopa, ilustracja dostępności strony i wytycznych WCAG

WCAG w 5 minut

WCAG to międzynarodowy standard dostępności stron internetowych, który mówi, jak budować serwis użyteczny dla osób z różnymi niepełnosprawnościami. Skrót pochodzi od Web Content Accessibility Guidelines, a wytyczne tworzy organizacja W3C. Najczęściej wdrażaną wersją jest dziś WCAG 2.1 i nowsza 2.2.

Cała norma opiera się na czterech zasadach: treść ma być postrzegalna, funkcjonalna, zrozumiała i solidna technicznie. Pod nimi kryją się konkretne kryteria, na przykład odpowiedni kontrast, teksty alternatywne do zdjęć, obsługa samą klawiaturą czy poprawne etykiety formularzy.

Zgodność dzieli się na trzy poziomy: A, AA i AAA. W praktyce i prawo, i zdrowy rozsądek celują w poziom AA. Od 28 czerwca 2025 europejski akt o dostępności rozszerzył obowiązek na wiele firm prywatnych, w tym sklepy internetowe, banki czy serwisy z e-bookami. To już nie jest temat wyłącznie dla instytucji publicznych.

Czym jest WCAG i skąd się wziął

WCAG powstał, bo internet domyślnie nie jest dostępny dla wszystkich, a bariery rzadko wynikają ze złej woli. Najczęściej biorą się z tego, że projektant widzi, słyszy i swobodnie używa myszki, więc nawet nie przychodzi mu do głowy, że ktoś tego nie może.

Wytyczne opisują, jak usunąć te bariery w mierzalny sposób. Zamiast ogólnika „strona ma być przyjazna”, dostajesz konkret: kontrast tekstu do tła co najmniej 4,5 do 1, każdy obrazek niosący treść z opisem alternatywnym, cała nawigacja możliwa do obsługi bez myszki.

Dostępność dotyczy większej grupy ludzi, niż się wydaje. Mówimy o osobach niewidomych korzystających z czytników ekranu, słabowidzących powiększających tekst, niesłyszących oglądających wideo bez dźwięku, ale też o kimś ze złamaną ręką albo o seniorze. Szacuje się, że trudności w korzystaniu z sieci dotyczą około jednej na sześć osób.

Cztery zasady WCAG, czyli POUR

Całą filozofię WCAG da się streścić czterema słowami: postrzegalność, funkcjonalność, zrozumiałość i solidność. W oryginale tworzą skrót POUR i to wokół nich zbudowane są wszystkie szczegółowe kryteria.

Zasada Co oznacza Przykład w praktyce
Postrzegalność Treść da się odebrać różnymi zmysłami Opis alternatywny zdjęcia, napisy do filmu, dobry kontrast
Funkcjonalność Wszystko da się obsłużyć różnymi sposobami Pełna obsługa klawiaturą, widoczny fokus, brak pułapek
Zrozumiałość Treść i działanie są przewidywalne Jasny język, czytelne komunikaty błędów, spójna nawigacja
Solidność Kod działa z technologiami wspomagającymi Poprawny HTML, etykiety pól, role i atrybuty ARIA

Te zasady nie są oderwane od reszty pracy nad stroną. Poprawny, semantyczny kod pomaga jednocześnie czytnikowi ekranu i robotowi Google, dlatego dostępność i semantyka w SEO bardzo często idą w parze.

Poziomy zgodności: A, AA i AAA

WCAG ma trzy poziomy zgodności, a docelowym standardem dla większości stron jest poziom AA. Każdy kolejny poziom dokłada wymagania, ale nie zastępuje poprzedniego. Żeby spełnić AA, musisz najpierw spełnić wszystko z poziomu A.

Poziom A to absolutne minimum, bez którego część użytkowników w ogóle nie skorzysta ze strony. Poziom AA to rozsądny, osiągalny standard, którego wymaga prawo i którego oczekują audyty. Poziom AAA bywa bardzo trudny do spełnienia na całym serwisie i traktuje się go raczej jako kierunek niż obowiązek.

W praktyce, gdy ktoś mówi „strona zgodna z WCAG”, niemal zawsze ma na myśli WCAG 2.1 albo 2.2 na poziomie AA. To do tego poziomu warto dążyć od początku, bo dorabianie dostępności po fakcie kosztuje więcej niż wbudowanie jej w projekt.

Dostępność a prawo: co zmienił 2025 rok

Od 28 czerwca 2025 europejski akt o dostępności, czyli EAA, objął obowiązkiem dostępności także wiele firm prywatnych. Wcześniej w Polsce twardy wymóg dotyczył głównie podmiotów publicznych na mocy ustawy o dostępności cyfrowej z 2019 roku.

Teraz krąg się poszerzył. Obowiązek obejmuje między innymi sklepy internetowe, usługi bankowe, transport, e-booki, telekomunikację i platformy handlu elektronicznego. Punktem odniesienia pozostaje WCAG na poziomie AA, opisany w europejskiej normie EN 301 549.

Dla właściciela strony oznacza to prostą rzecz: dostępność przestała być miłym dodatkiem do marketingu. Stała się wymogiem, którego brak może skończyć się skargą, postępowaniem i realnym ryzykiem finansowym. Mikrofirmy mają pewne ulgi, ale i tak warto sprawdzić, czy akurat Twój przypadek na nie pozwala.

Najważniejsze wymagania WCAG w praktyce

Większość punktów WCAG sprowadza się do kilkunastu rzeczy, które realnie decydują o tym, czy ktoś skorzysta z Twojej strony. Nie musisz znać całej normy na pamięć, żeby naprawić to, co najważniejsze.

4,5:1minimalny kontrast tekstu do tła dla zwykłej wielkości czcionki
3:1minimalny kontrast dla dużego tekstu i elementów graficznych
24×24 pxminimalny rozmiar celu dotykowego w WCAG 2.2

Najczęściej powtarzające się wymagania to: opisy alternatywne dla obrazów niosących treść, wystarczający kontrast kolorów, pełna obsługa klawiaturą z widocznym wskaźnikiem fokusu, poprawna struktura nagłówków oraz etykiety przy każdym polu formularza. Do tego dochodzą napisy do materiałów wideo, ustawiony język strony i komunikaty błędów, które tłumaczą, co poszło nie tak.

WCAG 2.2 dorzucił kilka nowych kryteriów, które dobrze oddają ducha standardu. Cel kliknięcia musi mieć rozsądny rozmiar, fokus nie może chować się pod przyklejonym nagłówkiem, a logowanie nie powinno wymagać rozwiązywania łamigłówek pamięciowych. Drobiazgi, które dla części osób decydują o tym, czy w ogóle dokończą zakup.

Pamiętaj o jednej pułapce. Sam kolor nie może być jedynym nośnikiem informacji. Jeśli błąd w formularzu zaznaczasz wyłącznie czerwoną ramką, osoba nierozróżniająca barw go nie zauważy. Dodaj ikonę albo opis. Przy okazji przyda się solidna struktura nagłówków H1, H2, H3, bo to po niej czytnik ekranu porusza się po stronie.

Jak wdrożyć WCAG na stronie WordPress

Na WordPressie sporą część dostępności załatwisz bez programisty, jeśli zaczniesz od dobrego motywu i kilku porządków. Reszta to nawyki przy dodawaniu treści, a nie jednorazowy projekt.

  1. Wybierz dostępny motyw. Szukaj szablonów z etykietą „accessibility-ready”. Mają poprawną strukturę, widoczny fokus i sensowny kontrast już na starcie.
  2. Uporządkuj nagłówki. Jeden H1 na stronę, dalej H2 i H3 w logicznej kolejności. Nie używaj nagłówków tylko po to, żeby coś powiększyć.
  3. Dodawaj opisy alternatywne. Przy każdym zdjęciu niosącym treść uzupełniaj pole tekstu alternatywnego. Element czysto dekoracyjny zostaw z pustym opisem.
  4. Sprawdź kontrast i czcionki. Zweryfikuj kolory tekstu względem tła i upewnij się, że da się powiększyć stronę bez rozsypania układu.
  5. Opisz formularze. Każde pole potrzebuje widocznej etykiety, a komunikat błędu ma mówić, co poprawić, nie tylko że jest źle.
  6. Przetestuj. Przejdź stronę samą klawiaturą, włącz czytnik ekranu i puść audyt w narzędziu, na przykład w Lighthouse.

Istnieją wtyczki wspierające dostępność, ale potraktuj je jak pomoc, nie jak zaklęcie. Nakładka, która obiecuje „pełną zgodność z WCAG jednym kliknięciem”, zwykle nie rozwiązuje realnych problemów, a czasem dokłada nowe. Dostępność robi się w treści i kodzie, nie w widżecie z boku ekranu.

Czym testować dostępność

Dostępność najlepiej sprawdza się dwutorowo: automatem, który wyłapie typowe błędy, i własnymi rękami, które wyłapią resztę. Same narzędzia automatyczne wykrywają tylko część problemów, więc nie zastąpią realnego testu.

Z automatów warto znać Lighthouse wbudowany w przeglądarkę Chrome, rozszerzenie axe DevTools oraz serwis WAVE. Każde z nich pokaże Ci listę problemów: brakujące opisy, słaby kontrast, pola bez etykiet. To dobry punkt startu, bo od razu widać, co naprawić najpierw.

Test ręczny jest niezastąpiony. Odłóż myszkę i spróbuj przejść całą stronę klawiszem Tab. Sprawdź, czy widać, na którym elemencie jesteś, czy da się rozwinąć menu i wysłać formularz. Potem włącz czytnik ekranu, choćby wbudowany w system, i posłuchaj, jak brzmi Twoja strona dla kogoś, kto jej nie widzi. To często otwiera oczy bardziej niż każdy raport.

Dlaczego dostępność opłaca się też w SEO

Strona dostępna i strona dobrze zoptymalizowana pod Google mają zaskakująco dużo wspólnego, bo obie potrzebują czystego, zrozumiałego kodu. Praca nad jednym podnosi drugie niemal za darmo.

Opisy alternatywne pomagają czytnikowi ekranu i jednocześnie podpowiadają wyszukiwarce, co jest na zdjęciu. Poprawna hierarchia nagłówków ułatwia nawigację osobom niewidomym i pomaga Google zrozumieć strukturę treści. Czytelne linki z sensownym tekstem są lepsze dla obu stron niż wszechobecne „kliknij tutaj”.

Do tego dochodzi szybkość i wygoda na telefonie, które liczą się w dostępności i w rankingu tak samo. Jeśli pracujesz nad Core Web Vitals, część tej roboty od razu poprawia komfort osób z niepełnosprawnościami. Dwie pieczenie na jednym ogniu.

Najczęściej zadawane pytania

Co to jest WCAG w prostych słowach?

WCAG to zestaw wytycznych, które opisują, jak zbudować stronę użyteczną dla osób z różnymi niepełnosprawnościami. Dotyczy między innymi kontrastu, opisów zdjęć, obsługi klawiaturą i czytelnych formularzy.

Standard tworzy organizacja W3C, a celem jest to, żeby z internetu mógł korzystać każdy, niezależnie od wzroku, słuchu czy sprawności rąk.

Jaki poziom WCAG jest wymagany?

W większości przypadków wymagany jest poziom AA według WCAG 2.1 lub 2.2. To on stanowi punkt odniesienia w przepisach i w audytach dostępności.

Poziom A to minimum, a AAA jest bardzo trudny do osiągnięcia na całym serwisie. Dlatego praktycznym celem pozostaje AA.

Czy moja firma musi spełniać WCAG?

Od 28 czerwca 2025 obowiązek dostępności objął wiele firm prywatnych w ramach europejskiego aktu o dostępności. Dotyczy między innymi sklepów internetowych, banków i usług cyfrowych.

Wcześniej twardy wymóg ciążył głównie na podmiotach publicznych. Niektóre mikrofirmy mają ulgi, ale warto sprawdzić, czy akurat Twój przypadek się do nich kwalifikuje.

Jak sprawdzić dostępność strony?

Połącz testy automatyczne z ręcznymi. Z automatów użyj Lighthouse, axe DevTools albo WAVE, które wskażą typowe błędy, jak brak opisów czy słaby kontrast.

Potem przejdź stronę samą klawiaturą i posłuchaj jej w czytniku ekranu. Narzędzia wyłapią część problemów, ale resztę zobaczysz dopiero w realnym teście.

Jaki kontrast wymaga WCAG?

Dla zwykłego tekstu WCAG wymaga kontrastu co najmniej 4,5 do 1 względem tła. Dla dużego tekstu oraz elementów graficznych i interfejsu wystarczy 3 do 1.

Kontrast sprawdzisz w darmowych narzędziach, podając kody kolorów tekstu i tła. To jeden z najczęściej oblewanych punktów, więc warto zacząć właśnie od niego.

Czy wtyczka załatwi zgodność z WCAG?

Nie, żadna wtyczka ani nakładka nie zapewni pełnej zgodności z WCAG jednym kliknięciem. Dostępność wynika z treści i kodu, a nie z widżetu doklejonego do strony.

Narzędzia bywają pomocne przy testach i drobnych poprawkach. Realne bariery i tak trzeba usunąć w nagłówkach, opisach, formularzach i kontraście.

Czy dostępność pomaga w pozycjonowaniu?

Tak, praca nad dostępnością zwykle poprawia też SEO, bo obie rzeczy potrzebują czystego, semantycznego kodu. Opisy zdjęć, struktura nagłówków i czytelne linki pomagają i czytnikom ekranu, i Google.

Szybka, wygodna na telefonie strona również służy obu celom naraz. Dlatego dostępności nie warto traktować jak kosztu oderwanego od widoczności.

Picture of Tomasz Zieliński
Tomasz Zieliński

Tomasz zajmuje się tematyką SEO, sztucznej inteligencji i automatyzacji pracy w marketingu internetowym. W swoich artykułach analizuje zmiany w algorytmach wyszukiwarek, rozwój narzędzi AI oraz nowe sposoby tworzenia i optymalizacji treści. Interesuje go przede wszystkim to, jak technologia wpływa na codzienną pracę specjalistów SEO, marketerów i twórców internetowych.

Facebook
Twitter
LinkedIn
Pinterest

Najnowsze Wpisy

Śledź nas