Jak dostosować stronę internetową do potrzeb osób niepełnosprawnych zgodnie z WCAG 2.2?

Czym jest dostępność cyfrowa i jakie zasady WCAG ją definiują?

Dostępność cyfrowa stron internetowych to projektowanie serwisów w sposób, który pozwala każdemu użytkownikowi korzystać z nich bez barier. Osoby niewidome odczytują treści przez czytnik ekranu. Osoby z ograniczeniami ruchowymi nawigują wyłącznie klawiaturą. Osoby niedosłyszące potrzebują napisów do materiałów wideo. Strona dostępna cyfrowo obsługuje te scenariusze bez dodatkowych narzędzi po stronie użytkownika.

Cztery zasady WCAG opracowane przez W3C i Web Accessibility Initiative definiują, co konkretnie strona musi spełniać. Stosuję je jako checklistę przy każdym projekcie.

• Postrzegalność – treści muszą być dostępne dla zmysłów użytkownika. Grafiki wymagają opisów alternatywnych, filmy potrzebują transkrypcji, a tekst musi mieć odpowiedni kontrast względem tła.

• Operowalność – cała nawigacja i interakcja muszą działać bez myszki. Przyciski, formularze i menu obsługiwane samą klawiaturą to absolutne minimum.

• Zrozumiałość – struktura strony musi być przewidywalna, a język prosty. Komunikaty błędów w formularzach powinny wskazywać co poprawić, nie tylko sygnalizować problem.

• Solidność – kod HTML musi być poprawny semantycznie, żeby technologie wspomagające prawidłowo interpretowały każdy element interfejsu.

Te cztery filary obowiązują niezależnie od tego, czy budujesz stronę dla urzędu czy dla firmy usługowej. Różnica polega na poziomie zgodności, który musisz osiągnąć. Planowanie dostępności cyfrowej od samego początku projektu zajmuje znacznie mniej czasu niż późniejsze poprawki na gotowej stronie. Dlatego uwzględniam te zasady już na etapie planowania struktury i projektu graficznego.

Od czego zacząć dostosowanie strony do WCAG 2.2?

Pierwszym krokiem w dostosowaniu firmowych stron internetowych do standardu WCAG 2.2 jest audyt obecnego stanu strony. Zanim cokolwiek zmienisz, musisz wiedzieć co dokładnie nie działa. Uruchamiam trzy darmowe narzędzia na 5 najważniejszych podstronach i w ciągu 20 minut mam pełną listę problemów.

1. WAVE (wave.webaim.org) – wklej adres strony i otrzymasz wizualną mapę błędów. Narzędzie oznacza brakujące opisy alternatywne, błędy kontrastu i problemy ze strukturą nagłówków bezpośrednio na stronie.

2. Lighthouse w Chrome – otwórz DevTools (F12), zakładka Lighthouse, zaznacz Accessibility. Wynik poniżej 90/100 oznacza poważne problemy. Każdy błąd zawiera link do konkretnej wytycznej WCAG z opisem jak go naprawić.

3. Test klawiaturą – zamknij myszkę i spróbuj przejść przez całą stronę samym klawiszem Tab. Każdy element interaktywny musi być osiągalny i widocznie podświetlony. Jeśli fokus gdzieś znika, osoba z ograniczeniami ruchowymi utknie w tym samym miejscu.

Po audycie sortuję błędy według wpływu na użytkownika. Pięć poprawek, które rozwiązują około 70% problemów z dostępnością stron: uzupełnienie atrybutów alt przy każdej grafice, podbicie kontrastu tekstu do minimum 4.5:1, dodanie etykiet do pól formularzy, poprawienie hierarchii nagłówków H1 do H3 oraz usunięcie elementów niedostępnych z klawiatury.

Przy stronach na WordPressie zaczynam od wtyczki WP Accessibility, która automatycznie naprawia część błędów: wymusza fokus na elementach nawigacji, dodaje skip link i poprawia atrybuty ARIA. Pozostałe problemy rozwiązuję ręcznie w motywie. Cały proces dostosowania strony wizytówkowej zajmuje mi 4 do 8 godzin roboczych.

