Wyobraź sobie, że co piąty klient, który trafia na Twoją stronę, nie może z niej skorzystać. Nie dlatego, że nie ma internetu ani urządzenia — ale dlatego, że Twoja strona nie jest zaprojektowana z myślą o jego potrzebach. Osoba niewidoma używająca czytnika ekranu. Osoba z drżeniem rąk, która nie może precyzyjnie kliknąć małego przycisku. Starszy klient, dla którego tekst jest za mały i za mało kontrastowy.

Według danych Światowej Organizacji Zdrowia ok. 16% populacji świata żyje z jakąś formą niepełnosprawności. W Polsce to ponad 5 milionów osób. Każda z nich jest potencjalnym klientem — o ile jej to umożliwisz.

Dostępna strona WordPress to nie fanaberia ani zarezerwowany dla wielkich korporacji obowiązek prawny. To sposób myślenia o stronie internetowej, który przynosi korzyści wszystkim użytkownikom — i który coraz wyraźniej staje się standardem rynkowym oraz wymogiem regulacyjnym w Europie.

Ten przewodnik pokaże Ci, jak wdrożyć dostępność na stronie WordPress krok po kroku — od zrozumienia wytycznych, przez testowanie, aż po konkretne działania techniczne.

Dlaczego dostępna strona WordPress to dziś konieczność?

Argument prawny — regulacje zaciskają się

Europejska Ustawa o Dostępności (ang. EAA — European Accessibility Act) — dyrektywa unijna 2019/882 — weszła w życie w czerwcu 2025 roku. Obejmuje szeroki zakres produktów i usług cyfrowych, w tym strony internetowe i aplikacje mobilne firm działających na rynku europejskim.

Co to oznacza praktycznie? Właściciele małych firm oferujących usługi przez internet — sklepy, platformy rezerwacji, serwisy informacyjne — zobowiązani są do zapewnienia dostępności swoich cyfrowych punktów kontaktu. Sankcje za brak zgodności zależą od kraju wdrożenia, ale ryzyko prawne jest realne.

Wcześniej, od 2019 roku, Ustawa o dostępności cyfrowej (implementacja europejskiej dyrektywy 2016/2102) objęła podmioty publiczne w Polsce — urzędy, szkoły, szpitale. Sektor prywatny jest kolejny.

Argument ekonomiczny — dotykasz większej grupy klientów

Dostępność to nie kwestia dobroczynności — to kwestia zasięgu rynkowego. Osoby z niepełnosprawnościami dysponują realną siłą nabywczą. Organizacja Anysurfer szacuje, że niedostępne strony tracą globalnie setki miliardów dolarów rocznie w niezrealizowanych transakcjach od użytkowników, którzy nie mogli sfinalizować zakupu lub skontaktować się z firmą.

Argument SEO — dostępność i pozycjonowanie idą w parę

Wyszukiwarki i czytniki ekranu (ang. screen readers — programy odczytujące treść strony dla osób niewidomych) korzystają z podobnych mechanizmów rozumienia treści. Dobrze opisane obrazy, prawidłowa hierarchia nagłówków, teksty alternatywne, czytelna struktura dokumentu — to elementy, które równolegle poprawiają dostępność i wzmacniają pozycjonowanie w wyszukiwarkach.

Dostępna strona WordPress jest jednocześnie bardziej przyjazna robotom Google.

Filar 1: Wytyczne WCAG — co musisz rozumieć jako właściciel firmy

WCAG (ang. Web Content Accessibility Guidelines — Wytyczne dotyczące dostępności treści internetowych) to zestaw międzynarodowych standardów dostępności opracowanych przez organizację W3C (ang. World Wide Web Consortium — konsorcjum standaryzujące technologie internetowe). To dokument techniczny, który przekłada się na konkretne wymagania dotyczące Twojej strony.

Cztery zasady POUR — fundament dostępności

Całość wytycznych WCAG opiera się na czterech fundamentalnych zasadach, tworzących akronim POUR:

P — Postrzegalność (ang. Perceivable)
Każda treść musi być dostępna dla zmysłów użytkownika — wzroku, słuchu lub dotyku. Jeśli informacja jest przekazywana wyłącznie przez kolor (np. „pola zaznaczone na czerwono są wymagane”), osoba z daltonizmem jej nie odczyta. Jeśli film nie ma napisów, osoba niesłysząca traci dostęp do treści dźwiękowej.

