WordPress nie jest ani dostępny, ani niedostępny sam z siebie. Gotowy serwis powstaje z rdzenia, motywu, wtyczek, własnego kodu, konfiguracji i treści. Każda z tych warstw może wprowadzić bariery. Oznaczenie motywu jako „accessibility-ready” jest użyteczną wskazówką, ale nie jest certyfikatem całej strony.
Audyt przed wyborem komponentów
Motyw i wtyczki trzeba oceniać na działających przykładach. Szczególne ryzyko tworzą menu, wyszukiwarki, formularze, karuzele, galerie, modale, banery cookies, kalendarze, mapy i systemy rezerwacyjne. Dostępna demonstracja jednego widoku nie potwierdza działania wszystkich konfiguracji.
Przed zakupem warto ustalić politykę aktualizacji, wsparcie autora i możliwość wprowadzania poprawek bez modyfikowania plików, które zostaną nadpisane. Rozwiązanie powinno mieć jasne API, semantyczny HTML i możliwość sterowania klawiaturą bez dodatkowych obejść.
Motyw i wzorce redakcyjne
Motyw odpowiada za globalną strukturę, kontrast, fokus, nawigację, zachowanie po powiększeniu i responsywność. Redaktor nie powinien ręcznie wybierać koloru każdego tekstu ani budować układu pustymi kolumnami. Projekt systemu powinien oferować ograniczony zestaw przetestowanych komponentów: nagłówki, alerty, karty, przyciski, tabele i sekcje.
Edytor blokowy może wspierać dostępność, jeśli wzorce narzucają poprawną kolejność i semantykę. Może ją również osłabić, gdy użytkownik otrzymuje nieograniczoną swobodę w zagnieżdżaniu bloków, zmianie kolorów i ukrywaniu treści. Uprawnienia, wzorce i szkolenie powinny odpowiadać kompetencjom redakcji.
Wtyczki i integracje
Wtyczka może wprowadzić własne przyciski, okna dialogowe, komunikaty i style. Trzeba sprawdzić ją w kontekście motywu, ponieważ konflikt CSS lub JavaScript może zepsuć widoczny fokus albo kolejność. Aktualizacja jednego elementu może zmienić zachowanie całej strony.
System osadzony w ramce albo otwierany na zewnętrznej domenie pozostaje częścią ścieżki użytkownika. Należy testować pełny proces i wymagać dostępności od dostawcy. Informacja „za system odpowiada partner” nie pomaga użytkownikowi, który nie może kupić biletu lub wysłać formularza.
Formularze i komunikaty dynamiczne
Formularz wymaga prawidłowych etykiet, instrukcji, oznaczenia pól obowiązkowych, dostępnej walidacji i logicznego zarządzania fokusem. Komunikat „formularz zawiera błędy” powinien prowadzić do konkretnych pól. Po wysłaniu użytkownik musi otrzymać dostępne potwierdzenie, także w czytniku ekranu.
AJAX i dynamiczne aktualizacje wymagają informowania technologii asystujących o zmianie stanu. Dodanie atrybutów ARIA bez zrozumienia zachowania może pogorszyć sytuację. W pierwszej kolejności należy korzystać z natywnych elementów HTML, a złożone wzorce wdrażać zgodnie z ich pełnym modelem klawiatury.
Aktualizacje i testy regresji
Aktualizacje są niezbędne dla bezpieczeństwa. Nie można jednak wdrażać ich bez sprawdzenia kluczowych ścieżek. Środowisko testowe powinno odtwarzać konfigurację produkcyjną, a lista regresji obejmować nawigację, formularze, wyszukiwarkę, powiększenie, klawiaturę i komponenty zmieniane w danej wersji.
Poprawki dostępności należy utrzymywać w motywie potomnym, własnej wtyczce lub źródle pod kontrolą wersji. Doraźna zmiana pliku wtyczki może zniknąć po aktualizacji. Każde obejście powinno mieć opis przyczyny, test i warunek usunięcia, gdy dostawca naprawi problem źródłowo.
Odpowiedzialność po uruchomieniu
Właściciel serwisu ustala standard i priorytety. Administrator utrzymuje system. Wykonawca odpowiada za zakres umowy. Redaktorzy odpowiadają za treści w granicach swoich uprawnień. Koordynator dostępności wspiera i monitoruje, ale nie zastępuje wszystkich ról.
Stały model obejmuje testy aktualizacji, przegląd wtyczek, kontrolę nowych wzorców, szkolenie redakcji, rejestr zgłoszeń i okresowy audyt. Dzięki temu WordPress pozostaje rozwijanym produktem, a nie stroną „odebraną” raz na zawsze.
Powiązane materiały: WordPress a dostępność po aktualizacji, Standardy publikacji oraz Dostępność po uruchomieniu strony.