♿ Dostępność wordpressowych stron: pełny poradnik 2026

Gdy użytkownik nie może przeczytać Pana/Pani tekstu, kliknąć przycisku lub po prostu zrozumieć, dokąd prowadzi link, odchodzi. Nie dlatego, że treść jest zła. Dlatego, że strona z nim nie rozmawia.

Od czerwca 2025 roku Europejski akt o dostępności (EAA) stał się obowiązkowy. W Niemczech działa własny, krajowy Barrierefreiheitsstärkungsgesetz (BFSG). Kary, nakazy, utrata odbiorców. Za presją prawną kryje się jednak prosta prawda: według danych WHO około 16% ludzi na świecie, czyli co szósta osoba, żyje z jakąś formą niepełnosprawności. Ignorowanie ich oznacza utratę co szóstego odwiedzającego.

WordPress nie jest tu ani wyjątkiem, ani wyrokiem. CMS daje dobrą podstawę, ale rzeczywista dostępność jest wynikiem świadomych działań dewelopera lub właściciela. W tym poradniku znajdzie Pan/Pani analizę krok po kroku: od struktury nagłówków po nawigację klawiaturą, od wyboru motywu po automatyczne testy. Żadnego lania wody, tylko to, co można zastosować już dziś. 💡 Szybki przegląd:

• Proszę sprawdzić postrzegalność: sensowny alt przy każdym obrazku, aria-label przy ikonach, zrozumiały tekst kotwicy przy każdym linku.
• Proszę osiągnąć kontrast 4,5 do 1 dla zwykłego tekstu i 3 do 1 dla dużego tekstu za pomocą WebAIM Contrast Checker.
• Proszę zbudować hierarchię nagłówków: jeden H1 na stronie, następnie H2 i H3 bez przeskakiwania poziomów.
• Proszę upewnić się, że wszystko jest dostępne z klawiatury: każdy element klikalny myszą musi działać po użyciu Tab i Enter.
• Proszę sprawdzić formularze: każda etykieta label musi być jawnie powiązana z polem wejściowym, placeholder nie zastępuje opisu.
• Proszę uruchomić WAVE lub Lighthouse: automatyczny audyt znajdzie większość problemów w pół minuty.

Czym jest dostępność cyfrowa i dlaczego jest obowiązkowa w 2026 roku

Dostępność cyfrowa (web accessibility) to praktyka projektowania i tworzenia stron, z których mogą korzystać osoby o różnych możliwościach fizycznych i poznawczych. Czytniki ekranu dla niewidomych, nawigacja klawiaturą dla osób z zaburzeniami motoryki, odpowiedni kontrast dla słabowidzących, napisy dla niesłyszących.

Standardem de facto są wytyczne WCAG 2.2 (Web Content Accessibility Guidelines) konsorcjum W3C. Trzy poziomy: A (minimalny), AA (docelowy dla większości) i AAA (najwyższy). Prawodawstwo UE i USA wymaga poziomu AA.

28 czerwca 2025 roku wszedł w życie Europejski akt o dostępności (dyrektywa UE 2019/882), który obejmuje handel elektroniczny, bankowość, transport i media. W Niemczech równolegle obowiązuje BFSG. Kary są różne: w Niemczech do 100 000 euro, we Francji do 250 000 euro. Strony WordPress firm komercyjnych podlegają tym regulacjom bezpośrednio.

Postrzegalność: jak sprawić, by treść była zrozumiała dla czytników ekranu

Pierwszy krok w dostępności: informacja musi być przedstawiona tak, aby użytkownik mógł ją odebrać przynajmniej jednym kanałem: wzrokiem, słuchem, dotykiem.

Obrazki i tekst alternatywny. Każdy znacznik img musi mieć atrybut alt. Dla obrazków niosących treść jest to opis tego, co się na nich dzieje (5-8 słów, bez słów „obrazek" czy „zdjęcie"). Dla obrazków dekoracyjnych: alt="" (pusty, ale obecny). Czytnik ekranu pomija pusty alt i nie rozprasza użytkownika.

1
/* functions.php — примусовий alt для мініатюр записів */
2
add_filter('wp_get_attachment_image_attributes', function($attr, $attachment) {
3
    if (empty($attr['alt'])) {
4
        $attr['alt'] = get_the_title($attachment->ID);
5
    }
6
    return $attr;
7
}, 10, 2);

