Dostępność cyfrowa według WCAG 2.1: poziomy, prawo i testy

WCAG 2.1 to międzynarodowe wytyczne, które opisują, jak zbudować stronę, z której skorzystają także osoby niewidome, słabowidzące, głuche, z ograniczeniami ruchowymi czy poznawczymi. W Polsce poziom AA tych wytycznych jest punktem odniesienia dla podmiotów publicznych, a od połowy 2025 roku dostępność dotyczy też wielu firm sprzedających online. Poniżej wyjaśniam, co dokładnie oznacza zgodność z WCAG 2.1, czym różni się poziom AA od AAA, której wersji wytycznych się trzymać i jak samodzielnie sprawdzić swoją stronę, zanim zrobi to klient albo urząd.

TL;DR

• WCAG 2.1 ma trzy poziomy zgodności: A (minimum), AA (standard wymagany w praktyce) i AAA (najwyższy, rzadko osiągalny dla całego serwisu).
• Od 28 czerwca 2025 roku Polski Akt o Dostępności obejmuje m.in. sklepy internetowe i usługi bankowe. Wyłączeni są tylko mikroprzedsiębiorcy.
• W3C zaleca dziś wersję WCAG 2.2. Strona zgodna z 2.2 spełnia automatycznie wymagania 2.1 i 2.0.
• Celuj w poziom AA. AAA traktuj jako bonus dla wybranych treści, a nie politykę dla całej witryny.
• Testy dostępności to trzy etapy: narzędzia automatyczne, sprawdzenie ręczne i testy z użytkownikami. Sam automat nie wystarczy.

Czym jest WCAG 2.1 i dla kogo powstało

WCAG (Web Content Accessibility Guidelines) to standard opracowany przez W3C, organizację, która tworzy podstawowe specyfikacje sieci. Wersja 2.0 ukazała się 11 grudnia 2008 roku, a WCAG 2.1 opublikowano 5 czerwca 2018 roku. Wersja 2.1 nie zastąpiła poprzedniczki, tylko ją rozszerzyła o nowe kryteria, przede wszystkim z myślą o osobach słabowidzących, użytkownikach urządzeń mobilnych i osobach z trudnościami poznawczymi.

Od marca 2021 roku mamy oficjalne polskie tłumaczenie WCAG 2.1, co mocno ułatwia pracę zespołom i urzędom, które wcześniej musiały opierać się na angielskim oryginale.

Cały standard opiera się na czterech zasadach. Dobrze je znać, bo każde kryterium sukcesu da się do jednej z nich przypisać:

1. Postrzegalność. Informacje muszą dotrzeć do użytkownika przynajmniej jednym zmysłem: obrazek ma tekst alternatywny, wideo ma napisy, tekst ma wystarczający kontrast.
2. Funkcjonalność. Wszystko da się obsłużyć klawiaturą, użytkownik ma czas na przeczytanie treści, nic nie miga w sposób mogący wywołać napad padaczki.
3. Zrozumiałość. Formularze mówią, czego oczekują, błędy są opisane, nawigacja zachowuje się przewidywalnie.
4. Solidność. Kod jest na tyle poprawny, że odczytają go przeglądarki i technologie wspomagające, np. czytniki ekranu.

Warto pamiętać, że dostępność to nie tylko kod. Wytyczne dla koordynatorów dostępności przypominają, że obejmuje ona również prosty język i dostępne dokumenty elektroniczne, np. pliki PDF z cennikiem czy regulaminem, które publikujesz na stronie.

Czy WCAG 2.1 jest w Polsce obowiązkowe

Same wytyczne WCAG nie są ustawą. To dokument techniczny, który staje się obowiązkowy dopiero wtedy, gdy powołuje się na niego prawo. W Polsce dzieje się to na dwóch torach.

Podmioty publiczne

Urzędy, szkoły, uczelnie, szpitale publiczne i inne instytucje podlegają Ustawie z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Wymagania techniczne wynikają z załącznika do ustawy i normy EN 301 549, która odwołuje się do kryteriów WCAG 2.1 na poziomach A i AA.

Jak to wygląda w praktyce? Ministerstwo Cyfryzacji co roku monitoruje strony instytucji. Według wyników monitoringu za 2025 rok żadna ze sprawdzonych stron nie była w pełni zgodna z ustawą, a większość, 79 serwisów, uznano za częściowo zgodne. To dobra ilustracja, że pełna zgodność jest trudna nawet dla podmiotów, które mają ten obowiązek od lat.

