Projektowanie strony zgodnej z WCAG polega na stosowaniu kilku prostych zasad już na etapie UX, designu i kodu. Dla początkujących oznacza to: poprawny kontrast, logiczną strukturę treści, obsługę klawiaturą i czytelny HTML.
Jeśli tworzysz stronę w WordPressie, sklep e-commerce lub prosty landing, da się osiągnąć podstawową zgodność z WCAG bez specjalistycznych narzędzi. Wystarczy wiedzieć, na czym się skupić i czego nie psuć.
Ten artykuł pokazuje praktyczne minimum WCAG – co zrobić, aby strona była używalna dla osób z niepełnosprawnościami i jednocześnie bezpieczna pod kątem wymagań prawnych.
Szybkie podsumowanie
- Kontrast tekstu do tła musi wynosić min. 4.5:1
- Strona musi działać bez myszy – pełna obsługa klawiaturą
- Poprawna struktura nagłówków (h2-h6)
- Linki i przyciski mają jasny, opisowy tekst
- Obrazy informacyjne mają atrybut alt
- Formularze mają etykiety label
- Ruchome elementy można zatrzymać
Kontekst problemu
WCAG dotyczy nie tylko instytucji publicznych. W praktyce obejmuje też sklepy internetowe, serwisy firmowe i aplikacje webowe, szczególnie jeśli są dostępne publicznie.
Dla projektanta lub właściciela strony problemem nie jest cała specyfikacja WCAG, tylko nieświadome łamanie podstaw – przez design, motywy WordPressa lub gotowe komponenty.
Najczęstszy scenariusz: strona wygląda dobrze wizualnie, ale jest nieczytelna dla czytników ekranu lub nie da się jej obsłużyć bez myszy.
Kluczowe zasady dostępności WCAG
Kontrast i czytelność
Jeśli tekst ma niski kontrast, osoba słabowidząca go nie odczyta. Minimalny kontrast to 4.5:1 dla zwykłego tekstu i 3:1 dla dużego.
W praktyce oznacza to unikanie jasnoszarego tekstu na białym tle i tekstu na zdjęciach bez tła.
Struktura nagłówków
Nagłówki budują logiczną strukturę strony. Czytniki ekranu poruszają się po nich, nie po wyglądzie.
Nie pomijaj poziomów. Jeśli zaczynasz od h2, kolejny poziom to h3, nie h4.
Obsługa klawiaturą
Każdy element interaktywny musi być dostępny z klawiatury (Tab, Enter, Escape).
Jeśli nie widzisz fokusu klawiatury, to użytkownik też nie. Widoczny focus jest obowiązkowy.
Teksty linków i przycisków
Link „kliknij tutaj” nie mówi nic czytnikowi ekranu.
Tekst linku ma opisywać cel, np. „Sprawdź ofertę hostingu”.
Obrazy i multimedia
Obraz przekazujący informację musi mieć alt. Dekoracyjny – pusty alt.
Jeśli wideo ma dźwięk, napisy są konieczne.
Formularze
Każde pole formularza musi mieć powiązaną etykietę label.
Błąd formularza powinien być opisany tekstem, nie tylko kolorem.
Zastosowanie w praktyce
- Sprawdź kontrast tekstu i przycisków (np. narzędzia online).
- Zweryfikuj strukturę nagłówków w kodzie, nie wizualnie.
- Przejdź stronę tylko klawiaturą – bez myszy.
- Sprawdź alt w najważniejszych obrazach.
- Przetestuj formularze przy błędnym wypełnieniu.
To ma sens, jeśli budujesz nową stronę lub aktualizujesz motyw.
To nie wystarczy, jeśli serwis ma złożone komponenty JS bez kontroli dostępności.
Najczęstsze błędy
- Tekst jako grafika – czytnik ekranu go nie odczyta
- Niski kontrast przycisków – elementy stają się niewidoczne
- Brak fokusu klawiatury – strona jest nieobsługiwalna
- Placeholder zamiast label – formularz traci kontekst
- Ikony bez tekstu – brak informacji o funkcji
- Animacje bez pauzy – problem dla osób z nadwrażliwością
Rekomendacje i dobre praktyki
To działa, jeśli traktujesz dostępność jako część UX, nie dodatek po fakcie.
Unikaj gotowych komponentów, gdy nie wiesz, jak działają z klawiaturą.
Jeśli korzystasz z WordPressa, wybieraj motywy deklarujące podstawową zgodność z WCAG i testuj je samodzielnie.
- Sprawdź kontrast wszystkich fontów
- Zachowaj logiczną hierarchię nagłówków
- Zapewnij widoczny focus
- Opisz linki i przyciski
- Uzupełnij alt w obrazach informacyjnych
- Nie polegaj wyłącznie na kolorze
Podsumowanie – co dalej
- Podstawy WCAG są osiągalne dla początkujących
- Dostępność realnie wpływa na UX i SEO
- Najwięcej problemów powoduje brak testów
Jeśli już masz stronę, przejdź ją klawiaturą i sprawdź kontrast. To najszybszy punkt startowy.
FAQ
Czy każda strona musi być zgodna z WCAG?
Prawnie obowiązek zależy od typu podmiotu, ale technicznie dostępność poprawia użyteczność każdej strony.
W e-commerce i SEO jest to realna przewaga.
Czy WCAG spowalnia projektowanie?
Nie, jeśli uwzględnisz je od początku.
Najwięcej czasu traci się na poprawki w gotowych projektach.
Czy plugin WCAG do WordPressa wystarczy?
Nie. Plugin może pomóc, ale nie naprawi złej struktury HTML, kontrastu ani UX.
Dostępność zaczyna się od projektu i kodu.