Dostępność WordPress
Spraw, by Twoja strona WordPress była naprawdę dostępna. EAA i WCAG, bez nakładki
WordPress jest elastyczny, ale nie jest domyślnie dostępny: kreatory stron, wtyczki i motywy wprowadzają ciche bariery. My je znajdujemy i dostarczamy poprawkę w Twoim własnym kodzie szablonu, żadnego widżetu, który spowalnia stronę.
Tak Seviranta zabiera się za Twoją stronę na WordPress u źródła
Gdzie kryją się bariery
Motywy, rozszerzenia i formularze wprowadzają ciche bariery. My znajdujemy je wszystkie.
Poprawka w źródle, a nie na wierzchu
Konkretne naprawy w Twoim motyw i wtyczki, bez warstwy nakładki, która jedynie ukrywa błędy.
Bez widgetu, bez spowolnienia
Crawlujemy zewnętrznie z serwerów w UE, 0% wpływu na Twoją szybkość ładowania i Core Web Vitals.
Gotowe na EAA
Sprawdzamy Twoją stronę pod kątem WCAG, na tym samym poziomie, na którym sprawdzają organy nadzoru.
Skan headless na silniku axe-core, tym samym, który działa w Google Lighthouse, z naszych serwerów w UE. 0% wpływu na szybkość ładowania Twojej strony.
Prawda: WordPress nie jest domyślnie dostępny
Porządny blokowy motyw WordPress, taki jak Twenty Twenty-Four, startuje lepiej niż wiele stron, ale sam z siebie rzadko spełnia WCAG 2.2 AA. Gdy tylko zaczniesz budować w Elementor, Divi lub Gutenberg, pozwolisz wtyczkom wstrzykiwać znaczniki albo dodasz obrazy bez tekstu alternatywnego, pojawiają się bariery, których Twoi odwiedzający, i European Accessibility Act, nie zaakceptują.
Co naprawdę jest na szali
- Niedostępny checkout to bezpośrednie naruszenie EAA.
- Widżet dostępności nie liczy się jako rozwiązanie strukturalne.
- Organy nadzoru testują wygenerowany HTML, łącznie z Twoimi aplikacjami.
- „Używamy WordPress” to nie obrona prawna: odpowiedzialność spoczywa na sklepie internetowym, który jest na żywo, a nie na platformie.
Ile może kosztować zwłoka
do € 1.000.000
Maksimum UE · Hiszpania/Luksemburg
$ 4.000
USA · Kalifornia (Unruh), za wizytę
Nie dostaniesz kary znienacka, najpierw przychodzi nakaz usunięcia uchybień z terminem. Ale kto w tym momencie pokaże datowane dossier, wychodzi najtaniej.
Zobacz, co dotyczy Twojego rynku →Ukryte ryzyko zewnętrznych rozszerzeń WordPress
Widżety recenzji, filtry, bundlery i aplikacje wyszukiwania wstrzykują dynamiczny HTML do Twojego frontendu, a każda aktualizacja aplikacji może dołożyć kolejną barierę. W audycie ten kod liczy się w pełni, nawet jeśli nie jest Twojego autorstwa. Dlatego Seviranta stale pilnuje efektu końcowego tak, jak widzi go organ nadzoru: Twój motyw na WordPress plus wszystkie aplikacje i treści dynamiczne.
Co najczęściej szwankuje na WordPress
- Kreatory stron tworzą nieczytelną zupę z divówElementor i Divi zagnieżdżają sekcje, kolumny i kontenery dziesiątki poziomów w głąb. Ta zupa z divów nie niesie żadnej semantyki, przez co czytnik ekranu gubi logiczną strukturę Twojej strony i odczytuje tylko porozrzucane fragmenty tekstu.
- Znaczniki wtyczek bez dostępnej nazwySlidery, pop-upy i formularze z wtyczek często wstrzykują przyciski i pola bez etykiety czy aria-label. Użytkownik czytnika ekranu słyszy wtedy tylko „przycisk” i nie wie, co dana akcja robi.
- Zepsuta kolejność nagłówków z kreatoraKreatory stron często dobierają nagłówki według rozmiaru, a nie znaczenia, przez co z h2 przeskakujesz od razu do h4. Użytkownicy czytników ekranu nawigują po nagłówkach i tracą wątek Twojej strony.
- Obrazy z biblioteki mediów bez tekstu alternatywnegoObrazy z biblioteki mediów często trafiają do Twojego motywu bez tekstu alternatywnego albo z nazwą pliku jako altem, nieczytelne dla czytników ekranu i niewidoczne dla Google.
Tak wygląda prawdziwa poprawka
Weźmy przycisk z ikoną z Twojego bloku Elementor lub Gutenberg. Bez dostępnej nazwy użytkownik czytnika ekranu słyszy tylko „przycisk”. Poprawka to jeden atrybut, bez przebudowy:
<button class="elementor-button">
<i class="icon-cart" aria-hidden="true"></i>
</button><button class="elementor-button"
aria-label="<?php esc_attr_e( 'Bekijk winkelwagen', 'theme' ); ?>">
<i class="icon-cart" aria-hidden="true"></i>
</button>Gdzie naprawiasz to w samym WordPressie
WordPress obiecuje WCAG 2.2 AA dla panelu administracyjnego i dołączonych motywów, tam gdzie to możliwe. Dla motywów firm trzecich, wtyczek i Twoich treści nie obiecuje nic. Dokładnie tam jest praca.
- 1Motyw: czytaj accessibility-ready tak, jak to zamierzonoTag oznacza ręczną weryfikację pod kątem 18 podstawowych wymagań: skip link jako pierwszy element fokusowalny, widoczny fokus o grubości co najmniej 2 px, kontrast 4,5:1 i 3:1 dla elementów interfejsu, landmarki, etykiety formularzy, brak migających mediów. WordPress sam dodaje, że tag nie oznacza, iż motyw spełnia WCAG AA, oraz że WCAG dotyczy treści i nie da się go zastosować do motywu.
- 2Tekst alternatywny: w bloku i w biblioteceBlok Image ma pole 'Alternative text' i pole wyboru 'Mark as decorative'; alt w bibliotece mediów jest wartością domyślną, alt w bloku ma pierwszeństwo. Opisz, co obraz wnosi. Uważaj na lightbox: podpis jest tam ukryty (otwarty issue), a przy pustym alt okno powiększenia nie ma nazwy.
- 3Nagłówki i kontrast w edytorzeUżyj zakładki Outline w Document Overview, żeby sprawdzić kolejność nagłówków; tytuł strony jest zwykle h1, zależnie od motywu. Edytor ostrzega przy zbyt niskim kontraście ('This color combination may be hard for people to read'), ale tylko w edytorze, tylko dla bloków z ustawieniami kolorów i nie dla kolorów przezroczystych. Ustaw paletę w theme.json lub Global Styles, a będzie obowiązywać wszędzie.
- 4Język, nawigacja i szablonyAtrybut lang pochodzi z Ustawienia → Ogólne → Język witryny. Blok Navigation ma otwarty issue z pułapką fokusu w menu nakładkowym przy rozwiniętym podmenu; przetestuj swoje menu, używając tylko Tab i Esc. Szablony i części szablonów nadpisujesz w motywie potomnym po nazwie pliku albo w Site Editor w motywie blokowym.
- 5Kreatory stron i wtyczkiElementor twierdzi, że wystarczy dostarczyć dostępną treść, ale skip link dostajesz tylko z motywem Hello, przy Canvas lub Full Width samodzielnie ustawiasz CSS ID 'content', a ARIA idzie przez custom attributes. Divi 4 odsyła w sprawie fokusu klawiatury i ARIA do produktów z marketplace; Divi 5 dodaje semantykę i ARIA przez Custom Attributes. Wszystko, co renderuje kreator lub wtyczka, znajduje się na tej samej stronie i liczy się w audycie.
WordPress Accessibility Team odradza widżety nakładkowe (overlay): żadne zautomatyzowane narzędzie samo w sobie nie zapewnia zgodności. Elementor sprzedaje taki widżet jako 'Ally', a marketplace Divi jako 'Accessibility Sidebar'. Warstwa nałożona na Twoją witrynę nie naprawia bloków pod spodem.
Co otrzymujesz
Na każdy błąd: co, dlaczego i jak
Dla każdego ustalenia widzisz, co jest nie tak, kogo to dotyczy, której reguły WCAG dotyczy i konkretne, świadome WordPress rozwiązanie, z przykładem kodu tam, gdzie to możliwe.
Wykrywanie specyficzne dla platformy
Wychwytujesz błędy, które powstają właśnie na WordPress, a nie tylko to, co wyłapuje ogólny test WCAG.
Dokumentacja, która się obroni
Opatrzony datami przegląd Twoich skanów i ustaleń, który możesz pokazać przy audycie lub inspekcji.
Przy narzędziu raportującym płacisz za licencję oraz swoim deweloperom za naprawę błędów. W Seviranta poprawka jest w cenie, bez podwójnego rachunku.
Chroń swoją konwersję i swój status prawny
Aplikacja, która dokleja ikonę dostępności na Twoją stronę WordPress, to ryzyko dla Twojego biznesu. Oto fakty:
Widżety dostępności WordPress
- Ładują dodatkowe zewnętrzne skrypty, które szkodzą Twojej szybkości ładowania (LCP), a tym samym konwersji.
- Maskują błąd, zamiast go rozwiązać, kod u podstaw pozostaje wadliwy.
- Nie chronią przed roszczeniami. FTC ukarała dostawcę nakładek accessiBe w 2025 roku grzywną w wysokości 1 miliona $ za wprowadzające w błąd zapewnienia o zgodności.
Podejście Seviranta
- 0% wpływu na szybkość ładowania, skanujemy z zewnątrz, z naszych serwerów w UE.
- Naprawiamy prawdziwy kod źródłowy Twoich szablonów WordPress.
- Automatycznie budujemy Twoje trwałe dossier EAA, gotowe do okazania organowi nadzoru.
Pytania i odpowiedzi
- Mój motyw jest accessibility-ready. Czy to wystarczy?
- Nie. Tag mówi, że motyw spełnia podstawowe wymagania zespołu weryfikującego; WordPress sam zaznacza, że nie jest to deklaracja WCAG AA. Twoje treści, wtyczki i kreator dochodzą do tego, i tam jest najwięcej uwag.
- Sprzedaję lub publikuję też dla Niemiec lub Francji. Co obowiązuje tam moją witrynę WordPress?
- Niemcy: BFSG obowiązuje od 28 czerwca 2025 sklepy internetowe B2C, z wyjątkiem dla mikroprzedsiębiorstw (mniej niż dziesięć osób i maksymalnie 2 miliony euro obrotu lub sumy bilansowej); nadzór sprawuje Marktüberwachungsstelle der Länder (MLBF). Francja: od 28 czerwca 2025 e-commerce podlega transpozycji EAA w Code de la consommation, z tym samym wyjątkiem dla mikroprzedsiębiorstw, pod nadzorem DGCCRF; miarą jest RGAA (WCAG 2.1 AA). W obu krajach liczy się opublikowana strona, a nie fakt, że korzystasz z WordPressa.
- Czy mogę wprowadzić poprawkę samodzielnie w Site Editor, czy potrzebuję developera?
- Kolory, nagłówki, teksty alternatywne, strukturę menu i wiele części szablonów możesz zmienić samodzielnie w edytorze lub Site Editor. Znaczniki z wtyczek lub kreatora często wymagają developera: nadpisanie szablonu w motywie potomnym, filtr albo ustawienie we wtyczce. Nasz raport przy każdej uwadze mówi, gdzie ona siedzi, więc wiesz, kto może się nią zająć.
- Czy widżet dostępności WordPress wystarczy dla EAA?
- Nie. Widżet kładzie warstwę na Twoją stronę, ale nie naprawia kodu u podstaw i nie liczy się jako zgodność strukturalna.
- Czy mój checkout WordPress podlega EAA?
- Tak. Checkout i nawigacja są wprost częścią obowiązku w ramach WCAG 2.1 AA.
- Czy Seviranta skanuje też moje aplikacje WordPress?
- Tak. Testujemy ostateczny wygenerowany HTML, motyw plus aplikacje, tak, jak robi to organ nadzoru.
- Czy to spowolni moją stronę WordPress?
- Nie. Skanujemy z zewnątrz, z naszych serwerów w UE; żaden skrypt nie trafia na Twoją stronę. 0% wpływu na szybkość ładowania i Core Web Vitals.
Sami też tak robimy
Trzymamy się dokładnie tej samej poprzeczki: nasza własna strona osiąga 0 błędów w axe-core, tym samym silniku, który działa w Google Lighthouse i którym skanujemy też Twój sklep na WordPress. To, co maszyna stwierdza z pewnością, rozwiązujemy maszynowo, resztę ocenia człowiek. Tak dokładnie dostajesz to od nas: zobacz prawdziwy przykładowy raport.
Czego EAA wymaga od Twojego sklepu WordPress
Od czerwca 2025 Twój sklep internetowy musi spełniać WCAG 2.1 AA, sklep WordPress nie jest wyjątkiem. Darmowy skan w 60 sekund pokazuje, na jakim jesteś etapie, wraz z dokładną linijką, która nie spełnia wymogów.
Sprzedajesz w więcej niż jednym kraju?
WCAG to światowy standard. Niemal każdy rynek się na nim opiera:
Dostosuj swój sklep WordPress do WCAG jeden raz, a spełnisz techniczną poprzeczkę na wszystkich tych rynkach. To, co różni się w zależności od rynku, to organ nadzoru i kary.
Zobacz, co obowiązuje na danym rynku zbytu →Zarządzasz wieloma stronami WordPress dla klientów?
Nie dopuść, by sklepy internetowe, które oddajesz, stały się dla Twoich zleceniodawców ryzykiem prawnym w świetle EAA. Wykorzystaj Seviranta jako swój zautomatyzowany stempel jakości przy każdym wdrożeniu i każdym deployu, jeden skan i każda strona jest dowodnie w porządku.
Zobacz nasz program partnerski →Inne platformy
Czytaj dalej
Przeskanuj swój sklep WordPress za darmo
Wklej adres URL swojego WordPressa do darmowego skanu i zobacz w ciągu minuty, które linijki nie spełniają wymogów, wraz z dokładnym miejscem w Twoim motywie lub kreatorze stron.