O — Obsługiwalność (ang. Operable)
Użytkownik musi móc obsłużyć każdy element strony — nie tylko myszką, ale też klawiaturą, przełącznikiem (ang. switch — urządzenie wspomagające dla osób z ograniczoną sprawnością rąk) czy sterowaniem głosowym. Jeśli do czegoś można dotrzeć tylko przez kliknięcie myszką — jest to poza zasięgiem wielu użytkowników.

U — Zrozumiałość (ang. Understandable)
Treść i sposób działania interfejsu muszą być jasne. Komunikat błędu „Błąd 422″ nic nie wyjaśnia. „Proszę podać adres e-mail w poprawnym formacie, np. jan@firma.pl” — wyjaśnia wszystko.

R — Rzetelność (ang. Robust)
Strona musi działać poprawnie z różnymi technologiami wspomagającymi (ang. assistive technologies) — czytnikami ekranu, powiększalnikami, starszymi przeglądarkami. Solidny, semantyczny kod HTML zapewnia tę zgodność.

Poziomy zgodności z WCAG

WCAG definiuje trzy poziomy wymagań:

Twój cel: zgodność z WCAG 2.1 na poziomie AA. To realistyczny standard dla małej firmy i jednocześnie wymagany przez przepisy europejskie.

Kluczowe wymagania WCAG 2.1 AA — co konkretnie musisz spełnić?

Poniżej lista najważniejszych wymagań przełożona na język praktyczny, bez żargonu technicznego:

Kontrast kolorów (kryterium 1.4.3)
Tekst musi mieć odpowiednio wysoki kontrast względem tła. Minimum dla tekstu normalnej wielkości: współczynnik kontrastu 4,5:1. Dla tekstu dużego (powyżej 18 punktów lub 14 punktów pogrubionego): 3:1. Jasnoszary tekst na białym tle prawie na pewno tego nie spełnia.

Tekst alternatywny dla obrazów (kryterium 1.1.1)
Każdy obraz przekazujący informację musi mieć tekst alternatywny (ang. alt text), który czytnik ekranu odczyta użytkownikowi niewidomemu. Obrazy dekoracyjne powinny mieć pusty atrybut alt (alt=""), żeby czytnik ekranu je pominął.

Napisy dla treści wideo i audio (kryterium 1.2.2)
Każde nagranie wideo z dźwiękiem musi mieć napisy (ang. captions). Materiały tylko audio (np. podcasty) muszą mieć transkrypcję (ang. transcript — tekstowy zapis nagrania).

Obsługa klawiaturą (kryterium 2.1.1)
Każda funkcja strony — nawigacja, formularze, przyciski, menu rozwijane — musi być dostępna wyłącznie z klawiatury, bez użycia myszy.

Widoczny wskaźnik fokusa (kryterium 2.4.7)
Gdy użytkownik porusza się po stronie klawiaturą, musi zawsze widzieć, który element jest aktualnie aktywny. Widoczny wskaźnik fokusa (ang. focus indicator — ramka lub podświetlenie wokół aktywnego elementu) to obowiązek — nie opcja stylizacyjna.

Linki pomijania nawigacji (kryterium 2.4.1)
Na początku strony musi znajdować się ukryty link „Przejdź do treści głównej” (ang. skip navigation link — link pozwalający ominąć nawigację), który staje się widoczny po wciśnięciu klawisza Tab. Pozwala użytkownikom czytników ekranu i klawiatury pominąć powtarzające się menu na każdej podstronie.

Etykiety formularzy (kryterium 1.3.1 i 3.3.2)
Każde pole formularza musi mieć powiązaną etykietę (ang. label — opisową nazwę pola). Tekst zastępczy w polu (ang. placeholder — wskazówka wyświetlana wewnątrz pustego pola) nie jest etykietą — znika, gdy użytkownik zaczyna pisać, i nie jest odczytywany przez wszystkie czytniki ekranu.

