WCAG — co to jest, wymagania, poziomy i jak sprawdzić stronę
WCAG (Web Content Accessibility Guidelines) to międzynarodowe wytyczne dostępności treści internetowych opracowane przez konsorcjum W3C. Opisują, jak budować strony, sklepy i aplikacje, żeby mogły z nich korzystać także osoby z niepełnosprawnościami — niewidome, słabowidzące, niesłyszące, z ograniczeniami ruchowymi lub trudnościami poznawczymi. Od 28 czerwca 2025 roku zgodność z nimi jest w Polsce obowiązkiem prawnym również dla wielu firm prywatnych.
W tym artykule wyjaśniamy, czym jest WCAG, jak różnią się wersje 2.0, 2.1 i 2.2, co oznaczają poziomy A, AA i AAA oraz kogo dokładnie obejmują przepisy o dostępności cyfrowej. Pokazujemy też, który standard jest dziś wiążący prawnie, jak samodzielnie sprawdzić stronę walidatorem, na czym polega audyt dostępności i co najczęściej wymaga poprawy na stronach opartych na WordPressie.
WCAG — co to jest?
WCAG to zbiór wytycznych technicznych określających, jak projektować i kodować treści cyfrowe, aby były dostępne dla jak najszerszego grona odbiorców. Publikuje je W3C (World Wide Web Consortium) — organizacja odpowiedzialna za standardy sieci — za pośrednictwem inicjatywy WAI (Web Accessibility Initiative). Dokument nie jest ustawą ani normą państwową; to rekomendacja techniczna, do której odsyłają przepisy prawa w Unii Europejskiej, Stanach Zjednoczonych i wielu innych krajach.
Wytyczne mają strukturę trójstopniową: cztery ogólne zasady dzielą się na wytyczne, a te na konkretne, sprawdzalne kryteria sukcesu. Każde kryterium przypisano do jednego z trzech poziomów zgodności — A, AA lub AAA. Dzięki takiej budowie dostępność da się mierzyć: strona albo spełnia dane kryterium, albo nie, a wynik można udokumentować w raporcie z audytu lub w deklaracji dostępności. To odróżnia WCAG od ogólnych zaleceń „dbaj o użyteczność”.
WCAG 2.0, 2.1 i 2.2 — czym różnią się wersje
Kolejne wersje WCAG nie zastępują poprzednich, lecz je rozszerzają — są kompatybilne wstecz. Strona zgodna z WCAG 2.2 spełnia jednocześnie wymagania 2.1 i 2.0, więc porządkowanie dostępności nigdy nie idzie na marne przy zmianie wersji standardu.
- WCAG 2.0 (2008) — 12 wytycznych i 61 kryteriów sukcesu; wersja historyczna, do której odwoływały się pierwsze polskie przepisy.
- WCAG 2.1 (2018) — 13 wytycznych i 78 kryteriów; dodano wymagania dla urządzeń mobilnych, osób słabowidzących i z trudnościami poznawczymi.
- WCAG 2.2 (październik 2023) — 86 kryteriów; nowe wymagania dotyczące widocznego fokusu, alternatywy dla przeciągania, minimalnego rozmiaru elementów klikalnych, spójnej pomocy i logowania bez testów pamięciowych. Usunięto kryterium 4.1.1 (Parsowanie), zdezaktualizowane przez współczesne przeglądarki.
W praktyce projektowej różnice między 2.1 a 2.2 są niewielkie i dotyczą kilku dodatkowych kryteriów. Jeśli budujesz stronę dzisiaj, sensownie jest celować od razu w WCAG 2.2 na poziomie AA — koszt jest zbliżony, a unikasz poprawiania serwisu przy najbliższej zmianie przepisów.
Cztery zasady WCAG: postrzegalność, funkcjonalność, zrozumiałość, solidność
Cała konstrukcja WCAG opiera się na czterech zasadach, nazywanych w skrócie POUR. Postrzegalność oznacza, że informacje muszą być dostępne dla zmysłów użytkownika: grafiki wymagają tekstów alternatywnych, filmy — napisów, a tekst — wystarczającego kontrastu względem tła. Funkcjonalność to możliwość obsługi całego interfejsu z klawiatury, bez pułapek nawigacyjnych i bez presji czasu.
Zrozumiałość dotyczy języka i przewidywalności: treść ma być napisana klarownie, język strony zadeklarowany w kodzie, nawigacja spójna na wszystkich podstronach, a formularze — opatrzone czytelnymi etykietami i komunikatami o błędach. Solidność to poprawny, semantyczny kod, który zinterpretują nie tylko przeglądarki, ale też technologie wspomagające: czytniki ekranu, systemy sterowania głosem czy alternatywne urządzenia wskazujące. Trzy pierwsze zasady dotyczą wspólnie projektanta i redaktora treści, czwarta jest zadaniem programisty.
Poziomy zgodności WCAG: A, AA i AAA
Poziom A to minimum — obejmuje kryteria, bez których część użytkowników w ogóle nie skorzysta ze strony, na przykład obsługa klawiaturą czy teksty alternatywne grafik. Poziom AA dokłada wymagania decydujące o realnej wygodzie: odpowiedni kontrast, poprawną hierarchię nagłówków, widoczne wskazanie fokusu, spójną nawigację i etykiety formularzy. To właśnie poziom AA jest punktem odniesienia w przepisach — zarówno dla podmiotów publicznych, jak i dla firm objętych europejskimi regulacjami.
Poziom AAA to najwyższe wymagania, obejmujące między innymi kontrast 7:1, tłumaczenie treści na język migowy czy uproszczoną wersję językową. W3C wprost zaznacza, że pełna zgodność z AAA nie jest realistycznym celem dla całych serwisów i nie jest wymagana prawnie — traktuje się ją jako kierunek dla wybranych treści, nie jako standard wdrożeniowy. W praktyce rozmowa o zgodności zawsze dotyczy poziomu AA.
Kto musi spełniać WCAG w Polsce — podmioty publiczne
Instytucje publiczne mają obowiązek zapewnienia dostępności cyfrowej od 2019 roku. Reguluje to ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych, wdrażająca dyrektywę (UE) 2016/2102. Dotyczy urzędów, sądów, szkół i uczelni, szpitali, jednostek samorządu oraz części organizacji finansowanych ze środków publicznych.
Ustawa wymaga zgodności serwisów i aplikacji z normą zharmonizowaną, czyli w praktyce z WCAG na poziomie AA, oraz publikacji deklaracji dostępności — dokumentu opisującego stan zgodności, wykryte wyjątki i dane kontaktowe do zgłaszania barier. Dostępność podmiotów publicznych podlega cyklicznemu monitoringowi, a użytkownik ma prawo złożyć żądanie zapewnienia dostępności konkretnej treści i otrzymać odpowiedź w terminie określonym ustawowo.
Firmy prywatne a WCAG — Europejski Akt o Dostępności
Od 28 czerwca 2025 roku obowiązek dostępności objął także sektor prywatny. Podstawą jest Europejski Akt o Dostępności — dyrektywa (UE) 2019/882 — wdrożona do polskiego prawa ustawą z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Przepisy obejmują m.in. handel elektroniczny, bankowość i usługi finansowe, telekomunikację, transport pasażerski, usługi dostępu do mediów audiowizualnych oraz e-booki.
Nie każda firma z branżowego katalogu podlega tym samym rygorom. Ustawa (Dz.U. 2024 poz. 731) przewiduje wyłączenie dla mikroprzedsiębiorstw — podmiotów zatrudniających mniej niż 10 osób, których roczny obrót lub suma bilansowa nie przekracza 2 mln euro. Uwaga na zakres tego wyłączenia: obejmuje ono wyłącznie oferowanie i świadczenie usług. Mikroprzedsiębiorca, który produkuje lub wprowadza do obrotu produkty objęte ustawą, podlega jej wymaganiom na zwykłych zasadach. Niezależnie od wielkości firmy działa też mechanizm nieproporcjonalnego obciążenia, z którego można skorzystać po udokumentowanej analizie. Naruszenia są zagrożone administracyjnymi karami pieniężnymi, a zakres obowiązków dla konkretnej działalności warto potwierdzić z prawnikiem.
Który standard obowiązuje prawnie: WCAG 2.1 czy 2.2?
Prawnie wiążącym punktem odniesienia w Unii Europejskiej jest nie sam dokument WCAG, lecz norma zharmonizowana EN 301 549. Jej obowiązująca wersja 3.2.1, zharmonizowana decyzją wykonawczą Komisji (UE) 2021/1339, włącza WCAG 2.1 na poziomach A i AA — i to jest dziś formalne minimum, mimo że WCAG 2.2 jest publikowany od października 2023 roku. Nowa wersja normy nabiera mocy prawnej dopiero po odniesieniu do niej w Dzienniku Urzędowym UE, co jest odrębnym krokiem po stronie Komisji Europejskiej.
Aktualizacja jest w toku: projekt EN 301 549 w wersji 4 przeszedł konsultacje publiczne pod koniec 2025 roku, a wersja finalna — przenosząca treści internetowe na WCAG 2.2 AA i mapująca normę wprost na wymagania Europejskiego Aktu o Dostępności — jest spodziewana w Dzienniku Urzędowym w drugiej połowie 2026 roku. Praktyczny wniosek dla firm jest jeden: prawne minimum to WCAG 2.1 AA, ale wdrażaj od razu 2.2 AA, żeby nie płacić za tę samą pracę dwa razy w perspektywie kilkunastu miesięcy.
Kontrast w WCAG — jakie wartości są wymagane
Kontrast to najczęściej naruszane kryterium i jednocześnie najłatwiejsze do sprawdzenia. Na poziomie AA tekst musi mieć współczynnik kontrastu co najmniej 4,5:1 względem tła. Dla tekstu dużego — od 18 punktów lub od 14 punktów w wersji pogrubionej — wystarczy 3:1. Ten sam próg 3:1 obowiązuje elementy nietekstowe istotne dla obsługi: ikony, obramowania pól formularzy, wskaźniki stanu.
W praktyce problem tworzą jasnoszare teksty pomocnicze, kolorowe przyciski z białym napisem, teksty nałożone na zdjęcia oraz podpowiedzi w polach formularzy. Współczynnik sprawdzisz w kilka sekund bezpłatnym narzędziem — na przykład WebAIM Contrast Checker albo próbnikiem kontrastu wbudowanym w narzędzia deweloperskie przeglądarki. Warto ustalić dostępną paletę już na etapie projektu graficznego: poprawianie kontrastu w gotowym serwisie zwykle oznacza korektę całej identyfikacji wizualnej.
Najczęstsze błędy dostępności na stronach
Większość barier na polskich stronach powtarza się w kilku wariantach. Poniższa lista pokrywa problemy, które wykrywamy najczęściej podczas przeglądu serwisów Klientów.
- Brakujące lub bezużyteczne teksty alternatywne grafik („obrazek1.jpg”, „zdjęcie”).
- Zbyt niski kontrast tekstu, zwłaszcza w stopce, podpisach i polach formularzy.
- Niewidoczny fokus klawiatury — użytkownik nie wie, w którym miejscu strony się znajduje.
- Menu, karuzele i okna modalne obsługiwane wyłącznie myszą.
- Nagłówki użyte dla efektu wizualnego zamiast do budowy struktury dokumentu.
- Formularze bez etykiet powiązanych z polami i bez czytelnych komunikatów o błędach.
- Linki typu „kliknij tutaj” i „czytaj więcej”, nieczytelne poza kontekstem.
- Filmy bez napisów i dokumenty PDF opublikowane jako skany bez warstwy tekstowej.
Charakterystyczne jest to, że większość z tych błędów nie wymaga przebudowy serwisu — to poprawki na poziomie treści, szablonu i arkusza stylów. Kosztowne stają się dopiero wtedy, gdy strona opiera się na źle napisanym motywie lub na skomplikowanym kreatorze wizualnym generującym nadmiarowy kod.
Jak sprawdzić zgodność strony z WCAG — walidatory i testy
Podstawowy przegląd zrobisz sam, bezpłatnie. Walidator WAVE pokazuje błędy dostępności bezpośrednio na stronie, rozszerzenie axe DevTools raportuje naruszenia z odniesieniem do konkretnych kryteriów WCAG, a Lighthouse (wbudowany w przeglądarkę Chrome) daje szybki wynik ogólny wraz z listą problemów. Do sprawdzania kolorów służy WebAIM Contrast Checker.
Narzędzia automatyczne mają jednak twarde ograniczenie: wykrywają orientacyjnie od 30 do 40 procent barier — tych, które da się rozpoznać maszynowo, jak brak atrybutu alt czy zbyt niski kontrast. Nie ocenią, czy tekst alternatywny faktycznie opisuje grafikę, czy kolejność nawigacji klawiaturą jest logiczna ani czy komunikat o błędzie jest zrozumiały. Dlatego rzetelna ocena zawsze łączy testy automatyczne z manualnymi: przejściem całej ścieżki użytkownika samą klawiszem Tab, odsłuchaniem strony w czytniku ekranu (NVDA jest bezpłatny) i sprawdzeniem serwisu przy 200-procentowym powiększeniu.
Audyt WCAG — co obejmuje i co dostajesz
Audyt dostępności to uporządkowany przegląd serwisu pod kątem wszystkich kryteriów wybranego poziomu zgodności. Zaczyna się od doboru reprezentatywnej próbki stron: strony głównej, szablonu podstrony, listingu, karty produktu, formularza kontaktowego i ścieżki zakupowej lub rejestracyjnej. Każdy z tych widoków sprawdza się automatycznie i manualnie, a wykryte problemy opisuje z przypisaniem do konkretnego kryterium WCAG.
Efektem jest raport z listą naruszeń, ich wagą, lokalizacją w kodzie i rekomendowanym sposobem naprawy — dokument, na podstawie którego programista może pracować bez dodatkowych ustaleń. Po wdrożeniu poprawek wykonuje się retest, a stan zgodności opisuje w deklaracji dostępności. Warto pamiętać, że dostępność nie jest stanem jednorazowym: każda nowa podstrona, wtyczka i publikowany materiał mogą wprowadzić nowe bariery, dlatego przegląd warto powtarzać, podobnie jak w przypadku bieżącej obsługi stron internetowych.
WCAG a WordPress — co sprawdzić na swojej stronie
Sam WordPress nie przesądza o dostępności — decyduje motyw, sposób budowania podstron i praktyka redakcyjna. Motywy z oficjalnego katalogu oznaczone etykietą „accessibility-ready” przechodzą podstawową weryfikację, ale nie gwarantują zgodności całego serwisu. Najwięcej problemów sprawiają rozbudowane kreatory wizualne, w których nagłówki dobiera się według wielkości czcionki, a przyciski i suwaki generowane są jako elementy nieobsługiwane z klawiatury.
Osobna kwestia to wtyczki typu overlay — nakładki obiecujące „zgodność z WCAG jednym kliknięciem”. Nie naprawiają one kodu, a jedynie dokładają warstwę na wierzchu strony; organizacje osób z niepełnosprawnościami wprost odradzają takie rozwiązania, a w wielu krajach stały się one przedmiotem pozwów. Realna poprawa polega na uporządkowaniu szablonu, hierarchii nagłówków, kontrastu i formularzy — czasem w ramach bieżących poprawek, a przy starych motywach w ramach przebudowy strony internetowej. Przy nowych projektach dostępność planujemy od początku, już na etapie projektowania stron internetowych.
WCAG 2.0 a WordPress - czy WordPress spełnia wymagania
Sam WordPress, czyli rdzeń systemu i edytor blokowy, jest projektowany z myślą o dostępności. Zespół WordPressa wymaga, żeby kod rdzenia, oficjalne wtyczki i serwisy WordPress.org spełniały WCAG 2.2 na poziomie AA. To wyższa poprzeczka niż WCAG 2.0, bo każda kolejna wersja zawiera wszystkie wcześniejsze kryteria i dokłada nowe. Strona zgodna z WCAG 2.1 AA jest więc automatycznie zgodna z WCAG 2.0 AA.
Deklaracja zespołu WordPressa dotyczy jednak tylko rdzenia. Gotowa strona składa się jeszcze z motywu, kilkunastu wtyczek, treści wprowadzanych przez redaktorów, zdjęć, plików PDF i osadzonych filmów. To w tych warstwach powstaje zdecydowana większość błędów. Dlatego na pytanie, czy WordPress spełnia WCAG 2.0, uczciwa odpowiedź brzmi: system to umożliwia, ale o zgodności konkretnej strony decyduje to, jak ją zbudowano i jak się ją prowadzi. Zgodność trzeba sprawdzić na gotowej stronie, a nie założyć na podstawie wyboru systemu.
Jak dostosować WordPress do wymagań dostępności - krok po kroku
Dostosowanie istniejącej strony na WordPressie do WCAG najlepiej prowadzić w stałej kolejności: najpierw elementy wspólne dla całego serwisu, potem pojedyncze podstrony i treści. Poprawka w szablonie naprawia problem na wszystkich stronach naraz.
- Sprawdź motyw: kontrast kolorów, widoczny fokus, obsługę menu z klawiatury i link „przejdź do treści” na początku strony.
- Ustaw język strony na polski, żeby czytnik ekranu czytał treść z poprawną wymową.
- Uporządkuj nagłówki: jeden H1 na stronie i kolejne poziomy bez przeskoków, dobierane według struktury, a nie wielkości czcionki.
- Uzupełnij teksty alternatywne w bibliotece mediów. Grafiki czysto dekoracyjne powinny mieć pusty atrybut alt.
- Popraw formularze: każde pole z widoczną etykietą i zrozumiałym komunikatem o błędzie.
- Dodaj napisy do filmów i zastąp skany PDF dokumentami z warstwą tekstową.
- Sprawdź baner cookies i okna wyskakujące. Muszą dać się zamknąć klawiaturą i nie mogą blokować reszty strony.
- Przeszkol osoby, które dodają treści. Bez tego nowe wpisy szybko przywracają stare błędy.
Wtyczki do dostępności WordPress - co pomaga, a co nie
Wtyczki do dostępności dzielą się na dwie grupy, które łatwo pomylić. Pierwsza to narzędzia pomocnicze dla osoby, która prowadzi stronę. Wtyczki takie jak Accessibility Checker skanują wpisy i strony w panelu WordPressa i pokazują błędy, zanim treść zostanie opublikowana. WP Accessibility uzupełnia drobne braki w motywach, na przykład dodaje link „przejdź do treści” czy poprawia atrybut języka. Takie wtyczki realnie ułatwiają pracę, ale nie zastępują poprawek w szablonie.
Druga grupa to nakładki, które dodają na stronie ikonkę z panelem do powiększania tekstu czy zmiany kontrastu i obiecują zgodność z WCAG bez zmian w kodzie. Takie rozwiązanie nie usuwa przyczyn problemów: formularz bez etykiet nadal nie ma etykiet, a menu nieobsługiwane z klawiatury dalej jest nieobsługiwane. Przy ocenie zgodności liczy się to, jak działa sama strona, a nie dodatkowy panel. Jeśli w ofercie wykonawcy zgodność z WCAG sprowadza się do instalacji jednej wtyczki, warto poprosić o raport z testów.
Walidator WCAG 2.0 - jak przetestować stronę na WordPressie
Nie istnieje jeden oficjalny walidator WCAG, który wydaje certyfikat zgodności. Konsorcjum W3C prowadzi jedynie listę narzędzi do oceny dostępności, a same narzędzia różnią się zakresem. Najpraktyczniej jest połączyć dwa lub trzy bezpłatne walidatory, na przykład WAVE, axe DevTools i Lighthouse, i przetestować nimi nie całą stronę, tylko jej typowe szablony.
Na stronie opartej na WordPressie wystarczy zwykle sprawdzić pięć rodzajów podstron: stronę główną, zwykłą podstronę, pojedynczy wpis na blogu, stronę z formularzem kontaktowym, a w sklepie WooCommerce także koszyk i zamówienie. Błąd znaleziony w jednym wpisie najczęściej powtarza się we wszystkich, bo wynika z szablonu. Wyniki walidatora warto zapisać, a po poprawkach przetestować te same adresy jeszcze raz. Walidator HTML od W3C nie jest już wymagany przez WCAG 2.2, ale poprawny kod nadal ułatwia pracę czytnikom ekranu. Pamiętaj, że walidatory automatyczne wychwytują tylko część barier, więc test klawiaturą i czytnikiem ekranu pozostaje konieczny.
Deklaracja dostępności na stronie WordPress
Deklaracja dostępności to dokument, w którym właściciel strony opisuje, w jakim stopniu serwis spełnia wymagania dostępności, jakie elementy są jeszcze niedostępne i jak zgłosić problem. Dla podmiotów publicznych jest obowiązkowa od 2019 roku i musi mieć ustaloną strukturę. Firmy prywatne objęte przepisami o dostępności produktów i usług mają inny obowiązek: informację o tym, jak usługa spełnia wymagania dostępności, publikują w ogólnych warunkach, regulaminie albo równoważnym dokumencie.
W WordPressie deklarację najprościej przygotować jako zwykłą stronę, a link do niej umieścić w stopce, żeby był dostępny z każdej podstrony. Deklaracja musi odpowiadać stanowi faktycznemu. Opublikowanie informacji o pełnej zgodności bez przeprowadzonych testów to ryzyko, a nie zabezpieczenie. Dlatego deklarację przygotowuje się na końcu, po audycie i poprawkach, i aktualizuje po każdej większej zmianie na stronie, na przykład po wymianie motywu.
Dostępność a SEO i konwersja
Dostępność i SEO w dużej mierze opierają się na tych samych fundamentach. Poprawna hierarchia nagłówków, semantyczny kod, opisowe teksty linków, teksty alternatywne grafik, deklaracja języka i czytelna nawigacja są jednocześnie wymaganiami WCAG i sygnałami, dzięki którym wyszukiwarka rozumie strukturę strony. Napisy do filmów dają treść, którą można zindeksować, a uporządkowany kod ułatwia pracę robotom — również tym zbierającym dane dla modeli AI.
Jest też druga strona rachunku: bariery kosztują sprzedaż. Formularz zamówienia, którego nie da się wypełnić z klawiatury, albo przycisk o zbyt niskim kontraście wykluczają część Klientów niezależnie od tego, ile wydajesz na reklamę. Zasady dostępności pokrywają się w wielu miejscach z klasycznymi regułami użyteczności — porządkuje je m.in. zestaw heurystyk Nielsena, które w praktyce prowadzą do podobnych decyzji projektowych.
Od czego zacząć wdrożenie WCAG
Sensowna kolejność prac wygląda tak samo niezależnie od wielkości serwisu. Najpierw ustal, czy Twoja firma podlega przepisom i na jakim poziomie — to determinuje zakres. Potem wykonaj szybki przegląd automatyczny, żeby poznać skalę problemu, i przetestuj klawiaturą kluczowe ścieżki: kontakt, zakup, rejestrację. Dopiero mając tę wiedzę, zamawiaj pełny audyt lub od razu poprawki.
Naprawy warto szeregować według wpływu na użytkownika, nie według liczby błędów w raporcie. Niedziałająca obsługa klawiaturą w koszyku blokuje zakup całkowicie; brak tekstu alternatywnego przy dekoracyjnej grafice w stopce jest problemem marginalnym. Na końcu opublikuj deklarację dostępności i wpisz przegląd dostępności do stałego rytmu prac nad stroną — obok aktualizacji, kopii zapasowych i analizy widoczności.
Podsumowanie
WCAG to wytyczne W3C opisujące, jak tworzyć treści cyfrowe dostępne dla wszystkich użytkowników. Opierają się na czterech zasadach — postrzegalności, funkcjonalności, zrozumiałości i solidności — a zgodność mierzy się na poziomach A, AA i AAA, przy czym praktycznym i prawnym punktem odniesienia jest poziom AA. Podmioty publiczne podlegają przepisom od 2019 roku, a od 28 czerwca 2025 roku obowiązki objęły także wiele firm prywatnych.
Formalne minimum to dziś WCAG 2.1 AA wynikające z normy EN 301 549 v3.2.1, ale nowa wersja normy przeniesie wymagania na WCAG 2.2 AA — dlatego nowe wdrożenia warto od razu robić w tym standardzie. Zacznij od bezpłatnego przeglądu walidatorem i testu klawiaturą, a decyzje o zakresie prac podejmij na podstawie audytu. Poniżej odpowiadamy na najczęstsze pytania o WCAG.
WCAG — najczęściej zadawane pytania
Co to jest WCAG i co oznacza ten skrót?
WCAG to skrót od Web Content Accessibility Guidelines, czyli wytycznych dotyczących dostępności treści internetowych. Opracowuje je konsorcjum W3C. Opisują, jak budować strony i aplikacje, żeby mogły z nich korzystać także osoby z niepełnosprawnościami.
Ile wytycznych zawiera WCAG 2.1?
WCAG 2.1 obejmuje 13 wytycznych zgrupowanych w czterech zasadach oraz 78 kryteriów sukcesu podzielonych na poziomy A, AA i AAA. Dla porównania WCAG 2.0 zawierał 12 wytycznych i 61 kryteriów, a WCAG 2.2 — 86 kryteriów.
Od kiedy obowiązuje WCAG 2.2?
WCAG 2.2 jest oficjalną rekomendacją W3C od 5 października 2023 roku, ale nie stał się jeszcze automatycznie wymogiem prawnym w Unii Europejskiej. Wiążąca jest norma EN 301 549, której obowiązująca wersja odwołuje się do WCAG 2.1 AA; aktualizacja normy do WCAG 2.2 jest w toku.
Jak sprawdzić, czy strona spełnia WCAG?
Zacznij od bezpłatnych walidatorów: WAVE, axe DevTools lub Lighthouse. Wykrywają one część barier automatycznie. Pełną odpowiedź daje dopiero audyt łączący testy automatyczne z manualnymi — obsługą klawiaturą, czytnikiem ekranu i sprawdzeniem powiększenia.
Czy mała firma musi dostosować stronę do WCAG?
To zależy od branży i wielkości firmy. Przepisy wdrażające Europejski Akt o Dostępności obejmują wskazane sektory, m.in. e-commerce i usługi finansowe. Wyłączenie dla mikroprzedsiębiorstw (poniżej 10 osób, obrót lub suma bilansowa do 2 mln euro) dotyczy wyłącznie usług — przy produktach objętych ustawą nie ma zastosowania. Zakres obowiązku dla konkretnej działalności warto potwierdzić z prawnikiem.
Czy wtyczka do WordPressa załatwia zgodność z WCAG?
Nie. Wtyczki i nakładki typu overlay nie naprawiają kodu strony, a jedynie dodają warstwę na wierzchu. Zgodność wymaga poprawek w szablonie, strukturze nagłówków, kontraście i formularzach — czyli pracy nad samą stroną.
Jaki kontrast wymaga WCAG na poziomie AA?
Co najmniej 4,5:1 dla zwykłego tekstu i 3:1 dla tekstu dużego, czyli od 18 punktów lub od 14 punktów pogrubionego. Próg 3:1 obowiązuje też elementy nietekstowe istotne dla obsługi, na przykład obramowania pól formularzy i ikony funkcyjne.
Czy WordPress jest zgodny z WCAG 2.0?
Rdzeń WordPressa jest tworzony zgodnie z WCAG 2.2 AA, co obejmuje też wymagania WCAG 2.0. Zgodność konkretnej strony zależy jednak od motywu, wtyczek i treści, więc trzeba ją sprawdzić testami na gotowej stronie.
Jaki walidator WCAG wybrać?
Najlepiej kilka naraz: WAVE do przeglądu błędów na stronie, axe DevTools do raportu z odniesieniem do kryteriów WCAG i Lighthouse do szybkiej oceny. Żaden walidator nie wydaje certyfikatu zgodności i żaden nie zastąpi testu klawiaturą i czytnikiem ekranu.
Nie wiesz, na ile Twoja strona spełnia wymagania dostępności i od czego zacząć poprawki? Sprawdzimy serwis pod kątem WCAG, wskażemy bariery w kolejności ich wpływu na użytkownika i wdrożymy poprawki — od korekty szablonu po pełną przebudowę strony internetowej, jeśli okaże się konieczna.
Skontaktuj się z nami
Zamów przegląd dostępności strony
Chcesz wiedzieć, czy Twoja strona spełnia wymagania WCAG i co trzeba poprawić w pierwszej kolejności? Sprawdzimy serwis i przedstawimy listę barier wraz z propozycją naprawy — bez zobowiązań. Odpowiadamy w ciągu jednego dnia roboczego.
Tel: 603 338 970
E-mail: kontakt@emm8.pl
Dlaczego warto zacząć z EMM8
- Łączymy pozycjonowanie, widoczność w AI i reklamę w jedną strategię, dzięki czemu cały budżet pracuje na ten sam cel: nowych Klientów.
- Od 2012 roku pomagamy firmom z różnych branż rosnąć w internecie, więc nie uczymy się na Państwa budżecie.
- Projekt prowadzi jedna osoba, która zna Państwa firmę, wyniki i cele, bez przekazywania sprawy między działami.
Zapytanie ofertowe
Wystarczy kilka zdań o firmie i potrzebach. Szczegóły doprecyzujemy na dalszym etapie.