Firmy prywatne

Od 28 czerwca 2025 roku obowiązuje Polski Akt o Dostępności, czyli ustawa z dnia 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Obejmuje ona m.in. usługi handlu elektronicznego i bankowość konsumencką. Spod obowiązku wyłączeni są jedynie mikroprzedsiębiorcy świadczący usługi. Przy sklepie internetowym sprawdzana jest dostępność całej ścieżki zakupowej: nawigacji, koszyka i płatności.

Ustawa nie mówi wprost „spełnij WCAG 2.1 AA”, ale rządowe wytyczne do PAD opierają się na normie europejskiej EN 301 549, a ta w części dotyczącej stron internetowych przenosi kryteria WCAG. W praktyce więc, jeśli prowadzisz sklep i nie jesteś mikroprzedsiębiorcą, poziom AA jest Twoim realnym punktem odniesienia.

Jeśli nie masz pewności, czy Twoja firma podlega PAD, np. przy granicy definicji mikroprzedsiębiorcy albo przy usłudze sprzedawanej wyłącznie innym firmom, sprawdź to z prawnikiem znającym tę ustawę. Ja pomagam w części technicznej, interpretację przepisów zostawiam specjalistom od prawa.

WCAG 2.1 czy 2.2: której wersji się trzymać

Najnowszą wersją jest WCAG 2.2, wydana 5 października 2023 roku. W grudniu 2024 roku W3C opublikowało jeszcze drobne poprawki redakcyjne do obu wersji, 2.1 i 2.2, więc obie pozostają aktualnymi dokumentami.

Kluczowa informacja jest taka: treść zgodna z WCAG 2.2 jest zgodna także z WCAG 2.1 i 2.0. Wersja 2.2 dodaje kilka kryteriów, m.in. minimalny rozmiar celu dotyku (24 na 24 piksele CSS), wymóg, by element z fokusem nie był zasłonięty przez np. przyklejony nagłówek, oraz ułatwienia przy logowaniu, które nie wymagają zapamiętywania haseł czy rozwiązywania łamigłówek. Jedno stare kryterium (4.1.1 Parsowanie) usunięto jako nieaktualne.

Moja rekomendacja: jeśli przepisy lub umowa wymagają WCAG 2.1 AA, projektuj pod WCAG 2.2 AA. Spełnisz wymóg dziś i nie będziesz przerabiać strony, gdy normy zostaną zaktualizowane.

Poziomy A, AA i AAA: czym się różnią

Poziomy zgodności są progresywne. Według przeglądu W3C opisanego na web.dev poziom A to minimum, AA to standard najczęściej wymagany przez organizacje, a AAA to poziom najwyższy. Spełnienie AA oznacza jednocześnie spełnienie A, a AAA obejmuje oba niższe poziomy.

Najłatwiej zobaczyć różnicę na konkretnych kryteriach z oficjalnej specyfikacji:

Dlaczego nie warto celować w AAA dla całego serwisu

Samo W3C w dokumencie o zgodności odradza wymaganie poziomu AAA jako ogólnej polityki dla całych serwisów, bo dla części treści nie da się go spełnić. Przykład: tłumaczenie każdego filmu na język migowy czy przepisanie specjalistycznego regulaminu na poziom szkoły podstawowej bywa niewykonalne albo zmienia sens dokumentu.

To nie znaczy, że AAA jest bezużyteczne. Kilka kryteriów z tego poziomu wdrażam często, bo kosztują niewiele, a realnie pomagają:

• większe przyciski i linki na urządzeniach mobilnych (44 px to też wygodniejsze klikanie kciukiem),
• wyższy kontrast w kluczowych miejscach, np. na cenach i przyciskach w koszyku,
• brak niespodziewanych limitów czasu przy wypełnianiu formularzy.

Podsumowując: AA jako obowiązkowa podstawa, wybrane kryteria AAA tam, gdzie poprawiają doświadczenie wszystkich użytkowników.

Kryteria, na których najczęściej potykają się strony firm

Z mojej praktyki przy audytach i przebudowach serwisów firmowych te problemy powtarzają się najczęściej. Wszystkie dotyczą poziomu A lub AA, więc są wymagane:

1. Za słaby kontrast. Jasnoszary tekst na białym tle wygląda elegancko w makiecie, ale nie spełnia progu 4,5:1. Dotyczy to też placeholderów w formularzach.
2. Brak lub bezsensowny tekst alternatywny. Atrybut alt z nazwą pliku „IMG_2048.jpg” formalnie istnieje, ale nic nie mówi użytkownikowi czytnika ekranu.
3. Obsługa wyłącznie myszą. Menu rozwijane, karuzele i okna modalne, których nie da się otworzyć ani zamknąć klawiaturą.
4. Niewidoczny fokus. Projektant usunął obramowanie fokusa, bo „brzydko wygląda”, i osoba nawigująca klawiszem Tab nie wie, gdzie jest.
5. Formularze bez etykiet. Pole opisane tylko placeholderem znika z opisu, gdy użytkownik zaczyna pisać, a komunikat o błędzie pojawia się wyłącznie jako czerwona ramka.
6. Brak przepływu treści na małym ekranie. WCAG 2.1 wprowadziło wymóg, by treść dało się czytać przy szerokości 320 pikseli CSS bez przewijania w poziomie. W praktyce oznacza to powiększenie do 400% na typowym monitorze.
7. Elementy zewnętrzne. Banery cookies, widżety czatu i okna newslettera, które przykrywają treść, nie mają fokusa albo mają kolory niespełniające wymogów kontrastu.

Ostatni punkt łatwo przeoczyć, bo te elementy dostarcza zwykle inna firma. Jeśli narzędzie na to pozwala, popraw kolory i stany fokusa we własnym zakresie. Dobrym przykładem jest dostosowanie wyglądu widżetu czatu własnym CSS, dzięki któremu dopasujesz kontrast przycisków i fokus do reszty strony, zamiast zostawiać domyślne kolory.

Jak przeprowadzić testy dostępności strony

Rzetelne sprawdzenie dostępności składa się z trzech etapów: testów automatycznych, ręcznych i testów z udziałem użytkowników, także osób z niepełnosprawnościami. Najpełniejszą formą jest audyt ekspercki.

Krok 1: testy automatyczne

Zacznij od narzędzi, które przeskanują stronę i wskażą oczywiste błędy: brak tekstów alternatywnych, puste linki, za niski kontrast, błędną strukturę nagłówków. Portal gov.pl ma przegląd narzędzi do automatycznego testowania dostępności, w tym kalkulatorów kontrastu, w których wpiszesz kolory w formacie CSS i od razu sprawdzisz, czy para spełnia wymogi WCAG.

Uwaga na pułapkę. W3C przypomina, że narzędzia oceny mogą dawać fałszywe lub mylące wyniki, a ostateczna ocena wymaga ludzkiego osądu. Automat sprawdzi, czy obrazek ma alt, ale nie oceni, czy ten opis ma sens. Wynik 100 na 100 w narzędziu nie oznacza zgodności z WCAG.

Krok 2: testy ręczne

Tu zaczyna się właściwa praca. Prosty zestaw, który możesz zrobić sam w godzinę:

1. Odłóż mysz i przejdź całą kluczową ścieżkę (np. od strony głównej do wysłania formularza lub zapłaty) wyłącznie klawiszami Tab, Shift+Tab, Enter i spacją.
2. Sprawdź, czy przez cały czas widzisz, który element jest aktywny.
3. Powiększ stronę w przeglądarce do 200%, a potem do 400%, i zobacz, czy nic się nie nakłada ani nie znika.
4. Włącz czytnik ekranu (NVDA w Windows, VoiceOver w macOS i iOS, TalkBack w Androidzie) i posłuchaj, jak brzmi menu i formularz.
5. Wyślij formularz z błędem i sprawdź, czy komunikat jest opisany tekstem, a nie tylko kolorem.
6. Otwórz kilka PDF-ów ze strony i zobacz, czy mają strukturę, czy są tylko skanem.

Krok 3: testy z użytkownikami

Nic nie zastąpi obserwacji osoby, która na co dzień korzysta z czytnika ekranu lub nawiguje klawiaturą. Takie testy wyłapują problemy, których nie ma w żadnej liście kryteriów, np. mylącą kolejność treści czy zbyt długą drogę do przycisku „Kup”.

Jeśli potrzebujesz pełnego obrazu i raportu z listą poprawek, opisałem osobno, jak zamówić audyt WCAG i wykorzystać raport tak, by poprawki przełożyły się też na konwersję.

Moje podejście: dostępność od pierwszej makiety

Najdroższa dostępność to ta dodawana na końcu. Widzę to przy każdej przebudowie: jeśli kolory marki zostały wybrane bez sprawdzenia kontrastu, a menu zbudowane z elementów, których nie obsłuży klawiatura, poprawki oznaczają zmianę identyfikacji wizualnej albo przepisanie komponentów od nowa. Te same rzeczy zaplanowane na etapie projektu kosztują kilka minut.