Hierarchia nagłówków (kryterium 1.3.1)
Strona musi mieć logiczną strukturę nagłówków: jeden H1 jako tytuł główny, następnie H2 dla sekcji głównych, H3 dla podsekcji. Nagłówków nie używamy do stylizacji wizualnej (np. „chcę większy tekst, to wstawię H2″) — używamy ich do struktury dokumentu.

Nazwa strony w tytule (kryterium 2.4.2)
Każda podstrona musi mieć unikalny i opisowy tytuł (tag <title>) — nie „Strona” ani „Witamy”, ale „Kontakt — Firma XYZ” lub „Jak zamawiać — Sklep ABC”.

Filar 2: Narzędzia testujące — jak sprawdzić dostępność swojej strony?

Dobra wiadomość: wiele narzędzi do testowania dostępności jest bezpłatnych i nie wymaga wiedzy technicznej. Zła wiadomość: żadne automatyczne narzędzie nie wyłapie wszystkich problemów — szacuje się, że automatyczne testy wykrywają ok. 30–40% naruszeń WCAG. Reszta wymaga ręcznego sprawdzenia.

Narzędzia automatyczne — szybki przegląd

WAVE (Web Accessibility Evaluation Tool — Narzędzie do Oceny Dostępności Stron Internetowych)
Bezpłatne narzędzie dostępne jako rozszerzenie przeglądarki (Chrome i Firefox) oraz przez stronę wave.webaim.org. Nakłada na stronę wizualną warstwę z kolorowymi ikonami wskazującymi błędy, ostrzeżenia i elementy wymagające ręcznego sprawdzenia.

Idealne dla właścicieli firm bez wiedzy technicznej — ikony i opisy są zrozumiałe, linki prowadzą do wyjaśnień każdego problemu.

Jak używać:

1. Zainstaluj rozszerzenie WAVE w przeglądarce
2. Wejdź na swoją stronę WordPress
3. Kliknij ikonę rozszerzenia
4. Czerwone ikony = błędy do naprawy natychmiast
5. Żółte ikony = ostrzeżenia wymagające ręcznej oceny
6. Niebieskie ikony = elementy struktury (do weryfikacji, nie zawsze błędy)

axe DevTools (Narzędzia Deweloperskie axe)
Rozszerzenie przeglądarki od firmy Deque — jedno z najbardziej precyzyjnych narzędzi automatycznego testowania. Wersja bezpłatna zintegrowana z narzędziami deweloperskimi przeglądarki (zakładka „axe DevTools” po zainstalowaniu). Wersja Pro (płatna) oferuje więcej reguł i integrację z narzędziami do zarządzania projektami.

Wyróżnik: bardzo niski współczynnik fałszywych alarmów (ang. false positives) — jeśli axe zgłasza błąd, z bardzo dużym prawdopodobieństwem to faktyczny problem.

Google Lighthouse (Latarnia Morska Google)
Wbudowane narzędzie audytowe w przeglądarce Chrome — dostępne bez instalacji. Otwórz Narzędzia Deweloperskie (klawisz F12), zakładka „Lighthouse”, wybierz kategorię „Dostępność” i kliknij „Analizuj stronę”.

Wynik w skali 0–100, podzielony na kategorie. Nie traktuj wyniku 100 jako certyfikatu pełnej zgodności — to ocena automatyczna. Ale wynik poniżej 80 to wyraźny sygnał, że coś wymaga pilnej uwagi.

Accessibility Checker przez wtyczkę WordPress
Wtyczka Accessibility Checker (od Equalize Digital) skanuje treść bezpośrednio w panelu administracyjnym WordPress przy każdym zapisaniu wpisu lub strony. Wyświetla listę błędów i ostrzeżeń tuż pod edytorem — bez wychodzenia z panelu i bez wiedzy technicznej.

Bezpłatna wersja sprawdza podstawowe reguły. Wersja Pro (ok. 290 dolarów rocznie) oferuje pełny zestaw reguł WCAG.

Narzędzia do testowania kontrastu kolorów

WebAIM Contrast Checker (Sprawdzacz Kontrastu WebAIM)
Strona contrast.webaim.org — wprowadzasz kod koloru tekstu i tła, dostajesz informację o współczynniku kontrastu i czy spełnia wymogi WCAG AA i AAA. Bezpłatny, bez instalacji.