Polecany wpis: Jak przeprowadzić walidację strony internetowej zgodnie ze standardami W3C i WCAG?

Czym różni się WCAG 2.0, 2.1 i 2.2?

Standard WCAG 2.0 powstał w 2008 roku i przez ponad dekadę był jedynym punktem odniesienia dla dostępności stron internetowych. Wersja 2.1 z 2018 roku dodała 17 nowych kryteriów sukcesu, głównie dotyczących urządzeń mobilnych i osób z ograniczeniami poznawczymi. WCAG 2.2, opublikowany w październiku 2023, rozszerzył standard o kolejne 9 kryteriów i jest aktualnie zalecaną wersją wytycznych dotyczących dostępności.

Cecha	WCAG 2.0 (2008)	WCAG 2.1 (2018)	WCAG 2.2 (2023)
Liczba kryteriów sukcesu	61	78	87
Obsługa mobilna	Brak	Tak, gesty dotykowe i orientacja ekranu	Tak, rozszerzona o minimalne rozmiary celów dotykowych
Ograniczenia poznawcze	Minimalne	Częściowe	Rozbudowane, m.in. pomoc kontekstowa i spójne mechanizmy nawigacji
Wymagany w polskim prawie	Nie	Tak, dla podmiotów publicznych	Rekomendowany od 2026
Status	Przestarzały	Obowiązujący standard prawny	Aktualny standard techniczny

W praktyce każda kolejna wersja zawiera wszystkie wymagania poprzedniej i dodaje nowe. Strona zgodna z WCAG 2.2 automatycznie spełnia standardy WCAG 2.0 i 2.1. Dlatego przy nowych projektach nie ma sensu celować w starsze wersje. Przy dostosowaniu istniejących stron internetowych zaczynam od wymagań 2.1, bo te egzekwuje polskie prawo, a następnie wdrażam dodatkowe kryteria z 2.2.

Poziomy zgodności A, AA i AAA – który wybrać?

Poziom AA to realny cel dla każdej strony firmowej i instytucjonalnej w 2026 roku. Poziom A pokrywa absolutne minimum, bez którego strona jest całkowicie niedostępna dla osób korzystających z technologii wspomagających. Poziom AAA wymaga m.in. kontrastu 7:1 i transkrypcji w czasie rzeczywistym, co dla większości serwisów komercyjnych jest nieopłacalne.

• Poziom A – 25 kryteriów bazowych. Obejmuje opisy alternatywne grafik, dostęp z klawiatury i brak automatycznie odtwarzanych dźwięków. Około 60% polskich stron firmowych nie spełnia nawet tego poziomu.

• Poziom AA – 13 dodatkowych kryteriów. Wymaga kontrastu tekstu minimum 4.5:1, widocznego wskaźnika fokusa i możliwości zmiany rozmiaru tekstu do 200% bez utraty funkcjonalności. Ustawa o dostępności cyfrowej wymaga tego poziomu od podmiotów publicznych.

• Poziom AAA – 23 kryteria najwyższego poziomu. Stosowany głównie przez strony rządowe UE i serwisy dedykowane osobom z niepełnosprawnościami. Dla strony firmowej czy sklepu internetowego to przerost formy nad potrzebą.

Stosuję prostą regułę przy każdym projekcie. Jeśli klient prowadzi stronę wizytówkową bez e-commerce, celuję w pełne AA. Jeśli prowadzi sklep internetowy objęty Europejskim Aktem o Dostępności, wdrażam AA z wybranymi elementami AAA w procesie zakupowym, bo tam konsekwencje niedostępności są najpoważniejsze.

Kto musi dostosować stronę internetową do WCAG w 2026 roku?

