WordPress pozwala szybko rozwijać serwis bez przebudowy całego systemu. Administrator może instalować wtyczki, zmieniać układ bloków, dodawać formularze, galerie, banery i kolejne typy treści. Ta elastyczność jest jedną z największych zalet platformy, ale z punktu widzenia dostępności tworzy również poważne ryzyko.
Strona, która przeszła audyt i została poprawiona, nie pozostaje dostępna automatycznie przez następne lata. Aktualizacja motywu może zmienić sposób działania menu. Nowa wtyczka może dodać niedostępne okno modalne. Zmiana układu strony głównej może zaburzyć kolejność nagłówków, a zwykła publikacja plakatu jako obrazu pozbawić część użytkowników dostępu do informacji.
Problemem nie jest sam WordPress. Oficjalne standardy programistyczne projektu odwołują się obecnie do zgodności z WCAG 2.2 na poziomie A i AA, a dokumentacja dla twórców motywów podkreśla konieczność znajomości HTML, CSS, JavaScriptu i zasad dostępności. Nie oznacza to jednak, że każda strona zbudowana na tej platformie jest dostępna. O wyniku decydują wszystkie warstwy serwisu: motyw, wtyczki, konfiguracja, treści i sposób późniejszego utrzymania.
Dostępność nie jest trwałą cechą motywu
Motyw odpowiada za dużą część struktury strony. Określa wygląd i działanie menu, nagłówka, stopki, wyników wyszukiwania, formularzy komentarzy, archiwów i pojedynczych wpisów.
Jeżeli został dobrze zaprojektowany, może zapewniać solidną podstawę dostępności. Nadal nie gwarantuje jednak poprawności całego serwisu.
Administrator może zainstalować kreator stron, który zastąpi część struktury motywu własnym kodem. Wtyczka formularza może używać innych komponentów niż pozostała część serwisu. Baner cookies może zasłaniać fokus, a moduł galerii wprowadzić przyciski bez dostępnych nazw.
Nawet oznaczenie motywu jako przygotowanego z uwzględnieniem dostępności nie powinno być traktowane jak certyfikat gotowej strony. Motyw jest tylko jednym z elementów środowiska. Dopiero jego połączenie z konkretnymi rozszerzeniami i treściami tworzy interfejs, z którego korzysta użytkownik.
Aktualizacja może poprawić bezpieczeństwo i jednocześnie zepsuć interfejs
Aktualizacje WordPressa, motywów i wtyczek są konieczne ze względu na bezpieczeństwo, kompatybilność i usuwanie błędów. Nie powinny być blokowane tylko dlatego, że mogą wpłynąć na wygląd lub działanie strony.
Trzeba jednak liczyć się z tym, że każda większa zmiana może wywołać regresję dostępności. Regresja oznacza, że element wcześniej działający prawidłowo po aktualizacji zaczyna tworzyć barierę.
Może zmienić się kod przycisku otwierającego menu, sposób obsługi fokusu albo struktura formularza. Aktualizacja arkusza stylów może usunąć obramowanie aktywnego elementu. Nowa wersja wtyczki może dodać animację, której nie da się zatrzymać, lub zmienić komunikaty przekazywane czytnikom ekranu.
Takie błędy często nie są widoczne podczas szybkiego oglądania strony. Interfejs wygląda niemal identycznie, ale zachowuje się inaczej podczas obsługi klawiaturą lub technologią wspomagającą.
Największe ryzyko tworzą wtyczki wpływające na interakcję
Nie każda wtyczka ma taki sam wpływ na dostępność. Rozszerzenie wykonujące kopie zapasowe nie zmienia bezpośrednio interfejsu użytkownika. Inaczej jest z wtyczkami tworzącymi formularze, menu, wyskakujące okna, kalendarze, rezerwacje, karuzele i systemy płatności.
Takie rozszerzenia wprowadzają własne komponenty i własny sposób obsługi. Mogą wyglądać poprawnie, ale nie przekazywać technologii wspomagającej informacji o stanie elementu, błędach lub zmianach na ekranie.
Szczególnie ryzykowne są rozwiązania wybierane wyłącznie na podstawie wyglądu, liczby instalacji albo deklaracji producenta. Hasło „accessibility ready” nie wyjaśnia, jaki zakres sprawdzono, według jakiej metody i w jakiej konfiguracji.
W praktyce ta sama wtyczka może działać inaczej zależnie od motywu, ustawień, dodatkowych skryptów i wersji językowej. Dlatego jej rzeczywiste zachowanie trzeba oceniać w docelowym serwisie, a nie na stronie demonstracyjnej producenta.
Edytor blokowy ogranicza część błędów, ale nie zastępuje kompetencji redaktora
WordPress daje redaktorowi dużą swobodę budowania podstron. Można dodawać nagłówki, kolumny, tabele, przyciski, obrazy i elementy osadzone bez zmiany kodu.
To ułatwia pracę, ale powoduje, że dostępność zależy także od codziennych decyzji redakcyjnych.
Redaktor może pominąć poziom nagłówka, użyć pogrubionego akapitu zamiast prawdziwego nagłówka albo opublikować nieopisany wykres. Może zmienić kolor przycisku na nieczytelny, dodać niejednoznaczny link „więcej” albo wkleić tabelę z rozbudowanymi scaleniami.
Sam system nie rozpozna poprawnie wszystkich takich sytuacji. Może zasugerować opis alternatywny lub ostrzec przed wybranym problemem, ale nie zna znaczenia informacji ani celu publikacji.
Dlatego dostępność serwisu WordPress jest w dużej mierze procesem redakcyjnym, a nie tylko właściwością kodu.
Kreator stron może ukrywać rzeczywistą strukturę
Wizualne kreatory pozwalają budować rozbudowane układy metodą przeciągania elementów. Redaktor widzi kolumny, sekcje i przyciski, ale nie zawsze ma kontrolę nad kodem generowanym w tle.
Element wyglądający jak nagłówek może być zwykłym akapitem. Kafelek może reagować wyłącznie na kliknięcie myszą. Zmiana kolejności kolumn na telefonie może nie odpowiadać kolejności odczytu przez czytnik ekranu.
Im bardziej kreator zastępuje standardowe mechanizmy WordPressa własnymi komponentami, tym większe znaczenie ma kontrola gotowego rezultatu.
Nie oznacza to, że każdy kreator jest niedostępny. Problem polega na tym, że dostępności nie można ocenić wyłącznie na podstawie wyglądu w panelu administracyjnym. Trzeba badać kod i zachowanie strony po jej opublikowaniu.
Drobna zmiana może wpłynąć na cały szablon
W WordPressie jedna modyfikacja często pojawia się na setkach podstron. Zmiana komponentu menu wpływa na cały serwis. Aktualizacja szablonu wpisu może zmienić wszystkie artykuły, a błąd w bloku karty usługi powtarzać się na każdej stronie, na której został użyty.
Z punktu widzenia utrzymania dostępności ma to podwójne znaczenie. Dobrze poprawiony komponent pozwala usunąć problem w wielu miejscach jednocześnie. Błędna aktualizacja może jednak równie szybko wprowadzić tę samą barierę w całym serwisie.
Dlatego audyt nie powinien koncentrować się wyłącznie na pojedynczych adresach. Powinien także identyfikować wspólne szablony, komponenty i mechanizmy odpowiedzialne za powtarzalne błędy.
Takie podejście pozwala odróżnić problem pojedynczej treści od błędu systemowego, który wymaga interwencji w motywie lub wtyczce.
Strona główna nie pokazuje dostępności całego WordPressa
Serwis może mieć dopracowaną stronę główną, ale niedostępne archiwum aktualności, wyniki wyszukiwania albo formularz kontaktowy. Może również korzystać z zewnętrznego systemu zapisów, który nie spełnia podstawowych wymagań.
WCAG odnosi zgodność do pełnych stron i kompletnych procesów. Jeżeli wykonanie zadania wymaga przejścia przez kilka kroków, wszystkie elementy tego procesu muszą spełniać wymagania odpowiedniego poziomu.
W serwisie WordPress oznacza to konieczność oceny różnych typów podstron i funkcji. Sam audyt strony głównej nie daje podstaw do stwierdzenia, że dostępny jest formularz, wyszukiwarka, dokumenty, archiwum albo proces zapisów.
Najpoważniejsze problemy często występują właśnie poza reprezentacyjną częścią serwisu, w miejscach rzadziej oglądanych przez administratorów, ale istotnych dla użytkowników.
Aktualizacja deklaracji nie naprawia serwisu
Po zmianie systemu, motywu lub wykonawcy instytucja może zaktualizować deklarację dostępności. Taka aktualizacja nie zastępuje jednak badania strony.
Deklaracja powinna opisywać rzeczywisty stan serwisu. Jeżeli opiera się na dawnym audycie wykonanym przed wdrożeniem nowych wtyczek i przebudową strony, może nie odpowiadać aktualnej sytuacji.
Podobny problem występuje po migracji treści. Nowy motyw może być lepszy technicznie, ale przeniesione dokumenty, tabele i obrazy nadal zawierają stare bariery.
Ocena dostępności musi więc odnosić się do konkretnej wersji działającego serwisu, jego aktualnych funkcji i opublikowanych treści.
Dostępność WordPressa wymaga kontroli po wdrożeniu
Jednorazowy audyt jest potrzebny, ale nie chroni przed wszystkimi przyszłymi zmianami. Serwis rozwija się, otrzymuje nowe moduły i jest obsługiwany przez kolejnych redaktorów.
Najbezpieczniejszy model zakłada kontrolę przed większym wdrożeniem, ponowną ocenę po jego publikacji oraz okresowe sprawdzanie kluczowych procesów. Szczególnej uwagi wymagają zmiany menu, formularzy, systemów zapisów, motywu i komponentów strony głównej.
Nie każda aktualizacja wymaga pełnego audytu całego serwisu. Trzeba jednak umieć ocenić zakres ryzyka i wybrać reprezentatywne obszary do testów regresyjnych.
Wymaga to znajomości architektury strony i wcześniejszych problemów. Bez takiej wiedzy łatwo skontrolować elementy, które nie zostały zmienione, i pominąć komponent odpowiedzialny za nową barierę.
Audyt powinien wskazywać także źródło problemu
Samo stwierdzenie, że przycisk jest niedostępny, nie wystarcza do skutecznej naprawy serwisu WordPress.
Trzeba ustalić, czy błąd pochodzi z motywu, wtyczki, konfiguracji, własnego kodu czy sposobu publikacji treści. Każde z tych źródeł wymaga innej reakcji.
Problem redakcyjny można rozwiązać przez poprawę treści i procedury publikacji. Błąd komponentu wymaga zmiany technicznej. Niedostępność systemu zewnętrznego może wymagać kontaktu z dostawcą, zastosowania alternatywy albo zmiany rozwiązania.
Profesjonalny audyt powinien rozdzielać te obszary, określać priorytet i wskazywać, które problemy powtarzają się systemowo. Dzięki temu instytucja nie poprawia ręcznie setek stron, gdy właściwa zmiana powinna zostać wykonana raz w szablonie.
WordPress nie gwarantuje dostępności, ale pozwala nią skutecznie zarządzać
Elastyczność WordPressa nie musi być wadą. Platforma pozwala tworzyć dostępne motywy, używać poprawnych struktur i rozwijać serwis bez utraty jakości.
Warunkiem jest świadome zarządzanie zmianami.
Dostępność nie może kończyć się w dniu odbioru strony. Musi obejmować wybór rozszerzeń, kontrolę aktualizacji, zasady pracy redaktorów i testy najważniejszych procesów.
Największym zagrożeniem nie jest pojedynczy błąd. Jest nim przekonanie, że skoro strona kiedyś przeszła audyt albo korzysta z dobrego motywu, pozostanie dostępna niezależnie od dalszych zmian.
WordPress jest środowiskiem stale rozwijanym. Dostępność takiego serwisu również musi być utrzymywana, weryfikowana i ponownie oceniana po zmianach, które wpływają na interfejs lub sposób realizacji usług.