Puste linki i przyciski. Ikona lupy bez tekstu to zagadka dla czytnika ekranu. Proszę zawsze dodawać aria-label do przycisków ikonowych:

1
<button aria-label="Open search">
2
    <span class="dashicons dashicons-search"></span>
3
</button>

Atrybuty title. Są przydatne dla dodatkowego kontekstu, ale proszę nie powielać w nich tekstu linku, czytnik ekranu odczyta to samo dwa razy. WordPress domyślnie powiela tekst linku w title, warto to wyłączyć.

Kontrast kolorów: podstawowe wartości i narzędzia do sprawdzania

Niewystarczający kontrast tekstu i tła to najpowszechniejszy problem. Według danych WebAIM Million 2025 niski kontrast wykryto na 81% przeskanowanych stron.

Minimalne wymagania WCAG 2.2 AA:

• Zwykły tekst (poniżej 18pt): kontrast 4,5:1
• Duży tekst (18pt i więcej lub 14pt pogrubiony): kontrast 3:1
• Ikony i elementy interfejsu: kontrast 3:1

Sprawdza się to w minutę za pomocą WebAIM Contrast Checker, gdzie wprowadza Pan/Pani kolor tekstu i tła w HEX i otrzymuje werdykt: Pass / Fail dla każdego poziomu.

Typowe obszary problemowe w WordPressie: szary tekst na białym tle w stopce, jasne przyciski z białym napisem, tekst na zdjęciach bez przyciemniającego podkładu. Rozwiązuje się to korektą CSS, najczęściej przez przyciemnienie tekstu o kilka tonów.

Struktura nagłówków: hierarchia zrozumiała dla wszystkich

Czytniki ekranu budują „spis treści" strony z nagłówków, użytkownik przeskakuje po H2 i H3, omijając nawigację. Jeśli hierarchia jest zaburzona, nawigacja się załamuje.

Zasady:

• Jeden H1 na stronę, z reguły tytuł wpisu
• H2 dla głównych sekcji, H3 dla podsekcji wewnątrz H2
• Nagłówki nie przeskakują poziomów: H2 → H4 (z pominięciem H3) to błąd
• Proszę nie używać znaczników h* dla uzyskania rozmiaru czcionki, od tego jest CSS

W WordPressie typowym problemem są wtyczki i motywy, które wstawiają H2/H3 dla swoich bloków (slidery z nagłówkiem, formularz subskrypcji, widgety paska bocznego). Są trzy rozwiązania: znaleźć ustawienia znacznika we wtyczce, dostosować kod wyjściowy przez filtr lub zmienić wtyczkę na staranniej napisaną. Tolerowanie zepsutej hierarchii, „bo ładnie wygląda", nie wchodzi w grę.

Nawigacja i punkty orientacyjne: drogowskazy dla czytnika ekranu

Punkty orientacyjne HTML5 dają czytnikowi ekranu mapę strony. Cztery kluczowe znaczniki: header dla nagłówka strony, nav dla nawigacji, main dla głównej treści i footer dla stopki. Użytkownik naciska skrót klawiszowy i przeskakuje od razu do głównej treści.

1
<header role="banner">
2
<nav role="navigation">
3
<main role="main">
4
<footer role="contentinfo">

Rola role="main" musi występować dokładnie raz na stronie. Większość nowoczesnych motywów WordPress używa tych tagów od razu po instalacji, proszę to sprawdzić za pomocą WAVE: sekcja „Structure" pokaże wszystkie punkty orientacyjne (landmarks).

Kolejny obowiązkowy element, „Skip to Content", to niewidoczny odnośnik umieszczony jako pierwszy element strony, który pozwala pominąć menu i od razu przejść do treści. W WordPressie dodaje się go za pomocą filtra lub przez wtyczkę ułatwień dostępu.

Formularze bez barier

Formularz kontaktowy, zapis do newslettera, składanie zamówienia: każde pole musi być opisane etykietą i dostępne z klawiatury.

*Każdy input musi mieć swój label (jawny lub przez aria-label):*

1
<label for="user-email">Email</label>
2
<input id="user-email" name="email" type="email">

Placeholder (placeholder) nie zastępuje etykiety, znika podczas wpisywania tekstu i jest źle odczytywany przez czytniki ekranu. Proszę używać placeholder wyłącznie jako podpowiedzi formatu, a nie jako nazwy pola.

