Dostępność w sieci oznacza tworzenie stron internetowych, które osoby z niepełnosprawnościami mogą skutecznie używać. Obejmuje to osoby korzystające z czytników ekranu, nawigacji tylko za pomocą klawiatury, kontroli głosowej, powiększaczy ekranu lub osoby z ograniczeniami widzenia kolorów. W ekosystemie WordPress dostępność jest zarówno wymogiem prawnym w wielu jurysdykcjach, jak i praktycznym sposobem dotarcia do szerszej publiczności — ponad 1 miliard ludzi na całym świecie ma jakąś formę niepełnosprawności.
W tym przewodniku przedstawiamy praktyczne kroki, aby uczynić Twoją stronę WordPress dostępną, zgodnie z Wytycznymi dotyczącymi dostępności treści w sieci (WCAG) 2.2 na poziomie AA — standardem najczęściej wymaganym przez przepisy dotyczące dostępności, w tym ADA (USA), EAA (UE) i AODA (Kanada).
Zrozumienie zasad WCAG 2.2
WCAG jest zorganizowane wokół czterech zasad, znanych jako POUR:
| Zasada | Co to oznacza | Przykłady WordPressa |
|---|---|---|
| Postrzegalność | Użytkownicy mogą postrzegać treść za pomocą wzroku, słuchu lub dotyku | Tekst alternatywny dla obrazów, napisy do filmów, wystarczający kontrast kolorów |
| Operacyjność | Użytkownicy mogą nawigować i interagować z interfejsem | Nawigacja za pomocą klawiatury, linki pomijające, brak pułapek klawiaturowych |
| Zrozumiałość | Użytkownicy mogą zrozumieć treść i jak używać interfejsu | Jasny język, spójna nawigacja, komunikaty o błędach |
| Solidność | Treść działa w różnych przeglądarkach, urządzeniach i technologiach wspomagających | Poprawny HTML, odpowiednie role ARIA, semantyczne znaczniki |
Wybór dostępnego motywu
Struktura HTML i CSS motywu WordPress stanowi fundament dostępności Twojej strony. Przy wyborze motywu WordPress oceń te czynniki dostępności:
- Semantyczny HTML: Motyw używa odpowiednich elementów HTML5 (header, nav, main, article, aside, footer) zamiast ogólnych divów dla wszystkiego
- Hierarchia nagłówków: H1 → H2 → H3 podąża za logiczną kolejnością bez pomijania poziomów
- Linki pomijające: Link "Przejdź do treści" jest obecny jako pierwszy element, który można skupić, umożliwiając użytkownikom klawiatury ominięcie nawigacji
- Nawigacja za pomocą klawiatury: Wszystkie interaktywne elementy (linki, przyciski, formularze) są osiągalne i użyteczne za pomocą klawisza Tab
- Wskaźniki fokusu: Elementy w fokusu mają widoczny kontur lub podświetlenie (nie usunięte za pomocą outline: none)
- Kontrast kolorów: Tekst spełnia wymagania kontrastu WCAG AA (4.5:1 dla normalnego tekstu, 3:1 dla dużego tekstu)
Motywy oznaczone jako "gotowe do dostępności" na WordPress.org przeszły podstawowy przegląd dostępności. Jednak ta etykieta wskazuje na punkt wyjścia, a nie pełną zgodność z WCAG. Wśród popularnych motywów, GeneratePress wyróżnia się dobrze napisanym kodem z czystym semantycznym HTML i odpowiednimi punktami ARIA.
Dostępność obrazów
Tekst alternatywny
Każdy znaczący obraz potrzebuje opisowego tekstu alternatywnego. WordPress ułatwia to — pole tekstu alternatywnego jest dostępne w Bibliotece Mediów oraz podczas wstawiania obrazów do treści.
| Typ obrazu | Podejście do tekstu alternatywnego | Przykład |
|---|---|---|
| Zdjęcie produktu | Opisz produkt | "Czerwona skórzana torba na ramię z złotym zapięciem, widok z przodu" |
| Zrzut ekranu | Opisz, co pokazuje zrzut ekranu | "Panel WordPressa pokazujący stronę Wtyczki z 12 aktywnymi wtyczkami" |
| Infografika | Podsumuj kluczowe informacje | "Wykres porównawczy: funkcje Elementor vs Gutenberg. Elementor ma ponad 100 widgetów, Gutenberg ma ponad 90 bloków" |
| Obraz dekoracyjny | Pusty tekst alternatywny (alt="") | Wzory tła, dzielniki, czysto dekoracyjne ikony |
| Wykres/graf | Opisz trend lub kluczowy punkt danych | "Wykres liniowy pokazujący wzrost ruchu na stronie o 45% od stycznia do grudnia 2025" |
Optymalizacja obrazów pod kątem dostępności
- Nie używaj obrazów tekstu — zamiast tego użyj rzeczywistego tekstu stylizowanego za pomocą CSS
- Upewnij się, że tekst osadzony w obrazach spełnia wymagania dotyczące kontrastu
- Podaj długie opisy dla skomplikowanych obrazów (wykresy, diagramy) używając sąsiedniego akapitu lub atrybutu longdesc
- Upewnij się, że obrazy mają odpowiednie wymiary, aby nie powodować przesunięć układu (CLS)
Nawigacja za pomocą klawiatury
Wielu użytkowników nawiguję po stronach internetowych wyłącznie za pomocą
klawiatura—Tab, aby przejść do przodu, Shift+Tab, aby przejść do tyłu, Enter, aby aktywować linki/przyciski, Spacja, aby przełączać pola wyboru i klikać przyciski, oraz Escape, aby zamknąć modale.
Typowe problemy z dostępnością za pomocą klawiatury
- Pułapki fokusowe: Okna modalne, które nie pozwalają na powrót do głównej treści (modale powinny zatrzymywać fokus wewnątrz modalu, a Escape powinno je zamykać)
- Brak wskaźników fokusu: CSS, który usuwa domyślny kontur na elementach z fokusem (nigdy nie używaj *:focus { outline: none } globalnie)
- Elementy nieinteraktywne z obsługą kliknięć: Divy lub spany z zdarzeniami onClick, które nie są dostępne za pomocą klawiatury (zamiast tego używaj przycisków lub linków)
- Menu rozwijane, które otwierają się tylko na najeżdżanie: Użytkownicy klawiatury nie mogą wywołać stanów najechania. Menu powinny otwierać się również na fokus/Enter
- Niestandardowe komponenty bez ARIA: Karty, akordeony i karuzele zbudowane bez odpowiednich ról ARIA i obsługi klawiatury
Kolor i kontrast
WCAG AA wymaga tych minimalnych współczynników kontrastu:
| Element | Minimalny współczynnik | Przykład (Zaliczony) | Przykład (Niezaliczony) |
|---|---|---|---|
| Normalny tekst (<18px) | 4.5:1 | #333 na #fff (12.6:1) | #999 na #fff (2.8:1) |
| Duży tekst (≥18px lub ≥14px pogrubiony) | 3:1 | #555 na #fff (7.4:1) | #aaa na #fff (2.3:1) |
| Komponenty UI (przyciski, pola wejściowe) | 3:1 | Przycisk niebieski #2563eb (4.6:1) | Jasnoniebieski #93c5fd (1.8:1) |
| Treść nie-tekstowa (ikony, ramki) | 3:1 | Ciemna ikona na jasnym tle | Jasnoszara ikona na białym tle |
Użyj narzędzi takich jak WebAIM's Contrast Checker lub rozszerzenie przeglądarki axe, aby zweryfikować współczynniki kontrastu. Nie polegaj tylko na kolorze, aby przekazać informacje—użyj etykiet tekstowych, wzorów lub ikon oprócz kodowania kolorami.
Dostępność formularzy
Formularze są jednym z najważniejszych obszarów dostępności. Niezależnie od tego, czy używasz bloków Gutenberg, Gravity Forms, czy WPForms:
- Oznacz każdy input: Użyj elementu <label> powiązanego z każdym inputem za pomocą atrybutu for/id. Tekst zastępczy nie jest substytutem dla etykiet
- Grupuj powiązane pola: Użyj <fieldset> i <legend> dla grup powiązanych inputów (np. pola adresu wysyłki)
- Podawaj komunikaty o błędach: Gdy walidacja się nie powiedzie, wskaż, które pole ma błąd i opisz, jak go naprawić. Użyj aria-describedby, aby powiązać komunikaty o błędach z ich polami
- Oznacz pola wymagane: Użyj atrybutu required i wizualnie oznacz pola wymagane tekstem (nie tylko gwiazdką)
- Obsługuj autouzupełnianie: Dodaj odpowiednie atrybuty autouzupełniania (name, email, tel, address-line1), aby przeglądarki mogły automatycznie wypełniać dane formularza
Dostępność treści
Struktura nagłówków
Odpowiednia hierarchia nagłówków pomaga użytkownikom czytników ekranu zrozumieć strukturę strony i nawigować między sekcjami. Zasady:
- Jeden H1 na stronę (tytuł strony/wpisu)
- H2 dla głównych sekcji
- H3 dla podsekcji w ramach H2
- Nie pomijaj poziomów (H2 → H4 bez H3 jest niepoprawne)
- Nie używaj nagłówków do stylizacji wizualnej—zamiast tego używaj klas CSS
Tekst linków
Unikaj ogólnego tekstu linków, który nie ma sensu poza kontekstem:
| Słaby tekst linku | Dostępny tekst linku |
|---|---|
| "Kliknij tutaj" | "Przeczytaj przewodnik po bezpieczeństwie WordPressa" |
| "Czytaj więcej" | "Przeczytaj pełną recenzję Elementor Pro" |
| "Dowiedz się więcej" | "Dowiedz się, jak zoptymalizować proces zakupu WooCommerce" |
| "Tutaj" | "Pobierz raport o wynikach wydajności" |
Tablice
Tablice danych powinny zawierać:
- <thead> z elementami <th> dla nagłówków kolumn (z scope="col")
- <th scope="row"> dla nagłówków wierszy
- Element <caption> opisujący cel tabeli
- Prosta struktura—unikaj scalonych komórek, gdy to możliwe, ponieważ są trudne do interpretacji dla czytników ekranu
Testowanie dostępności Twojej strony
| Narzędzie | Typ | Co testuje |
|---|---|---|
| axe DevTools | Rozszerzenie przeglądarki | Zautomatyzowane WCA |
| Wykrywanie naruszeń G | ||
| WAVE | Rozszerzenie przeglądarki / web | Ocena dostępności wizualnej z adnotacjami inline |
| Lighthouse | Chrome DevTools | Audyty dostępności z ocenami i rekomendacjami |
| Testowanie klawiatury | Ręczne | Nawigacja po całej stronie przy użyciu tylko klawiszy Tab, Enter i Escape |
| Czytnik ekranu | Ręczne | Testowanie z VoiceOver (Mac), NVDA (Windows) lub TalkBack (Android) |
Narzędzia automatyczne wychwytują około 30-50% problemów z dostępnością. Ręczne testowanie za pomocą klawiatury i czytnika ekranu jest konieczne, aby zidentyfikować problemy związane z interakcją, których narzędzia automatyczne nie mogą wykryć.
Wtyczki WordPress dla dostępności
- WP Accessibility: Dodaje linki omijające, naprawia powszechne problemy z dostępnością, dodaje pasek narzędzi dla preferencji użytkownika
- One Click Accessibility: Dodaje pasek narzędzi dostępności na froncie (rozmiar czcionki, kontrast, podświetlenie linków)
- Szablony startowe z dostępnością: Astra i GeneratePress mają solidne podstawy dostępności w swoich podstawowych motywach
Uwaga: Wtyczki nakładkowe do dostępności (które dodają pływający widget z przyciskami "napraw") są szeroko krytykowane przez społeczność zajmującą się dostępnością. Nie czynią one strony internetowej dostępną - dodają jedynie powierzchowną warstwę, która może faktycznie zakłócać działanie technologii asystujących. Skup się na wbudowywaniu dostępności w swój motyw i treść, zamiast polegać na nakładkach.
Aby uzyskać więcej szczegółów, zapoznaj się z oficjalną dokumentacją: Wytyczne WCAG, Zespół dostępności WordPress.
Najczęściej zadawane pytania
Czy WordPress jest dostępny od razu po instalacji?
Rdzeń WordPressa znacznie poprawił się pod względem dostępności. Panel administracyjny jest w dużej mierze nawigowalny za pomocą klawiatury, a edytor bloków zawiera etykiety ARIA. Jednak dostępność Twojej strony w dużej mierze zależy od używanego motywu i wtyczek. Motyw o słabej strukturze HTML podważa wbudowane funkcje dostępności WordPressa.
Czy potrzebuję prawnie dostępnej strony internetowej?
W wielu jurysdykcjach tak. ADA (USA), Europejska Ustawa o Dostępności (UE, obowiązująca od czerwca 2025), AODA (Kanada) i podobne przepisy wymagają, aby strony internetowe były dostępne. Konkretne wymagania zależą od Twojej lokalizacji, rodzaju działalności i odbiorców. Skonsultuj się z prawnikiem w celu uzyskania wymagań specyficznych dla Twojej sytuacji.
Czy dostępność wpływa na SEO?
Tak, istnieje znaczące pokrycie. Odpowiednia struktura nagłówków, opisowy tekst alternatywny, semantyczny HTML, szybkie ładowanie stron i przyjazność dla urządzeń mobilnych przynoszą korzyści zarówno dostępności, jak i SEO. Strony, które przestrzegają wytycznych WCAG, mają tendencję do lepszego rankingu, ponieważ zapewniają zasadniczo lepsze doświadczenie użytkownika. Aby zobaczyć najlepsze praktyki SEO, zapoznaj się z naszą listą kontrolną.
Czy kreatory stron mogą tworzyć dostępne strony internetowe?
Elementor i inne kreatory stron mogą tworzyć dostępne treści, jeśli są używane poprawnie. Kluczowe jest zapewnienie odpowiedniej hierarchii nagłówków, dodawanie tekstu alternatywnego do obrazów, używanie semantycznych widgetów (przyciski zamiast stylizowanych divów) oraz testowanie nawigacji klawiaturą. Sam kreator nie decyduje o dostępności - to, jak go używasz, ma znaczenie.
Jaki jest najczęstszy błąd dostępności na stronach WordPress?
Brak lub niewystarczający tekst alternatywny dla obrazów to najczęściej zgłaszane naruszenie WCAG. Drugim najczęstszym jest niewystarczający kontrast kolorów. Oba są łatwe do naprawienia - wymagają uwagi i konsekwentnej praktyki, a nie wiedzy technicznej.
Jak uczynić WooCommerce dostępnym?
Domyślne szablony WooCommerce mają rozsądne standardy dostępności. Kluczowe obszary do weryfikacji: tekst alternatywny dla obrazów produktów, etykiety formularzy w polach kasy, nawigowalność klawiaturą procesu koszyka i kasy oraz dostępne komunikaty o błędach dla niepowodzeń walidacji formularzy. Użycie dostępnego motywu jako podstawy znacznie redukuje potrzebną pracę specyficzną dla WooCommerce.
Twórz dostępne strony WordPress
Zacznij od dostępnej podstawy motywu. Przeglądaj lekkie, dobrze zakodowane motywy, które priorytetowo traktują semantyczny HTML i zgodność z WCAG.
Przeglądaj dostępne motywy →
