Dostępność stron WCAG 2026 – co musisz wiedzieć

Dostępność cyfrowa nie jest już opcjonalna

28 czerwca 2025 roku weszła w życie Europejska Dyrektywa o Dostępności (European Accessibility Act – EAA). Od tego momentu dostępność cyfrowa to nie kwestia dobrej woli, ale obowiązek prawny dla wielu firm w Polsce i całej Unii Europejskiej. Kary za nieprzestrzeganie przepisów mogą sięgać dziesiątek tysięcy złotych.

Ale dostępność to nie tylko prawo. W Polsce żyje ponad 4 miliony osób z różnymi niepełnosprawnościami. Dodaj do tego osoby starsze, użytkowników z tymczasowymi ograniczeniami (złamana ręka, operacja oczu) i tych korzystających z internetu w niesprzyjających warunkach (jasne słońce, hałaśliwe otoczenie). Dostępna strona to po prostu strona, która działa lepiej dla wszystkich.

European Accessibility Act – kogo dotyczy i co grozi za niespełnienie wymagań

EAA obejmuje usługi cyfrowe oferowane konsumentom, w tym strony internetowe i aplikacje mobilne firm prowadzących działalność handlową. W praktyce dotyczy to sklepów internetowych, bankowości elektronicznej, usług transportowych, telekomunikacyjnych i audiowizualnych.

Wyłączenia dotyczą mikroprzedsiębiorstw (poniżej 10 pracowników i obrót do 2 mln euro), ale tylko w zakresie usług – nie produktów. Jeśli Twoja firma nie mieści się w definicji mikroprzedsiębiorstwa i oferuje usługi online konsumentom, EAA najprawdopodobniej Cię dotyczy.

W Polsce implementację dyrektywy reguluje Ustawa o zapewnianiu dostępności. Organy nadzoru mogą nakładać kary finansowe, a osoby z niepełnosprawnościami zyskują prawo do składania skarg i żądania zapewnienia dostępności. Warto działać proaktywnie zamiast czekać na pierwszą kontrolę.

WCAG 2.2 – standard, który musisz znać

Web Content Accessibility Guidelines (WCAG) 2.2 to międzynarodowy standard dostępności cyfrowej opracowany przez W3C. EAA odwołuje się do normy EN 301 549, która z kolei bazuje na WCAG 2.1 na poziomie AA. W praktyce spełnienie WCAG 2.2 AA daje solidną podstawę zgodności z prawem.

Standard opiera się na czterech zasadach – treść musi być postrzegalna, funkcjonalna, zrozumiała i solidna technicznie (POUR – Perceivable, Operable, Understandable, Robust). Brzmi abstrakcyjnie, ale przekłada się na bardzo konkretne wymagania techniczne.

WCAG 2.2 wprowadził kilka nowych kryteriów w porównaniu do wersji 2.1. Najważniejsze to minimalna wielkość elementów interaktywnych (24×24 piksele CSS), brak pułapek fokusa w rozszerzonych komponentach, dostępna pomoc i spójne mechanizmy nawigacji. Jeśli Twoja strona spełniała WCAG 2.1 AA, aktualizacja do 2.2 nie wymaga rewolucji.

Kontrast i kolory – żeby każdy mógł przeczytać

Minimum kontrastu dla tekstu to 4.5:1 dla normalnego tekstu i 3:1 dla tekstu dużego (powyżej 18pt lub 14pt bold). Brzmi technicznie, ale w praktyce oznacza to jedno – jasnoszary tekst na białym tle odpada.

Częste błędy to: jasne kolory przycisków CTA z białym napisem, szare teksty pomocnicze (placeholdery formularzy, stopka), informacje przekazywane wyłącznie kolorem (np. czerwone pole = błąd, bez dodatkowego komunikatu tekstowego). Narzędzie WebAIM Contrast Checker pozwala sprawdzić dowolną kombinację kolorów w kilka sekund.

Nie polegaj wyłącznie na kolorze do przekazywania informacji. Jeśli pole formularza jest błędnie wypełnione, oprócz czerwonej ramki dodaj ikonę ostrzeżenia i tekstowy komunikat błędu. Osoby z daltonizmem (8% mężczyzn) mogą nie rozróżniać czerwieni od zieleni.

Teksty alternatywne – obrazy muszą mówić

Atrybut alt w znaczniku img to podstawa dostępności i jednocześnie element, który większość stron robi źle. Każdy obraz niosący treść musi mieć opisowy tekst alternatywny. Obrazy dekoracyjne powinny mieć pusty alt (alt=””), żeby czytnik ekranu je pomijał.