Grupowanie: przyciski radiowe i pola wyboru należy opakowywać w <fieldset> z <legend>. Pola obowiązkowe: proszę oznaczać tekstem „(wymagane)", a nie tylko gwiazdką czy kolorem.

Nawigacja klawiaturą: Pana/Pani strona bez myszy

Niektórzy użytkownicy w ogóle nie używają myszy: drżenie, spastyczność, paraliż. Wszystko musi działać za pomocą Tab, Shift+Tab, Enter, Escape i strzałek.

Szybki test: proszę otworzyć stronę i przejść ją wyłącznie klawiszem Tab. Każdy interaktywny element powinien otrzymywać widoczny fokus. Okno modalne musi zamykać się klawiszem Escape. Rozwijane menu musi rozwijać się po Enter.

Typowe wpadki stron na WordPressie:

• Niestandardowe menu rozwijane bez tabindex i aria-expanded
• outline: none w CSS (usuwa wskaźnik fokusu, proszę tego nie robić)
• Nieskończona pułapka fokusu w wyskakujących okienkach
• Slajdery, których nie da się obsłużyć z klawiatury

Nigdy nie należy całkowicie wyłączać standardowego stylu :focus. Jeśli domyślna ramka przeglądarki nie pasuje, proszę zastąpić ją niestandardowym :focus-visible z kontrastowym obrysem.

Skalowanie: proszę nie zabraniać użytkownikowi powiększania tekstu

Wiele mobilnych wersji stron na WordPressie blokuje powiększanie przez szczypnięcie (pinch-zoom) za pomocą meta-tagu:

1
<!-- НЕПРАВИЛЬНО — так робити не можна -->
2
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
3
 
4
<!-- ПРАВИЛЬНО -->
5
<meta name="viewport" content="width=device-width, initial-scale=1">

WCAG 2.2 wymaga możliwości powiększenia do 200% bez utraty treści i funkcjonalności, jest to Success Criterion 1.4.4. Proszę sprawdzić, czy podczas powiększania tekst nie jest przycinany i nie nachodzi na inne bloki.

Tematy WordPress i dostępność: na co zwracać uwagę przy wyborze

Żaden temat nie jest „w pełni dostępny od razu po instalacji", zbyt wiele zależy od treści i ustawień. Jednak baza startowa ma znaczenie.

Przy wyborze tematu proszę zwrócić uwagę:

• W opisie widnieje „accessibility ready", to tag na WordPress.org, oznacza podstawową zgodność z wymaganiami
• Poprawna struktura HTML5 z punktami orientacyjnymi (landmarks)
• Menu nawigacyjne, natywny <nav> z <ul>, a nie konstrukcja z divów i JS
• Obecność stylów :focus dla linków i przycisków
• Brak maximum-scale=1.0 w meta viewport

Standardowe temy WordPress (Twenty Twenty-Four, Twenty Twenty-Five) to niezły punkt wyjścia. Komercyjne tematy z wizualnymi kreatorami to strefa ryzyka: im więcej wizualnej „magii", tym większa szansa na zepsutą dostępność.

Narzędzia do audytu: od szybkiego sprawdzenia po profesjonalne testowanie

WAVE Evaluation Tool. Rozszerzenie przeglądarkowe WAVE od WebAIM, nakłada ikony bezpośrednio na stronę: czerwone to błędy, żółte to ostrzeżenia, zielone to elementy poprawne. Idealne do pierwszego audytu. Pokazuje kontrast, teksty alternatywne, strukturę nagłówków, atrybuty ARIA.

Google Lighthouse. Wbudowany w Chrome DevTools (F12 → Lighthouse → Accessibility). Daje ocenę liczbową 0-100 i listę konkretnych elementów do poprawy. Wygodny do regularnego monitorowania.

Accessibility Checker (Equalize Digital). Wtyczka do WordPressa, Accessibility Checker sprawdza treść bezpośrednio w edytorze (Gutenberg i Classic). Darmowa wersja skanuje wpis przed publikacją, Pro dodaje pełny audyt witryny.

WP Accessibility. Weteran wśród wtyczek dostępności, WP Accessibility od Joe Dolsona. Dodaje linki pomijające (skip links), punkty orientacyjne ARIA, usuwa zduplikowane atrybuty title linków, naprawia style :focus, usuwa tabindex z formularzy i target z linków. To nie panaceum, ale załatwia kilkanaście typowych problemów za jednym zamachem.

