“Zainstalujemy wtyczkę od dostępności” to najczęstsza odpowiedź, jaką dostaje firma pytająca o WordPress i WCAG. Wygląda rozsądnie, bo w WordPressie wtyczką rozwiązuje się wiele problemów. Tym razem jednak zamyka to sprawę wyłącznie na papierze. Wtyczki dostępnościowe robią realne rzeczy. Żadna nie daje jednak gwarancji tam, gdzie w typowym sklepie zgodność łamie się najczęściej. Mowa o opisach obrazów, kolejności nagłówków i komunikatach w koszyku. Ten tekst rozdziela trzy warstwy: motyw, wtyczki i treść. Pokazuje, co z każdej z nich naprawdę wynika. Na końcu jest procedura, którą sprawdzisz własną stronę w około pół godziny, bez żadnego narzędzia.
Co w WordPressie odpowiada za dostępność
Za dostępność strony na WordPressie odpowiadają trzy warstwy naraz: motyw, wtyczki oraz treść wpisywana przez redakcję. Trzecia jest zwykle pomijana w rozmowie i to ona generuje najwięcej niezgodności.
Motyw decyduje o strukturze nagłówków, kolejności zaznaczania elementów, kontraście palety i zachowaniu menu. Wtyczki dokładają pojedyncze mechanizmy oraz własne pola formularzy. Redakcja wprowadza obrazy, nagłówki, treść linków i pliki do pobrania, czyli dokładnie te elementy, których żadne oprogramowanie za nią nie wypełni.
Sam obowiązek prawny i to, kogo dotyczy, rozstrzyga osobny tekst o wymaganiach WCAG 2.1 AA dla firmowej strony i sklepu. Tutaj zajmujemy się wyłącznie tym, jak to wygląda w jednym konkretnym systemie.
Dlaczego motyw accessibility-ready to nie jest zgodność z AA
To jest najbardziej kosztowne nieporozumienie w całym temacie. Katalog motywów WordPressa ma znacznik accessibility-ready i firmy czytają go jako potwierdzenie zgodności. Dokumentacja WordPressa mówi coś przeciwnego, i to wprost.
Oznaczenie “accessibility ready” nie znaczy, że motyw spełnia wytyczne WCAG na poziomie AA. Znaczy, że motyw osiąga minimalne standardy ustalone przez zespół recenzujący motywy. – dokumentacja motywów WordPress.org, sprawdzona 26 sierpnia 2026
Znacznik wymaga konkretnych rzeczy i są one wartościowe. Motyw musi mieć skip-linki prowadzące do treści oraz nawigacji, widoczne oznaczenie elementu, na którym zatrzymuje się klawiatura, niezależne od samego koloru, a także kontrast tekstu na poziomie 4,5 do 1. Dla samego tekstu linku bez podkreślenia dochodzi kontrast 3 do 1 wobec otaczającego tekstu.
To dobry punkt startu i warto wybierać takie motywy. Nie jest to jednak certyfikat, a znacznik nie mówi nic o treści, którą do motywu wsypie redakcja.
Co naprawdę załatwia wtyczka
Wtyczki dostępnościowe dzielą się na trzy rodzaje i robią zupełnie różne rzeczy, choć w katalogu wyglądają podobnie. Rozróżnienie tych trzech kategorii oszczędza najwięcej czasu przy wyborze.
| Rodzaj | Co robi | Przykłady z katalogu WordPress.org |
|---|---|---|
| Poprawki techniczne | Dokłada skip-linki, naprawia atrybuty języka, wymusza widoczne zaznaczenie | WP Accessibility |
| Panel użytkownika (nakładka) | Dodaje przycisk z regulacją kontrastu i wielkości liter | Web Accessibility (dawniej Ally), UserWay, accessiBe |
| Sprawdzanie treści | Skanuje wpisy i strony w panelu, wskazuje błędy do poprawienia | Equalize Digital Accessibility Checker |
Dane z katalogu WordPress.org pobrane 26 sierpnia 2026: Web Accessibility ma ponad 500 tysięcy instalacji, UserWay ponad 80 tysięcy, WP Accessibility ponad 60 tysięcy, a Equalize Digital Accessibility Checker ponad 10 tysięcy.
Warstwa techniczna to najbardziej konkretna korzyść z wtyczki. Narzędzie z pierwszego rodzaju potrafi dołożyć skip-link, wymusić widoczne obramowanie zaznaczenia, poprawić atrybut języka strony i usunąć atrybuty psujące nawigację. Są to poprawki na poziomie kodu, więc działają niezależnie od tego, kto pisze treść. Nie gwarantują jednak poprawienia elementów generowanych przez inne wtyczki ani samej treści wpisu.
Na co patrzeć przy wyborze wtyczki
Sprawdź datę ostatniej aktualizacji i wersję WordPressa, z którą wtyczka była testowana. To zajmuje kilkanaście sekund w katalogu, a odsiewa najwięcej.
Przykład z tego samego zapytania do katalogu: według odczytu z 26 sierpnia 2026 wtyczka WP Accessibility Helper w wersji 0.6.6 była testowana do WordPressa 6.8.8, a ostatnią aktualizację otrzymała 29 maja 2025 roku. Wtyczka odpowiedzialna za warstwę dostępności, której nikt nie rusza od kilkunastu miesięcy, jest ryzykiem, a nie zabezpieczeniem.
Druga rzecz to rodzaj z tabeli wyżej. Wtyczka sprawdzająca treść w panelu redaktora rozwiązuje inny problem niż wtyczka dokładająca panel dla użytkownika. Pierwsza pomaga redakcji nie tworzyć nowych błędów. Druga nie usuwa błędów w kodzie źródłowym motywu ani rozszerzenia, choć może modyfikować wyrenderowaną stronę.
Trzecia rzecz to sprawdzenie, czy wtyczka nie dubluje tego, co robi już motyw. Motyw z oznaczeniem accessibility-ready ma skip-linki oraz widoczne zaznaczenie z definicji. Wtyczka dokładająca to samo potrafi wtedy wyprodukować podwójne skip-linki albo obramowanie nie pasujące do reszty serwisu.
Czego wtyczka nie załatwi
Żadna wtyczka nie uzupełni wiarygodnie treści, której nie ma, ani nie oceni sensu treści, która jest. To jest granica, o którą rozbija się większość wdrożeń “na wtyczkę”.
- Teksty alternatywne obrazów. Wtyczka wykryje brak atrybutu, a niektóre narzędzia próbują opis generować automatycznie. Żadne nie ma jednak gwarancji, że poprawnie rozpozna właśnie Twój model krzesła w kolorze grafitowym.
- Kolejność i hierarchia nagłówków. Redaktor, który zrobił nagłówek pogrubieniem, a po H2 wstawił H4, złamał strukturę wewnątrz treści. Motyw jest tu bez znaczenia.
- Etykiety pól w formularzach z innych wtyczek. Formularz kontaktowy, filtry produktów i wyszukiwarka pochodzą zwykle od trzech różnych dostawców. Wtyczka dostępnościowa nie zmienia ich kodu źródłowego i najwyżej nadpisuje wynik na gotowej stronie.
- Komunikaty o błędach w koszyku. WooCommerce wyświetla je własnym mechanizmem, a część motywów podmienia go na swój.
- Karuzele, wyskakujące okna i liczniki. Element, który sam się przewija albo znika po czasie, wymaga zmiany zachowania, nie nakładki.
- Pliki PDF w bibliotece mediów. Dostępność dokumentu robi się w programie, w którym powstał, a nie w WordPressie.
Wniosek jest prosty i niewygodny dla budżetu. Wtyczka zdejmuje część warstwy technicznej, a reszty nie da się zautomatyzować w całości i zostaje ona pracą w szablonie oraz w treści. Jeśli chcesz wiedzieć, ile tej pracy naprawdę jest, potrzebny jest przegląd, a jego zakres i koszt rozkłada wpis o audycie WCAG.
Gdzie sklepy na WooCommerce łamią to najczęściej
W sklepach na WooCommerce problemy powtarzają się w tych samych kilku miejscach, bo wynikają z połączenia samego WooCommerce, motywu, rozszerzeń oraz integracji zewnętrznych. Poniższe punkty formułujemy jako typowe obserwacje rynkowe, nie jako wyniki badania na próbie polskich sklepów.
Aktualizacja ilości w koszyku bywa pierwszym problemem. Liczba się zmienia, suma się przelicza, ale osoba korzystająca z czytnika ekranu nie dostaje o tym żadnej informacji. Zmiana wygląda dobrze i jest niesłyszalna.
Drugi punkt to wybór dostawy z mapą punktów odbioru. Mapa pochodzi od zewnętrznego dostawcy, obsługuje się ją myszą i bywa jedynym sposobem wskazania punktu. Bez alternatywnej listy do wyboru z klawiatury to jest twardy bloker zakupu.
Trzeci to formularz zamówienia z polami opisanymi wyłącznie szarym napisem w środku pola. Po kliknięciu napis znika i nie zostaje nic, co powiąże pole z jego znaczeniem.
Czwarty to komunikat o odrzuconej płatności, wyświetlany czerwoną ramką bez tekstu albo w ramce zewnętrznego operatora. Klient widzi, że coś się nie udało, i nie wie co. Sklep widzi porzucony koszyk.
Piąty punkt to filtry produktów na liście kategorii. Odświeżają wyniki bez przeładowania strony, więc osoba korzystająca z czytnika ekranu nie dowiaduje się, że lista się zmieniła. Wygląda to jak brak reakcji na kliknięcie.
Jeśli budujesz sklep od zera, warto rozstrzygnąć te pięć rzeczy na etapie wyboru rozwiązań, a nie po uruchomieniu. Kontekst kosztowy takiego projektu opisuje wpis o sklepie na WordPressie z WooCommerce, a same wtyczki sklepowe zbiera zestawienie wtyczek WooCommerce dla WordPressa.
Przy sklepie, który już działa, kolejność napraw wyznacza to, co blokuje złożenie zamówienia, a nie to, co najłatwiej poprawić. Jeśli chcesz mieć tę kolejność ustaloną dla swojego sklepu, opisz go w formularzu wyceny – wracamy z listą uporządkowaną według wpływu na sprzedaż.
Devstock · Software house
Strony WWW i sklepy e-commerce
Devstock projektuje i wdraża strony firmowe oraz sklepy WooCommerce/Shopify. Performance, SEO, integracje.
Zamów wycenę →Jak sprawdzić własną stronę w pół godziny
Cztery testy poniżej wykrywają blokery, czyli rzeczy, które uniemożliwiają zakup. Nie wymagają żadnego narzędzia ani wiedzy technicznej i może je zrobić osoba z marketingu. Pół godziny to nasz szacunek dla typowego serwisu, a nie zmierzony czas.
- Odłóż mysz i przejdź stronę klawiszem Tab. Sprawdź, czy widać, gdzie jesteś, czy da się otworzyć menu i zamknąć okno wyskakujące. Przejdź całą ścieżkę do złożenia zamówienia. Jeśli w którymś miejscu utkniesz, znalazłeś bloker.
- Powiększ stronę do 200 procent. W przeglądarce robi się to skrótem z klawiszem Ctrl i plusem. Sprawdź przede wszystkim, czy nic nie znika i czy wszystkie funkcje nadal działają.
- Wyłącz obrazy w ustawieniach przeglądarki. Zobaczysz, co zostaje na miejscu zdjęć. Puste ramki na kartach produktów to sygnał do sprawdzenia opisów alternatywnych, a nie od razu dowód ich braku.
- Wypełnij formularz błędnie i przeczytaj komunikat. Sprawdź, czy tekst mówi, które pole jest złe i dlaczego. Sama czerwona ramka to za mało.
Zapisz wyniki w jednym miejscu, choćby w notatce, bo to jest gotowa lista do rozmowy z wykonawcą. Ta procedura wykrywa blokery i nie zastępuje pełnego sprawdzenia. Zgodność z WCAG 2.1 na poziomie AA obejmuje łącznie 50 kryteriów z poziomów A i AA. Część z nich wymaga czytnika ekranu oraz doświadczenia w jego obsłudze.
Deklaracja dostępności – czego firma prywatna nie kopiuje z urzędów
Firma prywatna nie ma obowiązku publikować deklaracji dostępności według wzoru dla podmiotów publicznych. Tamten wzór wynika z osobnej ustawy o podmiotach publicznych, a obowiązek informacyjny firm wygląda inaczej.
Przepisy dla firm wymagają podania do publicznej wiadomości informacji o tym, w jaki sposób usługa spełnia wymagania dostępności. Miejscem jest regulamin świadczenia usług albo równoważny dokument. W WordPressie oznacza to zwykle podstronę z regulaminem, a nie osobny element w stopce.
W katalogu wtyczek znajdziesz narzędzia generujące deklarację według wzoru dla podmiotów publicznych. Dla urzędu są właściwe. Dla sklepu prywatnego produkują dokument, który wygląda oficjalnie i nie odpowiada na pytanie zadane przez ustawę.
Praktycznie wystarczy krótka sekcja w regulaminie. Opisz w niej, jak zapewniacie dostępność i gdzie zgłosić problem. Podaj konkretny kanał kontaktu, bo konsument ma prawo złożyć skargę, a firma ma na odpowiedź 30 dni. Ten sam zapis przyda się w ankiecie zakupowej dużego kontrahenta, bo pytanie o dostępność pojawia się tam coraz częściej.
FAQ – najczęstsze pytania o WordPress i WCAG
Czy nakładka dostępnościowa wystarcza?
Nie wystarcza, ponieważ nakładka działa w przeglądarce i nadpisuje wygląd strony, zamiast poprawiać jej kod oraz treść. Wspólne stanowisko środowiska dostępności, podpisane między innymi przez współautorów specyfikacji WCAG, mówi wprost, że pełnej zgodności nakładką osiągnąć się nie da. Traktuj ją jako udogodnienie dla części użytkowników.
Czy trzeba zmieniać motyw?
Zwykle nie trzeba, bo większość problemów rozwiązuje się poprawkami w szablonie potomnym. Wymiana motywu ma sens wtedy, gdy obecny nie pozwala zmienić struktury nagłówków ani zachowania menu bez przepisywania go od nowa. Decyzję warto podjąć po przeglądzie, nie przed nim.
Czy strona na kreatorze stron może być zgodna?
Może, choć zależy to od tego, ile kontroli nad kodem zostawia kreator. Budowniczy stron generują często zagnieżdżone kontenery i własne mechanizmy okien, które trudno poprawić od strony redakcji. Sprawdź to na jednym szablonie, zanim zbudujesz na nim cały serwis.
Kto odpowiada za dostępność treści dodawanej codziennie?
Odpowiada za nią redakcja i to jest warstwa, której nie da się zautomatyzować. Najprostszym rozwiązaniem jest wtyczka sprawdzająca treść w panelu, uzupełniona o krótką instrukcję dla osób publikujących. Bez tego każdy nowy wpis dokłada usterki szybciej, niż idą poprawki.
Podsumowanie
W WordPressie za dostępność odpowiadają trzy warstwy naraz i pomylenie ich jest źródłem większości rozczarowań. Motyw ustawia strukturę oraz kontrast, przy czym znacznik accessibility-ready z definicji nie oznacza zgodności z poziomem AA, co dokumentacja WordPressa mówi wprost. Wtyczki dzielą się na poprawiające technikę, dokładające panel dla użytkownika i sprawdzające treść w panelu redaktora, a wybierając którąkolwiek, zacznij od daty ostatniej aktualizacji. Reszta, czyli opisy obrazów, hierarchia nagłówków, etykiety w cudzych formularzach i komunikaty w koszyku, zostaje po stronie szablonu oraz redakcji. Zrób najpierw cztery testy z sekcji wyżej, bo według naszego szacunku zajmą około pół godziny i pokażą, czy problem jest kosmetyczny, czy blokuje sprzedaż. Jeśli chcesz, żeby ktoś przeszedł przez to z Tobą i wycenił poprawki, opisz swój serwis w formularzu wyceny – odsyłamy zakres podzielony na to, co robi wykonawca, a co redakcja.