Dobry tekst alternatywny opisuje funkcję obrazu, nie jego wygląd. Zamiast „zdjęcie kobiety” napisz „klientka korzystająca z aplikacji mobilnej sklepu”. Zamiast „logo firmy” napisz „KapitanWeb – strony internetowe i sklepy”. Dla wykresów i infografik podaj kluczowe dane w tekście alt lub w opisie pod obrazem.

WordPress ułatwia dodawanie alt tekstów – pole „Tekst alternatywny” pojawia się automatycznie przy każdym dodawanym obrazie w bibliotece mediów. Problem w tym, że wiele osób zostawia to pole puste. Warto przejrzeć całą bibliotekę mediów i uzupełnić brakujące opisy – to poprawia nie tylko dostępność, ale też pozycjonowanie strony.

Nawigacja klawiaturą – nie każdy używa myszki

Osoby niewidome, osoby z ograniczeniami ruchowymi i zaawansowani użytkownicy nawigują po stronach wyłącznie klawiaturą. Twoja strona musi być w pełni obsługiwalna za pomocą klawisza Tab (przechodzenie między elementami), Enter (aktywacja), Escape (zamykanie) i strzałek.

Najczęstsze problemy to: niewidoczny fokus (outline: none w CSS – jeden z najgorszych antywzorców dostępności), pułapki fokusa (modal, z którego nie da się wyjść tabem), elementy interaktywne niedostępne z klawiatury (onclick na div zamiast na button), nieintuicyjna kolejność fokusa.

Prosty test – odłóż myszkę i spróbuj przejść przez całą stronę samym Tabem. Czy widzisz, który element jest aktywny? Czy możesz otworzyć menu, wypełnić formularz, dodać produkt do koszyka? Jeśli gdziekolwiek utkniesz, Twoja strona ma problem z dostępnością.

ARIA – kiedy HTML nie wystarcza

ARIA (Accessible Rich Internet Applications) to zestaw atrybutów HTML, które przekazują dodatkowe informacje czytnikom ekranu. Pierwsza zasada ARIA brzmi: nie używaj ARIA, jeśli możesz użyć natywnego elementu HTML. Przycisk powinien być elementem button, nie div z role=”button”.

Gdzie ARIA jest naprawdę potrzebna? W dynamicznych komponentach, których natywny HTML nie obsługuje – tabs, accordions, modalne okna dialogowe, live regions (obszary aktualizowane dynamicznie, np. licznik koszyka). Atrybuty takie jak aria-expanded, aria-hidden, aria-label i aria-live informują czytnik ekranu o stanie i zachowaniu tych elementów.

Źle użyte ARIA jest gorsze niż brak ARIA. Atrybut aria-label nadpisuje widoczny tekst elementu dla czytników ekranu – jeśli przycisk ma tekst „Wyślij” i aria-label=”Kliknij tutaj”, czytnik powie „Kliknij tutaj”, co jest mniej informacyjne. Używaj ARIA świadomie i testuj z prawdziwym czytnikiem ekranu.

Formularze – najczęstsze źródło problemów z dostępnością

Formularze kontaktowe, rejestracyjne i zamówieniowe to miejsca, w których błędy dostępności kosztują najwięcej – dosłownie, bo uniemożliwiają konwersję. Każde pole formularza musi mieć powiązaną etykietę (label z atrybutem for wskazującym na id pola). Placeholder nie jest zamiennikiem etykiety – znika po rozpoczęciu wpisywania.

Komunikaty o błędach muszą być konkretne („Numer telefonu musi zawierać 9 cyfr”, nie „Nieprawidłowa wartość”), powiązane z polem za pomocą aria-describedby i ogłaszane przez czytnik ekranu (aria-live=”polite”). Grupuj powiązane pola za pomocą fieldset i legend – np. „Adres dostawy” jako legenda dla grupy pól z ulicą, miastem i kodem pocztowym.

CAPTCHA to poważna bariera dostępności. Wizualna CAPTCHA jest niemożliwa do rozwiązania dla osób niewidomych. Rozwiązaniem jest reCAPTCHA v3, która działa w tle bez interakcji użytkownika, lub honeypot – ukryte pole, które wypełniają tylko boty.

Multimedia – wideo i audio też muszą być dostępne

Filmy na stronie muszą mieć napisy (captions) dla osób niesłyszących i audiodeskrypcję dla osób niewidomych. YouTube automatycznie generuje napisy, ale ich jakość bywa niska – warto je przejrzeć i poprawić. Ręczne napisy w formacie SRT/VTT dają najlepsze rezultaty.

