Formularz działa, przyciski wyglądają dobrze, a strona przechodzi test Lighthouse, ale część osób nadal nie może z niej skorzystać. Wyjaśniam, czym jest WCAG, jak rozumieć poziomy A, AA i AAA oraz co te wytyczne oznaczają dla kodu HTML, CSS i JavaScript. Pokazuję też praktyczne przykłady, sposób testowania i najczęstsze błędy frontendowe.
WCAG porządkuje zasady tworzenia dostępnych stron internetowych
- WCAG to międzynarodowe wytyczne dotyczące dostępności treści internetowych.
- Standard opiera się na 4 zasadach: postrzegalności, funkcjonalności, zrozumiałości i solidności.
- Poziom AA jest najczęściej praktycznym celem dla serwisów i aplikacji.
- Automatyczne testy wykrywają tylko część problemów. Potrzebne są także testy klawiaturą i z czytnikiem ekranu.
- Dostępność najlepiej budować od początku projektu, a nie dopisywać po wdrożeniu.
Czym właściwie jest WCAG
WCAG, czyli Web Content Accessibility Guidelines, to zbiór wytycznych opracowanych przez organizację W3C. Ich celem jest takie tworzenie stron, aplikacji i treści cyfrowych, aby mogły z nich korzystać także osoby z niepełnosprawnościami wzroku, słuchu, ruchu czy funkcji poznawczych.
Nie jest to gotowy framework ani biblioteka do instalacji. WCAG opisuje testowalne wymagania, na przykład konieczność zapewnienia tekstu alternatywnego dla obrazu, widocznego fokusu klawiatury czy odpowiedniego kontrastu. Konkretne rozwiązanie może powstać w czystym HTML i CSS, w React, Vue, Angularze albo dowolnej innej technologii.
W praktyce odpowiada ono na pytanie, czy użytkownik może dostrzec informację, obsłużyć interfejs, zrozumieć jego działanie i odczytać go za pomocą różnych narzędzi. To ważne rozróżnienie, bo sama zgodność z jedną techniką, na przykład użycie atrybutów ARIA, nie gwarantuje jeszcze dostępności.
Cztery zasady, na których opiera się dostępność
WCAG 2.2 porządkuje wymagania według czterech zasad określanych skrótem POUR. Traktuję je jako prostą mapę podczas projektowania, ponieważ pozwalają szybko ustalić, gdzie może pojawić się problem.
| Zasada | Co oznacza | Przykład frontendowy |
|---|---|---|
| Postrzegalność | Informacja musi być dostępna dla różnych zmysłów i sposobów odbioru. | Tekst alternatywny, napisy do filmu, odpowiedni kontrast. |
| Funkcjonalność | Interfejs powinien dać się obsłużyć różnymi metodami. | Pełna obsługa klawiaturą i widoczny fokus. |
| Zrozumiałość | Treść i działanie interfejsu powinny być przewidywalne. | Jasne komunikaty błędów i spójna nawigacja. |
| Solidność | Treść powinna współpracować z przeglądarkami i technologiami asystującymi. | Semantyczny HTML oraz poprawne etykiety formularzy. |
Najłatwiej zobaczyć te zasady na formularzu logowania. Pole bez etykiety może być niewidoczne dla czytnika ekranu, przycisk dostępny wyłącznie po najechaniu myszą będzie nieobsługiwalny z klawiatury, a komunikat „Błąd” bez wskazania problemu pozostanie niezrozumiały. Jeden pozornie drobny komponent może więc naruszać kilka zasad jednocześnie.
Co oznaczają poziomy A, AA i AAA
Każde kryterium sukcesu ma przypisany poziom zgodności. A obejmuje podstawowe problemy, których usunięcie jest konieczne, aby część użytkowników w ogóle mogła skorzystać ze strony. AA dodaje wymagania istotne dla codziennego komfortu i jest najczęściej przyjmowanym celem projektowym.
AAA oznacza najwyższy poziom, ale nie zawsze da się go osiągnąć dla całego serwisu. W3C nie zaleca traktowania go jako uniwersalnego wymogu, ponieważ niektóre kryteria AAA nie pasują do każdego typu treści. Lepiej rzetelnie spełnić poziom AA i poprawić wybrane obszary ponad ten poziom, niż deklarować AAA bez pokrycia.
| Poziom | Znaczenie | Typowy cel |
|---|---|---|
| A | Minimum dostępności | Obowiązkowa baza dla każdego projektu |
| AA | Praktyczny standard dla większości stron | Docelowy poziom dla serwisów komercyjnych i publicznych |
| AAA | Najwyższy poziom, trudny do zastosowania wszędzie | Wybrane elementy i szczególne potrzeby odbiorców |
Przykładowo WCAG 2.2 na poziomie AA wymaga kontrastu co najmniej 4,5:1 dla zwykłego tekstu i 3:1 dla dużego tekstu. Wymaganie nie dotyczy jednak ozdobnych napisów czy logotypów w taki sam sposób jak treści, którą użytkownik musi przeczytać.
Jak WCAG przekłada się na kod frontendowy
Semantyczny HTML jest pierwszą linią obrony
Jeżeli tworzę przycisk, używam elementu Podobnie działają nagłówki, landmarki, listy i etykiety formularzy. Poprawna hierarchia Obraz przekazujący informację powinien mieć sensowny atrybut Nie przekazuję też informacji wyłącznie kolorem. Czerwone obramowanie pola może sygnalizować błąd, ale powinien mu towarzyszyć tekst, ikona albo inny jednoznaczny komunikat. W przypadku filmów potrzebne są między innymi napisy, a czasem także audiodeskrypcja. Najprostszy test wygląda banalnie: odkładam mysz i próbuję wykonać główne zadanie wyłącznie klawiszem Tab, Enter, Spacją i strzałkami. Jeśli fokus znika, kolejność jest nielogiczna albo modalnego okna nie da się zamknąć, użytkownik prawdopodobnie utknie. Nie usuwam obrysu fokusu bez zapewnienia czytelnego zamiennika. W WCAG 2.2 pojawiły się także wymagania dotyczące tego, aby fokus nie był zasłonięty przez przyklejony nagłówek oraz aby elementy sterujące miały odpowiednio duży obszar aktywny. W praktyce przyciski o rozmiarze około 44 pikseli są wygodniejsze na ekranach dotykowych, choć kryterium WCAG 2.2 AA dotyczące minimalnego rozmiaru celu ma wartość 24 na 24 piksele i przewiduje wyjątki. Przeczytaj również: CSS padding - Jak tworzyć czytelne układy bez błędów? ARIA to zestaw atrybutów opisujących role i stany interfejsu technologiom asystującym. Pomaga przy złożonych komponentach, takich jak zakładki, comboboksy czy niestandardowe okna dialogowe, ale nie naprawia automatycznie niepoprawnej struktury. Moja praktyczna zasada jest prosta: najpierw natywny HTML, później ARIA. Dodanie Żadne pojedyncze narzędzie nie odpowie wiarygodnie na pytanie, czy strona jest dostępna. Automatyczny skaner potrafi znaleźć brakujące atrybuty, problemy z kontrastem czy niektóre błędy formularza, ale nie oceni dobrze sensu tekstu alternatywnego ani tego, czy instrukcja jest zrozumiała. W narzędziach deweloperskich i popularnych audytach warto szukać wskazówek, ale nie traktować wyniku jako certyfikatu. Raport z zerową liczbą błędów automatycznych oznacza tylko, że narzędzie nie wykryło określonego zestawu problemów. Nie jest dowodem pełnej zgodności z WCAG. Dobrym rozwiązaniem jest włączenie testów dostępności do CI, czyli procesu automatycznie sprawdzającego kod przy każdym wdrożeniu. Testy komponentów mogą wykryć regresję w etykietach lub rolach, natomiast ręczna kontrola nadal pozostaje konieczna dla całych scenariuszy użytkownika. WCAG jest standardem technicznym, a nie polską ustawą. Obowiązek stosowania konkretnych wymagań wynika z rodzaju podmiotu, oferowanej usługi, umowy albo przepisów sektorowych. Dlatego przed wpisaniem w specyfikacji „strona zgodna z WCAG” trzeba doprecyzować wersję standardu, poziom i zakres badania. W Polsce podmioty publiczne podlegają ustawie o dostępności cyfrowej stron internetowych i aplikacji mobilnych. Wymagania są powiązane z WCAG 2.1 na poziomie AA oraz normą EN 301 549. Przy nowych projektach w 2026 roku rozsądnie jest projektować z uwzględnieniem WCAG 2.2, ale formalne wymagania konkretnego zamówienia lub instytucji trzeba sprawdzić osobno. Od 28 czerwca 2025 roku obowiązuje także Polski Akt o Dostępności, który obejmuje wybrane produkty i usługi gospodarcze, między innymi część usług handlu elektronicznego. Nie dotyczy on automatycznie każdej małej strony firmowej, a mikroprzedsiębiorcy świadczący usługi są objęci określonymi wyłączeniami. Analiza prawna zależy od modelu biznesowego, więc sam fakt użycia WCAG nie przesądza jeszcze o wszystkich obowiązkach. W wielu projektach największe problemy nie wynikają z trudnej technologii, lecz z kilku decyzji podjętych na skróty. Poprawa tych elementów często daje większy efekt niż instalowanie kolejnej wtyczki audytowej. Przestrzegam szczególnie przed nakładkami dostępności, które obiecują zgodność po dodaniu jednego skryptu. Mogą poprawić pojedyncze przypadki, lecz nie zastąpią semantycznego kodu, poprawnej logiki fokusu ani testów z użytkownikami. Dostępność powinna być cechą komponentu już na etapie projektowania, tak samo jak responsywność czy wydajność. Zacząłbym od kilku prostych decyzji zapisanych w systemie projektowym. Ustaliłbym style fokusu, minimalne rozmiary kontrolek, kontrast kolorów, hierarchię nagłówków oraz zachowanie formularzy. Dzięki temu dostępność nie zależy od pamięci pojedynczego programisty. Każdy komponent warto opisać nie tylko wyglądem, lecz także zachowaniem. Dla przycisku trzeba określić stan aktywny, nieaktywny i fokus, dla modala sposób wejścia i wyjścia, a dla pola formularza relację między etykietą, instrukcją i błędem. Najtańszy moment na poprawę dostępności to projektowanie komponentu, nie przebudowa gotowego serwisu. Na końcu sprawdziłbym trzy reprezentatywne ścieżki, na przykład wyszukiwanie, zakup i kontakt. Jeżeli użytkownik może wykonać je klawiaturą, przy powiększeniu, z czytnikiem ekranu i bez polegania wyłącznie na kolorze, projekt ma solidną bazę do dalszego audytu. Najkrótsza odpowiedź brzmi: WCAG to praktyczny standard opisujący, jak tworzyć treści i interfejsy dostępne dla możliwie szerokiego grona użytkowników. Dla większości projektów sensownym kierunkiem jest WCAG 2.2 na poziomie AA, uzupełnione o testy manualne i konsultacje z użytkownikami. Nie trzeba przebudowywać całej aplikacji w jeden weekend. Najlepiej zacząć od semantycznego HTML, klawiatury, formularzy, kontrastu i komunikatów o stanie, a potem sukcesywnie obejmować dostępnością kolejne komponenty. Taki proces poprawia nie tylko zgodność ze standardem, lecz także jakość korzystania ze strony na telefonie, przy słabym łączu i w codziennych, mniej idealnych warunkach., a nie klikalnego i pomaga poruszać się po stronie, a powiązanie z polem wskazuje użytkownikowi, czego oczekuje formularz.Obrazy, multimedia i kolor
alt. Grafika dekoracyjna zwykle potrzebuje pustego alt="", aby czytnik ekranu jej nie odczytywał. Tekst „zdjęcie” nie pomaga, bo nie wyjaśnia, co rzeczywiście znajduje się na obrazie.Klawiatura, fokus i działanie bez myszy
JavaScript i ARIA z umiarem
role="button" do elementu div nie zapewni obsługi klawiaturą, zarządzania fokusem ani właściwego stanu. Wszystko to trzeba dopisać i przetestować.Jak sprawdzić dostępność strony krok po kroku
Dostępność a przepisy w Polsce
Najczęstsze błędy, które da się usunąć szybko
Od czego zacząć w nowym projekcie frontendowym
Dostępna strona zaczyna się od decyzji, nie od raportu