One Click Accessibility. Wtyczka z paskiem narzędzi, One Click Accessibility pozwala użytkownikowi samodzielnie przełączyć kontrast, powiększyć czcionkę, podkreślić linki. To nie zastępstwo natywnej dostępności, a dodatkowa warstwa dla tych, którzy potrzebują specyficznych ustawień.

NVDA. Darmowy czytnik ekranu dla Windows, NVDA. Proszę przejść swoją witrynę z wyłączonym monitorem. Usłyszy Pan/Pani to, co słyszy niewidomy użytkownik. VoiceOver (wbudowany w macOS/iOS) to odpowiednik dla ekosystemu Apple.

Dziesięć kroków do dostępnej witryny WordPress

Oto esencja całego poradnika, lista kontrolna. Proszę ją przejść po każdym redesignie lub uruchomieniu nowego projektu.

• Proszę dodać alt dla każdego obrazka. W bibliotece mediów WordPress proszę wypełniać pole „Tekst alternatywny". Dla obrazków dekoracyjnych proszę ustawić alt="".

• Proszę opisać linki. Tekst linku powinien informować, dokąd prowadzi. „Kliknij tutaj" i „Dowiedz się więcej" to złe anchory. „Pobierz wtyczkę Accessibility Checker" to dobry.

• Proszę układać nagłówki po kolei. Jeden H1, potem H2, wewnątrz H2 proszę stosować H3. Proszę sprawdzić w WAVE: Structure → Heading Outline.

• Proszę doprowadzić kontrast do 4.5:1. Proszę przejść WebAIM Contrast Checker po głównych kolorach tematu: tekst, nagłówki, przyciski, linki, stopka.

• Proszę włączyć widoczny fokus. Proszę upewnić się, że :focus nie jest ustawione jako outline: none bez zamiennika. Niestandardowy fokus robi się przez :focus-visible.

• Proszę sprawdzić nawigację klawiaturą. Tab po wszystkich linkach i przyciskach, Enter do aktywacji, Escape do zamykania modali. Jeśli Pan/Pani utknie, to błąd.

• Proszę podpisać formularze. Każde pole musi mieć swój <label>. Pola obowiązkowe proszę oznaczać tekstowo. Grupy pól proszę umieszczać w <fieldset>.

• Proszę nie blokować zoomu. Viewport bez maximum-scale i user-scalable=no. Proszę sprawdzić przy dwukrotnym powiększeniu: treść nie może być przycinana.

• Proszę dodać skip link. Link „Przejdź do treści" jako pierwszy element <body>. WP Accessibility robi to automatycznie.

• Proszę uruchomić WAVE lub Lighthouse. Automatyczny audyt nie zastąpi ręcznego testowania, ale znajdzie zdecydowaną większość problemów w minutę.

⁉️🤔 Często zadawane pytania

Czy moja strona WordPress musi spełniać wymogi WCAG?

Jeśli Pana/Pani witryna reprezentuje firmę w UE, tak, od czerwca 2025 roku. Europejski akt o dostępności obejmuje handel elektroniczny, finanse, transport i media. W USA obowiązują podobne wymagania: ADA oraz Section 508 dla instytucji publicznych i ich wykonawców. Blog osobisty formalnie nie jest zobowiązany, ale znaczny odsetek użytkowników z niepełnosprawnościami to silny argument komercyjny.

Tak, komercyjne witryny w UE muszą spełniać wymogi WCAG 2.2 AA od 28 czerwca 2025 roku zgodnie z European Accessibility Act. Kary ustalają państwa członkowskie: kwoty sięgają setek tysięcy euro w zależności od jurysdykcji. W USA analogiczne wymagania wynikają z ADA i Section 508. W przypadku osobistych blogów niekomercyjnych nie ma obowiązku prawnego, ale dostępność poszerza grono odbiorców.

Czy wystarczy zainstalować wtyczkę typu One Click Accessibility?

Wtyczka typu toolbar to warstwa pomocnicza, a nie rozwiązanie. Umożliwia użytkownikowi zmianę kontrastu lub rozmiaru czcionki, ale nie naprawi brakujących tekstów alternatywnych, zaburzonej hierarchii nagłówków ani wyskakujących okienek niedostępnych z klawiatury. Należy zacząć od natywnej dostępności w kodzie i treści, a toolbar dodać jako ostatni szlif.

