Dostępność strony internetowej to nie dodatek dla wybranych, tylko sposób budowania witryny tak, żeby dało się z niej korzystać bez zbędnych przeszkód. W WordPressie temat dotyczy jednocześnie motywu, treści, formularzy, mediów i sposobu pracy redakcji, więc łatwo go zepsuć drobnymi decyzjami, które osobno wyglądają niegroźnie. W tym artykule pokazuję, czym ta dostępność jest w praktyce, jak ją sprawdzić i co poprawić najpierw, żeby efekt był realny, a nie tylko deklarowany.
Najważniejsze informacje na start
- Dostępność oznacza, że z witryny da się korzystać także klawiaturą, czytnikiem ekranu, na małym ekranie i przy słabszym wzroku lub motoryce.
- Praktycznym punktem odniesienia są wytyczne WCAG 2.2 na poziomie AA.
- W WordPressie najczęściej zawodzą motyw, builder, formularze, kontrast kolorów, nagłówki i media.
- Automatyczne testy są pomocne, ale nie zastępują ręcznego sprawdzenia klawiaturą i logicznej kolejności treści.
- W Polsce obowiązki dotyczą nie tylko sektora publicznego, ale też coraz większej części usług cyfrowych.
- Największą różnicę zwykle robią podstawy: semantyczny HTML, widoczny fokus, etykiety pól i sensowna struktura treści.
Jak rozumiem dostępność strony internetowej w praktyce
Kiedy mówię o dostępności, mam na myśli prostą rzecz: użytkownik ma móc odnaleźć treść, zrozumieć ją i wykonać działanie bez walki z interfejsem. To dotyczy nie tylko osób z trwałą niepełnosprawnością, ale też kogoś, kto korzysta z telefonu w słońcu, ma chwilowo złamaną rękę, pracuje na laptopie bez myszy albo po prostu trafia na stronę w biegu i nie ma czasu zgadywać, co oznacza dany przycisk.
W praktyce dostępność jest dla mnie miarą porządku w całej witrynie. Jeśli menu działa przewidywalnie, nagłówki mają sensowną hierarchię, formularze są opisane, a treść nie zależy wyłącznie od koloru czy animacji, strona staje się łatwiejsza w użyciu dla wszystkich. To właśnie dlatego nie traktuję jej jako osobnej „nakładki” na projekt, tylko jako fundament UX, który wpływa na konwersję, liczbę porzuconych formularzy i liczbę pytań do supportu.
W WordPressie to szczególnie ważne, bo nawet dobry CMS nie uratuje źle zbudowanego motywu albo chaotycznej pracy redakcji. Jeśli podstawy są ustawione poprawnie, treści szybciej się czyta, łatwiej je indeksować i prościej rozwijać stronę bez cofania wcześniejszych decyzji. Żeby przejść od ogólnej definicji do konkretów, trzeba zobaczyć standard, na którym opiera się cały temat.
Na jakich zasadach opiera się dobra dostępność
Najbardziej praktycznym punktem odniesienia są WCAG 2.2, czyli zestaw wytycznych opisujących, jak projektować treści internetowe tak, by były bardziej dostępne. W3C porządkuje je wokół czterech filarów: strona ma być postrzegalna, funkcjonalna, zrozumiała i solidna. To nie jest teoria dla auditorów, tylko bardzo użyteczny sposób myślenia o tym, co powinno działać na każdej podstronie.
| Filar | Co oznacza | Jak wygląda to w WordPressie |
|---|---|---|
| Postrzegalna | Treść da się odebrać wzrokiem, słuchem lub technologią wspomagającą. | Alt text przy obrazach informacyjnych, napisy do wideo, odpowiedni kontrast i brak informacji przekazywanych wyłącznie kolorem. |
| Funkcjonalna | Każdy element da się obsłużyć bez przeszkód, także samą klawiaturą. | Widoczny fokus, sensowna kolejność tabulatora, działające menu, poprawne przyciski i linki. |
| Zrozumiała | Układ, komunikaty i treść są przewidywalne oraz czytelne. | Logiczne nagłówki, jasne etykiety formularzy, spójne nazwy przycisków i prosty język w kluczowych miejscach. |
| Solidna | Strona jest zbudowana tak, by współpracować z różnymi przeglądarkami i czytnikami ekranu. | Semantyczny HTML, poprawne użycie elementów interaktywnych i brak komponentów, które udają coś innego niż są. |
W praktyce najczęściej celuje się w poziom AA, bo to rozsądny kompromis między jakością, zakresem zmian i kosztami wdrożenia. WCAG 2.2 dodaje też nowe kryteria względem wcześniejszej wersji, ale dla właściciela strony najważniejsze pozostają podstawy: kontrast tekstu, obsługa klawiaturą, zrozumiałe komunikaty i spójna struktura treści. W Polsce ten temat nie jest już wyłącznie „dobrą praktyką” - dla części stron publicznych i usług cyfrowych wchodzi po prostu w zakres obowiązku. Kiedy znamy zasady, łatwiej zobaczyć, co najczęściej psuje je w samym WordPressie.
Co w WordPressie najczęściej psuje dostępność
Z mojego doświadczenia najwięcej problemów nie robi sam WordPress, tylko to, co dokładamy na wierzchu: motyw, builder, wtyczki i sposób, w jaki redaktorzy składają treści. System potrafi być bardzo dobrym fundamentem, ale jeśli nałożysz na niego ciężki szablon i kilka efektownych komponentów bez testów, szybko dostajesz stronę, która wygląda dobrze na zrzucie ekranu, a słabo w realnym użyciu.
- Motyw bez porządnej obsługi klawiatury - użytkownik może utknąć w menu, sliderze albo modalu bez możliwości wyjścia.
- Przyciski zrobione z divów - wyglądają jak interaktywne elementy, ale nie zachowują się jak prawdziwe przyciski ani linki.
- Słaby kontrast i zbyt cienka typografia - szczególnie na przyciskach, etykietach i sekcjach hero, gdzie tekst bywa tylko ozdobą.
- Skakanie po nagłówkach - kilka H2 obok siebie bez logicznej hierarchii albo przypadkowe H4 użyte tylko dlatego, że „ładnie wygląda”.
- Formularze bez etykiet - użytkownik widzi pole, ale czytnik ekranu nie podaje, do czego ono służy.
- Karuzele i animacje bez kontroli - automatyczny ruch przeszkadza, rozprasza i bywa trudny do zatrzymania.
- Treści zapisane wyłącznie obrazem - infografika bez opisu albo przycisk umieszczony na grafice zamiast w HTML.
- Wtyczki dodające własny interfejs - im więcej warstw nadbudowy, tym większe ryzyko konfliktów i błędów semantycznych.
Najbardziej zdradliwe są te problemy, których nie widać na pierwszy rzut oka. Strona może wyglądać nowocześnie, a mimo to być trudna do obsłużenia klawiaturą albo nieczytelna dla czytnika ekranu. Sam opis błędów nie wystarczy, więc następny krok to sprawdzenie witryny w praktyce, bez zgadywania.
Jak sprawdzić stronę bez zgadywania
Najlepszy test dostępności to połączenie automatyzacji i ręcznego przeglądu. Narzędzia potrafią szybko wskazać brak altów, zbyt niski kontrast albo oczywiste błędy w kodzie, ale nie powiedzą ci, czy komunikat jest zrozumiały, czy użytkownik potrafi wyjść z modala i czy kolejność treści ma sens. Dlatego zaczynam od prostych zadań, a nie od listy checkboxów.
- Przejdź stronę samą klawiaturą i sprawdź, czy wszystko da się otworzyć, zamknąć i przejść dalej.
- Sprawdź widoczność fokusu, czyli obrysu aktywnego elementu; jeśli znika, użytkownik traci orientację.
- Przejrzyj nagłówki i upewnij się, że budują logiczną strukturę strony, a nie tylko układają tekst wizualnie.
- Otwórz formularze i zobacz, czy każde pole ma etykietę, a błędy są opisane jasno, nie tylko kolorem.
- Przetestuj stronę przy powiększeniu do 200 procent i na małym ekranie.
- Sprawdź obrazy, wideo i pliki do pobrania - czy mają sensowny opis i czy nie blokują dostępu do treści.
- Uruchom automatyczne narzędzie kontrolne jako pierwszy filtr, a nie jako ostateczny wyrok.
Jeśli mam ocenić czas, mała strona firmowa zwykle daje się przejść ręcznie w kilka godzin, ale sklep albo serwis z wieloma szablonami potrafi zająć kilka dni. To nie jest strata czasu - to koszt, który zwykle zwraca się szybciej niż poprawki wprowadzane „na ślepo”. Dopiero po takim przeglądzie warto przechodzić do zmian w motywie, treści i komponentach.
Jak poprawić dostępność w WordPressie krok po kroku
Gdy poprawiam stronę, zaczynam od miejsc, które wpływają na całość, a nie od pojedynczych ozdobników. W WordPressie największy efekt daje porządek w motywie, sensowna konfiguracja bloków i konsekwentna praca redakcji. Jeśli fundament jest dobry, kolejne podstrony nie rozsypują się przy każdej aktualizacji.
- Wybierz motyw z czystym HTML i wyraźnym fokusem - oznaczenie accessibility-ready może być dobrym sygnałem, ale i tak sprawdzam temat ręcznie.
- Ustal jedną logikę nagłówków - jeden H1 na stronę, potem H2 i H3 zgodnie z treścią, nie z wyglądem.
- Ustaw kontrast na poziomie AA - dla zwykłego tekstu celuję w relację 4.5:1, a nie w „ładnie wygląda na monitorze”.
- Nie opieraj znaczenia wyłącznie na kolorze - błąd formularza, status lub ważny komunikat muszą mieć także tekst.
- Pisz etykiety przycisków konkretnie - „Wyślij formularz”, „Pobierz cennik”, „Zobacz ofertę” mówią więcej niż „Kliknij tutaj”.
- Dodawaj alt text tam, gdzie obraz niesie informację - dekoracyjne grafiki mogą mieć pusty atrybut, ale informacyjne nie mogą być niemymi ozdobami.
- Dorób napisy i transkrypcje do materiałów wideo i audio - bez tego część użytkowników dostaje tylko połowę treści.
- Sprawdź formularze i komunikaty błędów - czytelny błąd przy polu jest lepszy niż ogólny alert na górze strony.
- Ogranicz nadmiar widgetów i efektów - każda dodatkowa warstwa to nowe ryzyko problemów z klawiaturą i czytnikami ekranu.
- Wykorzystaj `theme.json` - w blokowych motywach to dobry sposób na uporządkowanie kolorów, typografii i odstępów u źródła.
W dokumentacji WordPressa mocno wybrzmiewa myślenie semantyczne: elementy mają wyglądać i działać jak to, czym są naprawdę. To praktyczna zasada, nie akademicki slogan, bo właśnie dzięki niej przyciski pozostają przyciskami, linki linkami, a nawigacja nie staje się zbiorem przypadkowych divów. Żeby te poprawki nie rozpadły się po kolejnej aktualizacji, trzeba jeszcze ustawić prosty proces utrzymania.
Jak utrzymać dobry poziom, gdy strona rośnie
Największy błąd, jaki widzę w zespołach, to traktowanie dostępności jak jednorazowego projektu. Tymczasem witryna zmienia się cały czas: dochodzą nowe wpisy, nowe bloki, nowe wtyczki, nowy landing page po kampanii i nowy popup po aktualizacji sprzedażowej. Bez prostych zasad nawet dobrze poprawiona strona potrafi po kilku miesiącach wrócić do stanu wyjściowego.
- Ustal krótką checklistę publikacji dla redaktora.
- Nie dopuszczaj do publikacji bez sprawdzenia nagłówków, linków i altów przy kluczowych grafikach.
- Testuj najważniejsze szablony po każdej większej zmianie motywu lub wtyczki.
- Trzymaj jedną bibliotekę komponentów zamiast budować każdy blok od zera.
- Ustal, kto odpowiada za treść, kto za layout, a kto za test klawiaturą.
- Nie instaluj wtyczek „na próbę”, jeśli dodają własne interfejsy bez sprawdzenia jakości kodu.
W praktyce najlepiej działa podejście, w którym dostępność jest częścią procesu, a nie osobnym zadaniem na koniec sprintu. Dzięki temu łatwiej utrzymać spójność między nowymi podstronami, starszymi wpisami i zmianami wprowadzanymi przez kilka osób naraz. Na końcu zostaje już tylko kolejność działań, bo to ona decyduje, czy projekt ruszy z miejsca.
Od czego zacząłbym poprawki na stronie w tym tygodniu
Gdybym miał wejść na stronę i poprawić ją bez dużego budżetu, zacząłbym od rzeczy, które dają największy zwrot najkrótszą drogą. Nie od animacji, nie od kosmetyki, tylko od elementów, które użytkownik naprawdę musi obsłużyć, żeby wykonać zadanie.
- Przeszedłbym menu, formularze i główne CTA samą klawiaturą.
- Poprawiłbym kontrast, fokus i etykiety tam, gdzie użytkownik najłatwiej się gubi.
- Ułożyłbym nagłówki i treść na pięciu najważniejszych podstronach.
- Usunąłbym albo zastąpił komponenty, które blokują obsługę bez myszy.
- Ustaliłbym jedną checklistę redakcyjną dla wszystkich nowych wpisów i landing page’y.
Jeśli miałbym wskazać jedną zasadę, byłaby bardzo prosta: testuj realne zadania, a nie tylko wygląd strony. To właśnie taka praktyka najszybciej pokazuje, czy witryna jest naprawdę dostępna, czy tylko dobrze wygląda w projekcie.