Colour Contrast Analyser (Analizator Kontrastu Kolorów)
Bezpłatna aplikacja desktopowa od TPGi. Pozwala próbkować kolory bezpośrednio z ekranu — przydatne gdy nie znasz kodu koloru elementu na stronie.

Funkcja sprawdzania kontrastu w Figmie
Jeśli Twój projektant graficzny używa Figmy — wtyczka Contrast sprawdza kontrast bezpośrednio w projekcie, zanim trafi on do wdrożenia. Lepiej wykryć problem na etapie projektu niż po publikacji.

Czytniki ekranu — testowanie z perspektywy użytkownika

Żadne automatyczne narzędzie nie zastąpi przetestowania strony z perspektywy osoby niewidomej. Czytniki ekranu to programy odczytujące treść strony na głos. Warto poświęcić godzinę na zapoznanie się z jednym z nich:

NVDA (ang. NonVisual Desktop Access — Bezwizualny Dostęp do Komputera)
Bezpłatny czytnik ekranu dla Windows. Najpopularniejszy wśród użytkowników z niepełnosprawnością wzroku w Polsce i Europie. Pobierz ze strony nvaccess.org.

VoiceOver
Wbudowany czytnik ekranu w systemach macOS i iOS — bez instalacji, aktywowany skrótem klawiszowym. Dobry do testowania na urządzeniach Apple.

JAWS (ang. Job Access With Speech — Dostęp do Pracy za Pomocą Mowy)
Komercyjny czytnik ekranu dla Windows, najczęściej używany w środowiskach korporacyjnych. Licencja kosztuje kilka tysięcy złotych — nie kupujesz go do testów, ale warto wiedzieć o jego istnieniu.

Jak przetestować stronę czytnikiem ekranu:

1. Wyłącz monitor lub zamknij oczy
2. Użyj wyłącznie klawiatury i czytnika
3. Spróbuj: przejrzeć stronę główną, znaleźć ofertę, wypełnić formularz kontaktowy
4. Każde miejsce, w którym jesteś zdezorientowany, to potencjalny problem dostępności

Wtyczka do automatycznych testów w WordPress

WP Accessibility (Dostępność WordPress)
Wtyczka Joe Dolce’a — jedna z najdłużej aktywnych wtyczek poprawiających dostępność WordPress. Automatycznie dodaje brakujące elementy: linki pomijania nawigacji, wskaźniki fokusa, etykiety brakujące przy ikonach wyszukiwania i innych elementach interfejsu.

Bezpłatna, aktywnie rozwijana, kompatybilna z większością motywów.

Filar 3: Dostępne motywy WordPress — od czego zacząć?

Wybór motywu to fundament dostępnej strony WordPress. Zły motyw z licznymi naruszeniami WCAG wymusza naprawę setek problemów. Dobry motyw dostępny z założenia — daje Ci solidną bazę, na której budujesz.

Co sprawdzić przed wyborem motywu?

Certyfikat dostępności w katalogu WordPress.org
Wszystkie motywy w oficjalnym katalogu motywów WordPress.org muszą spełniać podstawowe wymogi dostępności jako warunek publikacji. Szukaj motywów z tagiem „accessibility-ready” (motyw gotowy pod dostępność) — to wstępna selekcja, nie gwarancja pełnej zgodności z WCAG AA.

Testy przed zakupem
Przed zakupem motywu premium: uruchom demo na stronie producenta przez narzędzie WAVE lub Lighthouse. Wynik poniżej 80 w kategorii dostępności w Lighthouse to czerwona flaga.

Dokumentacja producenta
Renomowani producenci motywów dostępnych wprost deklarują zgodność z WCAG i opisują, na jakim poziomie. Brak jakiejkolwiek wzmianki o dostępności w dokumentacji to znak, że temat nie był priorytetem.

Rekomendowane dostępne motywy WordPress

Twenty Twenty-Four i Twenty Twenty-Five (motywy domyślne WordPress)
Oficjalne motywy domyślne WordPress są rozwijane przez Automattic z myślą o dostępności i regularnie audytowane. Proste, wydajne, w pełni kompatybilne z Edytorem Bloków. Dobry punkt startowy, szczególnie jeśli nie masz budżetu na motyw premium.