Obowiązek prawny dostosowania stron internetowych do standardu WCAG dotyczy w 2026 roku dwóch grup podmiotów. Pierwsza to instytucje publiczne objęte polską Ustawą o dostępności cyfrowej z 2019 roku. Druga to firmy komercyjne objęte Europejskim Aktem o Dostępności (EAA), który wszedł w życie w czerwcu 2025.

Podmioty objęte obowiązkiem dostosowania stron do WCAG 2.1 poziom AA:

• Instytucje publiczne – urzędy, szkoły, biblioteki, ośrodki pomocy społecznej, domy kultury, publiczne przedszkola i żłobki. Za brak zgodności grozi kara do 10 000 zł, a każdy użytkownik może złożyć zgłoszenie dostępności serwisu do odpowiednich organów.

• E-commerce – sklepy internetowe powyżej średniej wielkości w rozumieniu UE. Cały proces zakupowy musi być dostępny dla osób korzystających z technologii wspomagających.

• Bankowość elektroniczna – bankowość internetowa i aplikacje mobilne banków.

• Platformy e-learningowe – komercyjne kursy online i platformy szkoleniowe.

• Transport z rezerwacją online – e-bilety i systemy rezerwacji.

• Telekomunikacja – strony i aplikacje operatorów.

Podmioty, które nie podlegają pod obowiązek prawny w 2026:

• Strona wizytówkowa firmy usługowej bez e-commerce i rezerwacji online

• Strona kancelarii prawnej bez panelu klienta

• Portfolio fotografa lub projektanta

• Strona restauracji z menu w PDF bez systemu zamówień online

Prowadzę stronę firmową bez sklepu i rezerwacji online. Czy muszę ją dostosować? Prawnie nie. Ale dostępność stron internetowych dla osób z niepełnosprawnościami to nie tylko kwestia przepisów. W Polsce żyje od 4 do 7 milionów osób z ograniczeniami wzroku, słuchu czy ruchu. Niedostosowana strona traci tę grupę odbiorców. Dodatkowo osoba z niepełnosprawnością może wnieść roszczenie cywilne za brak dostępu do usługi. W Polsce zdarza się to 1 do 3 razy rocznie, ale koszt pojedynczego roszczenia sięga 5 000 do 20 000 zł.

Lista obowiązkowych elementów WCAG dla urzędów, fundacji, domów kultury, przedszkoli i żłobków

Strony internetowe instytucji publicznych podlegają najostrzejszym wymaganiom. Przy projektowaniu stron dla przedszkoli, domów kultury czy fundacji realizujących zadania publiczne stosuję poniższą listę jako minimum do wdrożenia.

• Deklaracja dostępności – osobna podstrona z informacją o zakresie zgodności z WCAG 2.1, datą ostatniego przeglądu i danymi kontaktowymi koordynatora dostępności. Bez niej strona formalnie nie spełnia ustawy.

• Kontrast i czytelność – stosunek kontrastu tekstu do tła minimum 4.5:1. Widżet do zmiany rozmiaru czcionki i przełączania trybu kontrastowego to elementy, które wdrażam w każdym projekcie dla instytucji.

• Pełna nawigacja klawiaturą – menu, formularze, przyciski i linki muszą być osiągalne klawiszem Tab. Skip link na początku strony pozwala pominąć powtarzalną nawigację.

• Tekst alternatywny przy każdej grafice – zdjęcia kadry, logotypy, galerie wydarzeń. Osoba korzystająca z czytnika ekranu musi otrzymać opis tego, co przedstawia obraz.

• Transkrypcje i napisy do multimediów – filmy z wydarzeń, relacje, materiały promocyjne placówki wymagają napisów lub transkrypcji tekstowej.

• Poprawna hierarchia nagłówków H1 do H6 – logiczna struktura treści pozwala technologiom wspomagającym prawidłowo interpretować układ strony.

• Dostępne formularze – pola z etykietami, komunikaty błędów wskazujące konkretne pole i czytelne przyciski akcji. Formularz zapisu dziecka do placówki musi być obsługiwalny bez myszki.

