WordPress, na którym według W3Techs działa 39,6% wszystkich stron internetowych, właśnie cofnął poprawkę dostępności, na którą osoby niewidome czekały sześć lat. Chodziło o powiadomienia w panelu administracyjnym, których czytnik ekranu nie ogłasza. Wyjaśniamy, co się stało, dlaczego spór wyszedł daleko poza kod i co z tej historii wynika dla każdego, kto prowadzi stronę na WordPressie.

Co się stało w połowie października

W 2020 roku Andrea Fercia, wieloletni specjalista ds. dostępności w projekcie WordPress, otworzył zgłoszenie #50486 „Improve the admin notices accessibility”. Opisał w nim prosty, ale dotkliwy problem: powiadomienia w panelu administracyjnym (komunikaty o zapisaniu zmian, ostrzeżenia, błędy) nie mają znaczników, które identyfikowałyby je dla technologii wspomagających. Osoba korzystająca z czytnika ekranu nie dowiaduje się, że komunikat się pojawił, a osoba poruszająca się klawiaturą nie może do niego przeskoczyć.

Według The Repository zgłoszenie było przesuwane przez siedem kolejnych wydań. Na początku października 2026 r. core committer Joe Dolson wprowadził uproszczoną poprawkę, którą Fercia zrecenzował i poparł. Zmiana:

  • umieszczała powiadomienia w obszarze nawigacyjnym (tzw. landmarku), do którego można przejść skrótem,
  • dodawała liczbę powiadomień do tytułu strony, czyli do pierwszej informacji, jaką czytnik ekranu ogłasza po wczytaniu strony.

Dzień później wyszedł błąd: licznik w tytule pokazywał powiadomienia, których nie było, np. „(2 notices)” przy każdym wejściu na kokpit. Dolson przygotował poprawkę licznika, a dyskusja trwała, gdy w zgłoszeniu pojawił się pierwszy w jego historii komentarz współzałożyciela WordPressa Matta Mullenwega: „Please revert all of this”. W tym samym komentarzu Mullenweg napisał do Fercii, że nie pełni on już żadnych funkcji w WordPress.org i jest „zaproszony do wnoszenia swoich talentów do innego projektu”.

Około 19 godzin później Dolson cofnął zmiany. W opisie commita uzasadnił to technicznie: obsługa powiadomień w panelu jest na tyle złożona, że zmiana okazała się przedwczesna, a jego poprawka ograniczyłaby fałszywe alarmy, ale „nie na tyle, by trafić do produkcji”. Serwis WPWithin podaje, że cofnięcie nastąpiło 14 października, a zgłoszenie trafiło do kategorii „Future Release”, czyli bez wyznaczonego wydania.

Konto zablokowane, przeprosiny i list otwarty

Wkrótce po komentarzu konto Fercii w WordPress.org zostało zablokowane. Mullenweg przeprosił za to na Slacku projektu i napisał, że blokada „nie miała się wydarzyć”. Konto przywrócono. Jednocześnie, jak relacjonuje The Repository, Mullenweg potwierdził, że odsunięcie Fercii nie było pomyłką: był „po prostu już niezainteresowany jego wkładem”. Fercia odmówił komentarza.

To nie pierwsze napięcie wokół zespołu dostępności. W sierpniu Mullenweg stwierdził, że zespół „przekroczył swoje uprawnienia”, i zapowiedział, że inne zespoły mogą uchylać jego zalecenia. W 2025 r. proponował też, by poprawki dostępności rozwijać jako osobną, oficjalną wtyczkę zamiast w rdzeniu systemu. Sam Mullenweg mówił wtedy The Repository, że zawsze był „głęboko zaangażowany w dostępność jako kluczowy element produktów WordPressa”.

18 października Darrell Hilliker, niewidomy użytkownik czytnika ekranu i certyfikowany specjalista IAAP CPWA, opublikował w Blind Access Journal list otwarty do Mullenwega. Hilliker podkreśla, że poprawianie czy cofanie niedopracowanego kodu to normalna część pracy nad oprogramowaniem. Zastrzeżenia budzi u niego sposób podjęcia decyzji i to, co jej towarzyszyło. Pyta m.in., czy dostępność jest dla WordPressa wymaganiem równym wydajności i bezpieczeństwu oraz jaki jest plan i harmonogram naprawy powiadomień.

Joe Dolson zasugerował, by tę pracę kontynuować w ramach projektu Feature Notifications, który w październiku wznowił Jonathan Bossenger, developer advocate w firmie Automattic. Jak pisze The Repository, wersja 0.3.0 ma się ukazać jako wtyczka 1 grudnia, ale nie ma terminu włączenia jej do rdzenia.

Dlaczego „zwykłe powiadomienie” to bariera

Komunikat „Zmiany zapisane” albo „Nie udało się opublikować wpisu” widzący użytkownik zauważa od razu. Jeśli komunikat nie jest odpowiednio oznaczony w kodzie, czytnik ekranu go nie przeczyta. Osoba niewidoma nie wie wtedy, czy jej działanie się udało.