Astra
Jeden z najpopularniejszych motywów WordPress z dobrą historią dostępności. Wersja bezpłatna obsługuje podstawowe scenariusze, wersja Pro (ok. 59 dolarów rocznie) oferuje zaawansowane opcje. Producent (Brainstorm Force) publikuje informacje o zgodności z WCAG.

GeneratePress
Lekki, szybki motyw z dobrym wynikiem dostępności. Kod jest czysty i semantyczny — to solidna baza do budowania dostępnej strony WordPress. Wersja bezpłatna pokrywa podstawowe potrzeby.

Kadence
Motyw z rosnącą popularnością i aktywnym rozwojem pod kątem dostępności. Wbudowane opcje dla wskaźnika fokusa, kontrastu i struktury nagłówków. Kompatybilny z Edytorem Bloków i wtyczką Kadence Blocks.

Blocksy
Nowoczesny motyw z blokowym podejściem do budowania strony. Producent aktywnie pracuje nad zgodnością z WCAG AA i regularnie wydaje aktualizacje poprawiające dostępność.

Czego unikać?

Motywów zbudowanych wyłącznie wokół efektów wizualnych
Animacje uruchamiające się automatycznie, treści wczytywane podczas przewijania (ang. scroll-triggered animations — animacje uruchamiane przy przewijaniu), paralaksa (ang. parallax — efekt głębi przy przewijaniu) — mogą powodować problemy dla osób z zaburzeniami przedsionkowymi i wrażliwością na ruch.

Motywów z menu dostępnym tylko po najechaniu myszką (ang. hover-only)
Menu rozwijane, które działa tylko po najechaniu kursorem, jest niedostępne dla użytkowników klawiatury i ekranów dotykowych.

Motywów bez deklaracji dostępności
Brak jakiejkolwiek informacji o dostępności w dokumentacji motywu premium to bardzo złe świadectwo.

Filar 4: Teksty alternatywne i nawigacja — praktyczne wdrożenie

To obszar, w którym właściciel firmy może zrobić naprawdę dużo samodzielnie, bez angażowania dewelopera.

Teksty alternatywne — jak je pisać poprawnie?

Tekst alternatywny (ang. alt text — skrót od alternative text) to opis obrazu dodawany w kodzie HTML przez atrybut alt. Czytnik ekranu odczytuje go użytkownikowi niewidomemu zamiast obrazu. Google używa go do indeksowania treści graficznej.

Jak dodać tekst alternatywny w WordPress:
W bibliotece mediów WordPress kliknij na obraz → pole „Tekst alternatywny” w panelu bocznym. W edytorze bloków: kliknij na blok z obrazem → zakładka „Blok” w prawym panelu → pole „Tekst alternatywny”.

Zasady pisania dobrych tekstów alternatywnych:

❌ Nie rób tego:

• alt="obrazek" — żadnej informacji
• alt="IMG_20231015_142233.jpg" — nazwa pliku
• alt="zdjęcie" — opisujesz typ, nie treść
• alt="logo logo firmy XYZ logo" — nadmiarowe powtórzenia

✅ Rób to:

• Opisuj treść i funkcję obrazu, nie jego wygląd
• Bądź zwięzły — 125 znaków to praktyczny limit
• Jeśli obraz zawiera tekst — przepisz ten tekst w alt
• Nie zacznij od „Obraz przedstawia…” — czytnik ekranu i tak powie „grafika”

Przykłady:

ŹRÓDŁE: zdjęcie produktu — buty trekkingowe
❌ alt="buty"
❌ alt="zdjęcie butów trekkingowych na białym tle"
✅ alt="Buty trekkingowe XYZ Trail Pro w kolorze szarym z pomarańczowymi akcentami"

ŹRÓDŁE: baner promocyjny z tekstem "-20% do końca tygodnia"
❌ alt="baner promocyjny"
❌ alt="promocja"
✅ alt="20% zniżki na wszystkie produkty — oferta ważna do niedzieli"

ŹRÓDŁE: ikona dekoracyjna przy nagłówku sekcji
✅ alt="" (pusty — obraz dekoracyjny, czytnik go pomija)

ŹRÓDŁE: zdjęcie zespołu firmy
❌ alt="team"
✅ alt="Trzyosobowy zespół firmy XYZ podczas spotkania roboczego w biurze"