Odtwarzacz wideo musi być obsługiwalny z klawiatury – play/pause, regulacja głośności, włączanie napisów. Natywny element HTML5 video spełnia te wymagania, ale wiele customowych playerów już nie. Autoplay z dźwiękiem to nie tylko irytujące, ale też problematyczne dla dostępności – użytkownik czytnika ekranu może nie wiedzieć, skąd dochodzi dźwięk.

Narzędzia do testowania dostępności

Automatyczne narzędzia wykrywają około 30-40% problemów z dostępnością. Reszta wymaga ręcznego testowania. Ale ten automatyczny audit to dobry punkt wyjścia.

WAVE (Web Accessibility Evaluation Tool) – darmowe rozszerzenie do Chrome i Firefox. Nakłada na stronę kolorowe ikony wskazujące błędy, ostrzeżenia i elementy strukturalne. Intuicyjne i szybkie.

axe DevTools – rozszerzenie do Chrome od Deque Systems. Bardziej techniczne niż WAVE, daje precyzyjne informacje o naruszeniach WCAG z odniesieniami do konkretnych kryteriów. Wersja darmowa pokrywa podstawowe testy.

Lighthouse – wbudowany w Chrome DevTools. Audit dostępności to jedna z kategorii obok wydajności i SEO. Nie jest tak szczegółowy jak WAVE czy axe, ale daje szybki przegląd. Jeśli prowadzisz stronę na WordPressie, w artykule o Core Web Vitals znajdziesz więcej o korzystaniu z Lighthouse.

Ręczne testy to klucz do pełnej oceny. Nawigacja klawiaturą, powiększenie strony do 200%, test z czytnikiem ekranu (NVDA jest darmowy na Windows, VoiceOver jest wbudowany w macOS i iOS). Poproś osobę z niepełnosprawnością o przetestowanie strony – żaden automatyczny tool nie zastąpi perspektywy rzeczywistego użytkownika.

WordPress i dostępność – praktyczne wskazówki

WordPress jako platforma ma wbudowane podstawy dostępności – system zarządzania mediami z polami alt, semantyczna struktura nagłówków w edytorze, obsługa skip links w większości motywów. Problem w tym, że motywy i wtyczki zewnętrzne często te fundamenty niszczą.

Przy wyborze motywu szukaj oznaczenia „accessibility-ready” w repozytorium WordPress.org. Te motywy przeszły przegląd dostępności i spełniają podstawowe wymagania. Popularne motywy takie jak GeneratePress, Flavflavor czy Flavor mają dobre wsparcie dostępności, ale nadal wymagają poprawnej konfiguracji.

Wtyczki typu page builder (Elementor, WPBakery, Divi) generują dodatkowe warstwy HTML, które mogą pogarszać dostępność. Jeśli ich używasz, testuj wynikowy kod – nie wystarczy, że edytor wizualny wygląda dobrze. Natywny edytor Gutenberg generuje czystszy, bardziej semantyczny HTML.

Zadbaj o bezpieczeństwo strony jednocześnie z dostępnością – captcha, dwuetapowa weryfikacja i inne mechanizmy bezpieczeństwa muszą być obsługiwalne przez osoby z niepełnosprawnościami.

Najczęstsze błędy dostępności na polskich stronach

Po analizie setek polskich stron internetowych powtarzają się te same problemy. Brakujące alt teksty – to absolutny numer jeden. Niedostateczny kontrast – szczególnie w modnych, minimalistycznych designach z jasnoszarą typografią. Brak etykiet formularzy – placeholdery zamiast labeli. Pułapki fokusa w modalach i menu mobilnym. Brak skip linku (mechanizmu pomijania nawigacji).

Zaskakująco dużo problemów wynika z plików PDF. Firmy publikują regulaminy, cenniki i oferty w formacie PDF, który jest zeskanowanym obrazem – czytnik ekranu widzi pustą stronę. Jeśli publikujesz PDF-y, upewnij się, że są to dokumenty tekstowe z prawidłową strukturą nagłówków i tagów.

Dostępność jako przewaga konkurencyjna

Dostępna strona to nie obciążenie, ale inwestycja. Poprawienie dostępności prawie zawsze poprawia też ogólne UX – czytelniejsze fonty, lepsze kontrasty, prostsze formularze, szybsza nawigacja. To przekłada się na wyższe konwersje i lepsze pozycje w Google, bo wiele kryteriów WCAG pokrywa się z czynnikami rankingowymi.

Zamiast traktować dostępność jako jednorazowy projekt, wbuduj ją w proces tworzenia i aktualizacji strony. Każda nowa podstrona, każdy nowy wpis blogowy, każda zmiana w szablonie powinna przechodzić podstawowy test dostępności. Z czasem stanie się to nawykiem – tak naturalnym jak sprawdzanie, czy strona wyświetla się poprawnie na telefonie.