W WCAG 2.2 opisują to trzy kryteria:

  • 4.1.3 Komunikaty o stanie (poziom AA) – komunikaty o stanie muszą być programowo określone przez rolę lub właściwości, tak by technologie wspomagające mogły je przekazać bez przenoszenia fokusu. W praktyce chodzi o role="status", role="alert" albo aria-live.
  • 2.4.1 Możliwość pominięcia bloków (poziom A) – landmarki i linki „przejdź do” pozwalają szybko dotrzeć do ważnej części strony.
  • 2.4.2 Tytuł strony (poziom A) – tytuł strony ma opisywać jej temat lub cel. Właśnie tę informację czytnik ogłasza jako pierwszą, dlatego licznik powiadomień w tytule był sensownym pomysłem, dopóki nie zaczął pokazywać fałszywych wartości.

Panel administracyjny to narzędzie do tworzenia treści. Dla takich narzędzi W3C ma osobne wytyczne, ATAG 2.0, które obejmują też dostępność samego interfejsu edytora. Jeśli redaktor, księgowa czy rzecznik prasowy z niepełnosprawnością nie może samodzielnie opublikować wpisu, to jest to również bariera w miejscu pracy.

Co to oznacza dla Twojej strony na WordPressie

Uspokajamy: cofnięta zmiana dotyczyła wyłącznie panelu administracyjnego, a nie stron, które widzą odwiedzający. Z tej historii wynikają jednak trzy praktyczne wnioski.

  1. Za dostępność strony odpowiadasz Ty, nie dostawca CMS-a. Obowiązki z ustawy o dostępności cyfrowej czy Polskiego Aktu o Dostępności spoczywają na właścicielu serwisu. Nie przeniesiesz ich na WordPressa ani na autora motywu.
  2. Komunikaty o stanie na stronie publicznej to częsty i niewidoczny dla skanerów problem. „Dodano do koszyka”, „Wiadomość wysłana”, „Brak wyników wyszukiwania” – jeśli motyw lub wtyczka nie ogłasza ich czytnikowi ekranu, część klientów nie wie, co się stało. Automatyczne testy rzadko to wychwytują, o czym pisaliśmy w tekście Czy darmowy skaner WCAG wystarczy do oceny zgodności?
  3. Tempo poprawek w rdzeniu systemu jest nieprzewidywalne. Zgłoszenie #50486 czekało sześć lat. Jeśli Twoja organizacja zatrudnia osoby korzystające z czytników ekranu, nie zakładaj, że panel wkrótce sam się poprawi. Zaplanuj obejście, np. sprawdzanie stanu wpisu na liście wpisów po każdej publikacji.

Lista kontrolna: komunikaty i powiadomienia w WordPressie

  • [ ] Wyślij formularz kontaktowy z błędem i bez błędu. Sprawdź czytnikiem ekranu (np. NVDA), czy komunikat zostaje odczytany bez szukania go ręcznie.
  • [ ] W sklepie dodaj produkt do koszyka i zmień jego ilość. Czy czytnik ogłasza zmianę?
  • [ ] Wyszukaj frazę, która nie daje wyników. Czy informacja o braku wyników jest ogłaszana?
  • [ ] W narzędziach deweloperskich sprawdź, czy kontener komunikatów ma role="status", role="alert" albo aria-live, i czy istnieje w kodzie, zanim pojawi się w nim treść.
  • [ ] Upewnij się, że komunikaty nie znikają same po kilku sekundach albo że da się wydłużyć czas ich wyświetlania.
  • [ ] Sprawdź, czy ważne komunikaty nie są przekazywane wyłącznie kolorem (np. czerwona ramka bez tekstu).
  • [ ] Przejdź stronę klawiaturą: czy z każdego miejsca da się dotrzeć do komunikatu o błędzie i do pola, którego dotyczy?
  • [ ] Wybierając motyw, sprawdź, czy ma tag accessibility-ready w katalogu WordPress.org, i przeczytaj wymagania zespołu motywów. To dobry punkt wyjścia, ale nie zastępuje audytu.
  • [ ] Po każdej większej aktualizacji motywu lub wtyczki powtórz te testy i zaktualizuj deklarację dostępności.
  • [ ] Jeśli w zespole pracują osoby z niepełnosprawnościami, zapytaj je, które ekrany panelu sprawiają kłopot, i zgłoś te problemy dostawcom wtyczek.

Wniosek

Spór wokół zgłoszenia #50486 jest po części techniczny: pierwsza wersja poprawki miała prawdziwy błąd i jej cofnięcie dało się uzasadnić. Ale sposób, w jaki odsunięto specjalistę, który według jego profilu w WordPress.org współtworzył 33 wydania systemu, pokazuje, jak kruche jest to, co wydaje się oczywiste w największym systemie stron na świecie. Dla właścicieli stron wniosek jest prosty: dostępności nie da się zlecić CMS-owi. Trzeba ją sprawdzać samemu, regularnie i z udziałem użytkowników czytników ekranu.

Źródła