• Wersja w języku migowym lub ETR – dla kluczowych informacji publicznych. W praktyce dotyczy to głównie urzędów, ale fundacje realizujące zadania publiczne też powinny to uwzględnić.

Przy dostosowaniu stron internetowej dla przedszkoli i żłobków największym wyzwaniem są galerie zdjęć i formularze zapisu. Galeria z 200 zdjęciami bez opisów alternatywnych to 200 elementów niedostępnych dla osób niewidomych. Formularz zapisu dziecka z rozwijanymi listami bez etykiet blokuje osoby korzystające z klawiatury. Te dwa elementy naprawiam w pierwszej kolejności, bo mają bezpośredni wpływ na to, czy rodzic z niepełnosprawnością zapisze dziecko do placówki.

Jak dostosować stronę na WordPressie do wymagań WCAG?

Dostosowanie stron www na WordPressie do wymagań WCAG zaczyna się od wyboru motywu, który ma poprawną strukturę HTML i obsługuje nawigację klawiaturą. Większość popularnych motywów nie spełnia nawet poziomu A. Testuję każdy motyw narzędziem WAVE przed rozpoczęciem projektu i odrzucam te, które generują więcej niż 5 błędów dostępności na czystej instalacji.

Trzy wtyczki, które stosuję w każdym projekcie wymagającym zgodności z WCAG:

• WP Accessibility (darmowa) – automatycznie dodaje skip link, wymusza widoczny fokus na elementach nawigacji, naprawia atrybuty ARIA w standardowych widgetach WordPressa. Instaluję ją jako pierwszą, bo eliminuje 15 do 20 błędów bez ingerencji w kod motywu.

• One Click Accessibility (darmowa) – dodaje widżet do zmiany kontrastu, powiększania czcionki i podświetlania linków. Użytkownicy korzystający z tego panelu mogą dostosować wygląd strony do swoich potrzeb bez znajomości ustawień przeglądarki.

• AccessiBe / UserWay (płatne, od 49 USD/mies.) – nakładki AI analizujące stronę w czasie rzeczywistym. Poprawiają etykiety formularzy, opisy alternatywne i role ARIA automatycznie. Stosuję je wyłącznie jako uzupełnienie, nie jako zamiennik ręcznych poprawek. Sama nakładka nie gwarantuje pełnej zgodności ze standardem WCAG 2.2.

Osobną kategorią problemów są page buildery. Elementor, Divi i WPBakery generują zagnieżdżone struktury div, które utrudniają poruszanie się po stronie osobom korzystającym z czytnika ekranu. Przy tworzeniu stron dostosowanych do potrzeb osób z niepełnosprawnościami ograniczam page builder do layoutu, a treści właściwe umieszczam w natywnych blokach Gutenberga. Gutenberg domyślnie produkuje czystszy HTML z poprawnymi znacznikami semantycznymi: header, main, article, footer.

Pięć zmian w motywie, które robię ręcznie po instalacji wtyczek:

1. Ustawiam język strony w atrybucie lang="pl" w tagu html – bez tego czytniki ekranu nie dobiorą właściwej syntezy mowy.

2. Sprawdzam każdy formularz Contact Form 7 lub WPForms pod kątem etykiet. Pole bez tagu label jest niewidoczne dla technologii wspomagających.

3. Dodaję atrybut alt do każdego obrazu w bibliotece mediów. WordPress pozwala uzupełniać opisy zbiorczo, ale generyczne teksty typu „obraz-1” nie spełniają wymagań WCAG.

4. Testuję menu mobilne klawiszem Tab. Hamburgery, które otwierają się tylko na kliknięcie myszką, blokują całą nawigację dla osób z ograniczeniami ruchowymi.

5. Usuwam lub zastępuję slidery na stronie głównej. Automatycznie przewijające się bannery to jedna z najczęstszych barier dostępności, szczególnie dla osób z zaburzeniami poznawczymi.