Obrazy złożone — diagramy, wykresy, infografiki
Jeśli obraz przekazuje złożone informacje (np. wykres słupkowy z danymi sprzedażowymi), sam tekst alternatywny może nie wystarczyć. Dodaj opis w treści strony pod obrazem lub utwórz osobną stronę z pełnym opisem danych. Alternatywnie — użyj tabel HTML zamiast grafiki tam, gdzie to możliwe.

Nawigacja klawiaturą — jak sprawdzić i poprawić?

Nawigacja klawiaturą to zdolność do obsłużenia całej strony wyłącznie przy użyciu klawiatury, bez myszy.

Test podstawowy — zrób to teraz:

1. Otwórz swoją stronę
2. Kliknij w puste miejsce na stronie, żeby upewnić się, że fokus (punkt aktywności) jest na stronie
3. Naciskaj klawisz Tab — przechodzisz przez kolejne elementy interaktywne (linki, przyciski, pola formularzy)
4. Używaj klawiszy strzałek w menu, Enter do aktywacji linków i przycisków, Escape do zamykania menu
5. Pytania do sprawdzenia podczas testu:
   • Czy zawsze widzisz, który element jest aktywny?
   • Czy możesz dotrzeć do wszystkich linków i przycisków?
   • Czy kolejność Tab jest logiczna (lewa → prawa, góra → dół)?
   • Czy menu rozwijane daje się obsłużyć?
   • Czy formularze dają się wypełnić i wysłać?

Najczęstsze problemy z nawigacją klawiaturą w WordPress:

Problem 1: Brak widocznego wskaźnika fokusa
Wiele motywów usuwa domyślny niebieski obrys (ang. outline) wokół aktywnych elementów, bo „brzydko wygląda”. Dla użytkownika klawiatury to katastrofa — nie widzi, gdzie jest.

Rozwiązanie w CSS (arkusz stylów) motywu (lub dodatkowy CSS w panelu WordPress → Wygląd → Dostosuj → Dodatkowy CSS):

/* Przywróć i wzmocnij widoczny wskaźnik fokusa */
:focus {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
}

/* Dla nowoczesnych przeglądarek — jeszcze lepsza kontrola */
:focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
}

/* Ukryj obrys tylko dla kliknięć myszką (nie dla klawiatury) */
:focus:not(:focus-visible) {
    outline: none;
}

Problem 2: Pułapka fokusa (ang. focus trap)
Sytuacja, gdy fokus wchodzi do elementu (np. menu mobilnego, modalu/okienka dialogowego) i nie może z niego wyjść przez klawisz Escape lub Tab. Użytkownik jest „uwięziony” w jednym elemencie strony.

Rozwiązanie: wymaga interwencji dewelopera w kodzie JavaScript odpowiedzialnym za dane menu lub modal.

Problem 3: Menu dostępne tylko po najechaniu myszką
Klasyczny problem z menu rozwijającym się po hover (ang. stanie najechania kursorem) bez obsługi klawiatury. Rozwiązanie: zmień motyw lub popros dewelopera o dodanie obsługi klawiszem Enter i strzałkami.

Linki pomijania nawigacji — jak dodać?

Wtyczka WP Accessibility dodaje linki pomijania automatycznie. Możesz też dodać je ręcznie przez kod w szablonie motywu lub w dodatkowym CSS.

Minimalna implementacja przez CSS (jeśli motyw ma już kod HTML linku pomijania, ale jest on ukryty):

/* Link pomijania — widoczny tylko przy fokusie klawiaturowym */
.pomiń-do-treści {
    position: absolute;
    top: -9999px;
    left: -9999px;
    background: #005fcc;
    color: #ffffff;
    padding: 8px 16px;
    font-size: 16px;
    font-weight: bold;
    text-decoration: none;
    z-index: 9999;
}

.pomiń-do-treści:focus {
    top: 8px;
    left: 8px;
}

Dostępne formularze — lista kontrolna

Formularze kontaktowe, formularze zapisu na newsletter, formularze zamówień — to krytyczne punkty dostępności każdej strony biznesowej.

LISTA KONTROLNA DOSTĘPNEGO FORMULARZA:

□ Każde pole ma widoczną etykietę PONAD polem (nie tylko placeholder wewnątrz)
□ Etykieta jest powiązana z polem przez atrybut "for" lub jest zagnieżdżona
□ Wymagane pola są oznaczone tekstowo ("wymagane") — nie tylko gwiazdką
□ Jeśli gwiazdka — jest wyjaśniona na początku formularza ("* pole wymagane")
□ Komunikaty błędów wskazują, KTÓRE pole ma błąd i JAK go poprawić
□ Błędy są ogłaszane czytnikowi ekranu (ARIA live region)
□ Przycisk wysyłania ma opisową etykietę ("Wyślij wiadomość", nie samo "OK")
□ Formularz daje się obsłużyć wyłącznie klawiaturą
□ Pola mają widoczny wskaźnik fokusa
□ Zabezpieczenie antyspamowe jest dostępne (hCaptcha jest lepsza niż reCAPTCHA v2)

Rekomendowane dostępne wtyczki do formularzy:

• Gravity Forms z dodatkiem GF Accessible — zaawansowane, płatne, najlepsze wsparcie WCAG
• WPForms — dobra domyślna dostępność, popularne wśród małych firm
• Fluent Forms — wbudowana obsługa etykiet i ARIA

Nawigacja i struktura strony — pozostałe elementy

Czytelne linki — co powinno być tekstem linku?

❌ Nie rób tego:

• „Kliknij tutaj” — czytnik ekranu odczytuje listę wszystkich linków na stronie, i „kliknij tutaj” nic nie mówi
• „Więcej” — więcej czego?
• „Czytaj dalej” (10 razy na tej samej stronie) — które?

✅ Rób to:

• „Przeczytaj więcej o ofercie konsultacji” — jasne i konkretne
• „Pobierz cennik usług (PDF, 450 KB)” — informuje też o formacie i rozmiarze
• „Skontaktuj się z nami przez formularz”

Język strony w kodzie
Czytnik ekranu musi wiedzieć, w jakim języku odczytywać treść — żeby używać właściwej wymowy. WordPress dodaje atrybut języka automatycznie, ale sprawdź, czy Twój motyw go nie nadpisuje.

W panelu WordPress → Ustawienia → Ogólne → Język witryny — upewnij się, że język jest ustawiony poprawnie.

Powiększalność tekstu
Użytkownicy z wadami wzroku powiększają tekst w przeglądarce do 200%. Upewnij się, że Twoja strona nie blokuje powiększenia przez tag <meta name="viewport" content="user-scalable=no"> — to bezpośrednie naruszenie WCAG.

Animacje i ruch — uszanuj preferencje użytkownika
Osoby z zaburzeniami przedsionkowymi (zawrotami głowy, epilepsją) mogą mieć poważne trudności z animowanymi elementami strony. CSS pozwala uszanować preferencje systemowe użytkownika:

/* Wyłącz animacje dla użytkowników, którzy tak preferują */
@media (prefers-reduced-motion: reduce) {
    *,
    *::before,
    *::after {
        animation-duration: 0.01ms !important;
        animation-iteration-count: 1 !important;
        transition-duration: 0.01ms !important;
        scroll-behavior: auto !important;
    }
}

Deklaracja dostępności — co to jest i czy musisz ją mieć?

Deklaracja dostępności to dokument opisujący, w jakim stopniu Twoja strona spełnia wymogi dostępności, które znane problemy pozostają nierozwiązane i jak użytkownicy mogą zgłaszać trudności.

Dla podmiotów publicznych (urzędy, szkoły) deklaracja dostępności jest obowiązkowa zgodnie z polskim prawem. Dla firm prywatnych jest dobrowolna, ale coraz bardziej rekomendowana — szczególnie po wejściu w życie Europejskiej Ustawy o Dostępności.

Minimalna treść deklaracji dostępności:

• Status zgodności z WCAG 2.1 (w pełni zgodna / częściowo zgodna / niezgodna)
• Lista znanych problemów dostępności i powodów ich nierozwiązania
• Data ostatniej oceny dostępności
• Dane kontaktowe do zgłaszania problemów
• Procedura odwoławcza (do kogo zwrócić się, gdy problem nie został rozwiązany)

Kompleksowa lista kontrolna dostępnej strony WordPress