Nie. Toolbar (One Click Accessibility, UserWay) to jedynie dodatkowa „nakładka". Nie zastępuje natywnej dostępności: nie poprawia tekstów alternatywnych, hierarchii nagłówków, pułapek klawiaturowych ani niepodpisanych pól formularzy. Należy zacząć od poprawy kodu i treści, toolbar to ostatni szlif.

Jak przetestować witrynę bez kupowania drogich narzędzi?

Pełny cykl z wykorzystaniem bezpłatnych narzędzi: rozszerzenie WAVE (pierwsze szybkie skanowanie) → Google Lighthouse (ocena liczbowa + lista problemów) → ręczne przejście klawiaturą (Tab/Enter/Escape) → NVDA w systemie Windows lub VoiceOver na Macu (przejście przez witrynę z wyłączonym monitorem). To wystarczy, aby rozwiązać zdecydowaną większość problemów.

Bezpłatny cykl: rozszerzenie WAVE do przeglądarki → Google Lighthouse w Chrome DevTools → ręczne przejście klawiaturą → NVDA (Windows) lub VoiceOver (macOS/iOS) do testowania czytnikiem ekranu. Te cztery narzędzia pokrywają 90% zadań. Płatne usługi są potrzebne tylko do regularnego audytu dużych projektów.

Czy można uczynić dostępną witrynę zbudowaną w kreatorze wizualnym (Elementor, WPBakery)?

Można, ale jest to trudniejsze. Kreatory generują HTML dynamicznie, a niektóre widżety naruszają hierarchię nagłówków lub wstawiają opakowania div bez semantyki. Należy sprawdzać każdy blok osobno za pomocą WAVE. Elementor Pro od wersji 3.15+ dodał ustawienia atrybutów aria dla widżetów, warto z nich korzystać.

Można, ale będzie to wymagało więcej pracy ręcznej. Kreatory wizualne mają tendencję do naruszania hierarchii nagłówków i generowania nadmiarowych opakowań div. Należy sprawdzać wynik w WAVE po każdej zmianie. Elementor Pro (3.15+) umożliwia ustawianie atrybutów ARIA dla widżetów, co częściowo rozwiązuje problem.

Jak często należy sprawdzać dostępność witryny?

Po każdej znaczącej aktualizacji: nowy motyw, nowa wtyczka, przeprojektowanie, duża publikacja treści. Minimalny cykl to uruchamianie Lighthouse raz na kwartał i przechodzenie kluczowych stron za pomocą klawiatury. Automatyczne monitorowanie przez Accessibility Checker Pro jest uzasadnione w przypadku witryn z regularnie publikowaną treścią.

Co najmniej po każdej dużej zmianie (zmiana motywu, nowa wtyczka, przeprojektowanie) oraz profilaktycznie raz na kwartał. W przypadku witryn z regularnymi publikacjami uzasadnione jest automatyczne monitorowanie przez Accessibility Checker Pro. Test czytnikiem ekranu wystarczy przeprowadzać raz na pół roku, jeśli baza kodu nie uległa zmianie.

Co zrobić z dostępnością strony WordPress już teraz

Nie czekają Państwo na idealny moment. WCAG 2.2 AAA to cel, a nie start. Proszę zacząć od trzech działań już dziś:

• Proszę uruchomić WAVE na stronie głównej. Proszę poprawić czerwone błędy (zwykle 5-10 sztuk), usuwają one najpoważniejsze bariery.
• Proszę przejść stronę za pomocą klawiatury. Tab, Tab, Tab. Jeśli Państwo utknęli, proszę naprawić. Jeśli nie widać fokusa, proszę dodać :focus-visible.
• Proszę sprawdzić kontrast trzech kolorów: kolor tekstu, kolor przycisków, kolor linków. Proszę doprowadzić do 4.5:1.

Te trzy kroki, pół godziny pracy, i lwia część rezultatu. Resztę, wtyczki, czytniki ekranu, ARIA, proszę dodawać stopniowo.

Jeśli strona jest komercyjna i działa w UE, proszę nie odkładać. EAA od 2025 roku daje organom nadzorczym realne narzędzia. Lepiej spotkać kontrolę z zielonym Lighthouse niż z pismem od regulatora.