Przy projektowaniu stron na WordPressie stosuję zasadę: jeśli nie mogę przejść przez cały proces (od strony głównej do wysłania formularza) samym klawiszem Tab w mniej niż 60 sekund, strona wymaga poprawek. Ten test zajmuje 2 minuty i wyłapuje 80% problemów z operowalnością, zanim trafią do audytu.

Ile kosztuje dostosowanie strony do standardu WCAG?

Koszt dostosowania strony do standardu WCAG 2.2 zależy od jej rozmiaru i liczby błędów wykrytych w audycie. Strona wizytówkowa na WordPressie z 5 do 10 podstronami wymaga zwykle 4 do 8 godzin pracy i kosztuje od 800 do 2 000 zł netto. Rozbudowany serwis instytucji publicznej z galerią, formularzami i materiałami wideo to 3 000 do 8 000 zł netto i 2 do 4 tygodni roboczych. Sklep internetowy na WooCommerce z setkami kart produktów, procesem checkout i panelem klienta generuje największe koszty, bo każdy element ścieżki zakupowej musi być dostępny dla osób korzystających z technologii wspomagających. Samo dostosowanie stron internetowych dla istniejącego serwisu zawsze wychodzi drożej niż budowa strony dostępnej od zera. Dlatego przy nowych projektach uwzględniam wymagania dostępności cyfrowej już na etapie wyceny, co eliminuje koszty późniejszych przeróbek. Szczegółowe widełki cenowe dla poszczególnych typów stron znajdziesz w moim cenniku usług tworzenia stron internetowych.

Jak sprawdzić czy strona spełnia wytyczne WCAG? – Checklista

Samodzielną weryfikację dostępności stron przeprowadzisz w trzech krokach: automatyczny skan, test manualny i test z użytkownikiem. Narzędzia automatyczne (WAVE, Lighthouse, AXE DevTools) wykrywają około 30 do 40% problemów dotyczących dostępności stron. Pozostałe 60% wymaga ręcznego sprawdzenia przez człowieka, bo żaden algorytm nie oceni czy tekst alternatywny faktycznie opisuje treść obrazu, a nie zawiera pustego ciągu znaków.

Test manualny, który wykonuję przy każdym projekcie:

1. Przechodzę całą stronę klawiszem Tab i sprawdzam czy fokus jest widoczny na każdym elemencie interaktywnym.

2. Wyłączam CSS w przeglądarce i weryfikuję czy treść zachowuje logiczną kolejność bez stylowania.

3. Powiększam tekst do 200% i sprawdzam czy żaden element strony nie zostaje obcięty ani nie nachodzi na sąsiednie bloki.

4. Włączam czytnik ekranu NVDA (darmowy, Windows) i próbuję wykonać kluczową akcję na stronie: wysłać formularz, przejść do oferty, znaleźć dane kontaktowe. Jeśli osoby słabowidzące lub niewidome nie mogą ukończyć tego procesu, strona nie spełnia wytycznych WCAG na poziomie AA.

5. Sprawdzam kontrast kolorów w Color Contrast Analyzer. Każde połączenie tekstu i tła poniżej 4.5:1 to błąd poziomu AA.

Po zakończeniu testów sporządzam raport z listą błędów, priorytetem naprawy i odniesieniem do konkretnego kryterium sukcesu WCAG 2.2. Zgłoszenie do audytu dostępności przez zewnętrzny podmiot (np. Fundację Widzialni) ma sens przy stronach instytucji publicznych, gdzie formalny certyfikat zgodności jest wymagany. Dla stron firmowych wystarczy rzetelny audyt wewnętrzny przeprowadzony według tej procedury.

Czy dostępność cyfrowa wpływa na pozycjonowanie strony w Google?

Dostępność cyfrowa strony nie jest bezpośrednim czynnikiem rankingowym w algorytmie Google. Ale wpływa na pozycjonowanie pośrednio przez sygnały, które Google mierzy i nagradza. Poprawna struktura nagłówków, opisy alternatywne grafik, semantyczny HTML i szybkość ładowania to jednocześnie wymagania WCAG i kryteria oceny jakości strony przez Googlebota.