Dlatego w moich projektach dostępność nie jest osobnym etapem. Ponieważ projektuję interfejs w Figmie, koduję go i odpowiadam za SEO sam, decyzje o kontraście, wielkości przycisków, kolejności fokusa i strukturze nagłówków podejmuję raz i nie gubią się między projektantem a programistą. Nie korzystam z gotowych szablonów, więc nie dziedziczę cudzych błędów, np. motywu z dziesiątkami niedostępnych suwaków.

Dostępność dobrze idzie w parze z tym, co i tak jest dla firmy ważne. Czytelna struktura nagłówków pomaga Google zrozumieć stronę. Lekki, semantyczny kod przyspiesza ładowanie i poprawia Core Web Vitals. Wyraźne przyciski i dobrze opisane formularze zwiększają liczbę zapytań i zamówień. Więcej o tym, jak łączę wygląd z użytecznością, piszę w tekście o różnicy między UI a UX.

— Marcin

Strona zgodna z WCAG bez przerabiania wszystkiego od zera

Jeśli planujesz nową stronę albo sklep i chcesz od początku spełnić wymagania WCAG 2.1 i 2.2 na poziomie AA, mogę poprowadzić cały proces: od projektu UI/UX, przez wdrożenie, po optymalizację szybkości i widoczności w Google. Zobacz, jak wygląda projektowanie stron i UI/UX, albo od razu sprawdź ofertę sklepów internetowych, jeśli Twoja firma podlega Polskiemu Aktowi o Dostępności. Przykłady wdrożeń znajdziesz w realizacjach.

Najczęstsze pytania o WCAG 2.1

Od kiedy WCAG 2.1 obowiązuje w Polsce?

Dla podmiotów publicznych kryteria WCAG 2.1 są wymagane na mocy ustawy o dostępności cyfrowej z 4 kwietnia 2019 roku. Firmy prywatne objęte Polskim Aktem o Dostępności mają obowiązki od 28 czerwca 2025 roku. W ich przypadku punktem odniesienia jest norma EN 301 549, która przenosi kryteria WCAG.

Czy moja mała firma musi spełniać WCAG?

Polski Akt o Dostępności wyłącza z obowiązków mikroprzedsiębiorców świadczących usługi. Jeśli Twoja firma jest większa i sprzedaje konsumentom online, prawdopodobnie podlega ustawie. Nawet bez obowiązku dostępna strona jest wygodniejsza dla wszystkich klientów, więc warto o nią zadbać.

Który poziom wybrać: AA czy AAA?

Wybierz AA. To poziom, do którego odwołują się przepisy i normy, a W3C nie zaleca wymagania AAA dla całych serwisów. Pojedyncze kryteria AAA, np. większe cele dotyku czy wyższy kontrast, możesz wdrożyć tam, gdzie mają sens.

Jaka jest najnowsza wersja WCAG?

Najnowszą wersją jest WCAG 2.2 z października 2023 roku. Jest zgodna wstecz, więc spełniając ją, spełniasz także WCAG 2.1 i 2.0. Trwają prace nad WCAG 3.0, ale na razie nie jest to obowiązujący standard.

Czy wtyczka lub nakładka zapewni zgodność z WCAG?

Nie. Nakładki dodające przyciski powiększenia czy zmiany kontrastu nie naprawiają kodu strony, np. brakujących etykiet formularzy czy niedostępnego menu. Zgodność osiąga się przez poprawny projekt i kod, a potwierdza testami ręcznymi i audytem.

Źródła

• WCAG 2 Overview, W3C
• WCAG 2.1 już oficjalnie po polsku, Ministerstwo Cyfryzacji
• ABC Koordynacji Dostępności, Fundusze Europejskie
• Wyniki monitorowania dostępności cyfrowej w 2025 r., gov.pl
• Polski Akt o Dostępności: usługi handlu elektronicznego, gov.pl
• Wytyczne: jak zapewnić dostępność produktów i usług, gov.pl
• Measure accessibility, web.dev
• Ogłoszenie o aktualizacji WCAG 2.1 i 2.2, W3C
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C
• Understanding Conformance, W3C
• Jak automatycznie testować dostępność cyfrową stron, gov.pl
• Wybór narzędzi oceny dostępności cyfrowej, W3C

Rekomendacje

• Audyt WCAG: jak zamówić go i wykorzystać raport do poprawy konwersji