Natychmiast do sprawdzenia (bez dewelopera)

□ Uruchom WAVE na stronie głównej — napraw wszystkie czerwone błędy
□ Sprawdź kontrast kolorów tekstu na tle (WebAIM Contrast Checker)
□ Sprawdź, czy wszystkie obrazy mają teksty alternatywne (Biblioteka mediów)
□ Przetestuj nawigację klawiaturą (klawisz Tab przez całą stronę)
□ Sprawdź, czy formularze mają etykiety nad polami (nie tylko placeholdery)
□ Sprawdź, czy tytuły podstron są unikalne i opisowe (Yoast SEO / Rank Math)
□ Sprawdź hierarchię nagłówków (WAVE pokazuje strukturę nagłówków)
□ Sprawdź, czy język strony jest ustawiony w ustawieniach WordPress
□ Uruchom Lighthouse → zakładka Dostępność → cel: 90+

Do wdrożenia z pomocą dewelopera lub wtyczki

□ Linki pomijania nawigacji (wtyczka WP Accessibility lub kod)
□ Widoczny wskaźnik fokusa dla wszystkich elementów interaktywnych
□ Dostępne menu mobilne (obsługa klawiaturą i czytnikiem ekranu)
□ Napisy do filmów wideo na stronie
□ Atrybuty ARIA tam, gdzie HTML semantyczny nie wystarczy
□ Obsługa preferencji ograniczonego ruchu (prefers-reduced-motion)
□ Sprawdzenie z czytnikiem ekranu NVDA lub VoiceOver

Długoterminowo

□ Regularne audyty dostępności (co 6–12 miesięcy)
□ Szkolenie treści — osoby dodające treści wiedzą, jak pisać alt texty i strukturyzować nagłówki
□ Deklaracja dostępności z procedurą zgłaszania problemów
□ Śledzenie zmian w WCAG (planowane WCAG 3.0)

Dostępność a pozycjonowanie — podwójna korzyść

Zanim zakończymy, warto podkreślić coś, co właściciele firm często pomijają: wdrożenie dostępności na stronie WordPress to inwestycja, która procentuje podwójnie.

Wszystkie te działania jednocześnie poprawiają dostępność i pozycjonowanie:

• Opisowe teksty alternatywne dla obrazów → Google indeksuje treść graficzną
• Logiczna hierarchia nagłówków H1–H6 → wyraźna struktura treści dla robotów
• Opisowe tytuły podstron → lepsza klikalność w wynikach wyszukiwania
• Czytelne etykiety linków → lepsza nawigacja wewnętrzna rozumiana przez roboty
• Szybkość strony (powiązana z dostępnością przez Lighthouse) → czynnik rankingowy Google
• Responsywność mobilna → obowiązkowa zarówno dla dostępności, jak i SEO

Dostępna strona WordPress to nie dodatkowy koszt. To standard, który staje się obowiązkowy — i który, wdrożony porządnie, przynosi Ci lepsze pozycje w wyszukiwarce, szerszy zasięg i lepsze doświadczenie dla wszystkich użytkowników.

Podsumowanie — dostępność to inwestycja w każdego klienta

Budowanie dostępnej strony WordPress nie wymaga jednorazowej, ogromnej inwestycji. Wymaga świadomości i systematyczności — zaczynając od podstaw: dobrych tekstów alternatywnych, czytelnych kontrastów, opisowych etykiet formularzy i sprawdzenia nawigacji klawiaturą.

Zasady WCAG 2.1 AA to Twój kompas. Narzędzia takie jak WAVE, Lighthouse i axe to Twoi asystenci do codziennych przeglądów. Dostępny motyw to solidna baza. A wtyczki takie jak WP Accessibility i Accessibility Checker zautomatyzują część pracy.

Każdy krok w stronę dostępnej strony WordPress to krok w stronę strony, która działa lepiej dla każdego — bez względu na to, jak dany użytkownik wchodzi z nią w interakcję.

Zacznij od audytu WAVE dziś. To zajmie 15 minut i pokaże, gdzie jesteś.

Przeprowadziłeś audyt WAVE i nie wiesz, od czego zacząć naprawy? Wklej adres swojej strony w komentarzu — pomogę wskazać priorytety.