Jak poprawić dostępność strony w WordPressie, żeby agent AI znalazł każdy przycisk

Cztery ikony w stopce emedia.pl wystarczyły, żeby każda z pięciu zmierzonych stron oblała kontrolę dostępności dla agentów w Lighthouse. Ikony Facebooka, Instagrama, LinkedIna i TikToka miały pusty atrybut alt. Człowiek je rozpoznaje po kształcie, agent AI i czytnik ekranu dostają cztery linki bez nazwy. Ten wpis tłumaczy, skąd bierze się taki wynik, czym jest drzewo dostępności i jak naprawić najczęstsze usterki w WordPressie bez przebudowy strony.

Materiał opieramy na dokumentacji Chrome dla Lighthouse, na kodzie źródłowym kontroli (lista 33 reguł jest publiczna) i na kursie Learn Accessibility od Google, z którego bierzemy definicje i przykłady. Piszemy dla osoby, która prowadzi stronę firmy, nie dla programisty, ale każdą naprawę opisujemy tak, żeby dało się ją zlecić jednym zdaniem.

Co to jest drzewo dostępności?

Strona, którą widzisz, to obraz namalowany przez przeglądarkę na podstawie kodu HTML. Równolegle przeglądarka buduje drugą strukturę, niewidoczną: drzewo dostępności (accessibility tree). Zawiera każdy element, który ma znaczenie dla obsługi strony, z trzema informacjami: rolą (link, przycisk, pole tekstowe, nagłówek, lista), nazwą (co ten element robi lub jak się nazywa) i stanem (rozwinięty, zaznaczony, wyłączony). Kurs Learn Accessibility opisuje to tak: drzewo powstaje ze standardowego modelu DOM, a technologie wspomagające korzystają z niego przez interfejsy dostępu w przeglądarce.

Z tego drzewa od lat korzystają czytniki ekranu: NVDA i JAWS na Windows, VoiceOver na Macu i iPhonie, TalkBack na Androidzie. Osoba niewidoma nie ogląda strony, tylko przeskakuje po drzewie: klawisz H prowadzi do kolejnego nagłówka, K do kolejnego linku, a landmarki (nagłówek strony, nawigacja, treść główna, stopka) pozwalają wskoczyć do właściwej części. Google pisze wprost, że nagłówki i landmarki to jeden z głównych sposobów nawigacji użytkowników czytników.

Od 2026 roku z tego samego drzewa korzysta trzeci czytelnik: agent AI w przeglądarce. Gemini w Chrome, Comet od Perplexity czy agent ChatGPT dostają polecenie w rodzaju „wyślij zapytanie o wycenę” i muszą znaleźć na stronie właściwy przycisk. Dokumentacja Chrome ujmuje to jednym zdaniem: agenci sprawdzają drzewo dostępności, aby zidentyfikować elementy interaktywne. Jeśli w drzewie jest wpis „przycisk” bez nazwy, agent nie wie, czy to „Wyślij”, „Anuluj” czy „Zamknij okno”. Zgaduje albo rezygnuje. Dlatego Lighthouse w kategorii Przeglądanie agentowe ma osobną kontrolę: drzewo dostępności jest dobrze zbudowane.

Nazwa dostępna: jedno pojęcie, które załatwia połowę błędów

Z 33 reguł, które Lighthouse sprawdza dla agentów, 13 dotyczy jednego: czy element ma nazwę dostępną (accessible name). To tekst, którym drzewo opisuje element. Kurs Google podaje trzy zapisy, które dają dokładnie tę samą nazwę „Czerwone skórzane buty”:

• link z tekstem: nazwa to tekst między znacznikami linku;
• link z obrazkiem: nazwa to atrybut alt tego obrazka;
• pole formularza z etykietą: nazwa to tekst etykiety (label) powiązanej z polem.

Ikona bez tekstu i bez alt nie daje nic. Przycisk z samą lupą, strzałka karuzeli, „hamburger” menu na telefonie, logo w nagłówku, ikony social media w stopce: w każdym z tych miejsc nazwa musi pochodzić z alt obrazka albo z atrybutu aria-label, bo tekstu widocznego nie ma. Kurs dzieli obrazy na cztery typy i dla obrazów funkcjonalnych, czyli takich, które coś robią po kliknięciu, każe opisywać działanie, nie wygląd. Alt ikony Facebooka to nie „niebieskie kółko z literą f”, tylko „Facebook emedia”. Alt logo w nagłówku to nazwa firmy albo „Strona główna”, nie „logo”.

Trzy zasady dla alt, które Google powtarza w kursie: zwięźle, do około 150 znaków; bez słów „zdjęcie” i „obraz”, bo czytnik sam mówi, że to obraz; naturalnie, nie pod wyszukiwarkę. Obraz czysto ozdobny dostaje pusty alt, wtedy drzewo go pomija, i to jest poprawne. Błąd zaczyna się, gdy pusty alt trafia na obraz, który jest linkiem albo przyciskiem. Wtedy pomijany jest link, a nie ozdoba.

Z polami formularza jest podobnie. Placeholder nie jest etykietą: szary tekst w polu znika po kliknięciu i drzewo go nie traktuje jak nazwy. Pole potrzebuje elementu label powiązanego atrybutem for albo atrybutu aria-label. Dotyczy to też pól, których człowiek nie widzi, na przykład ukrytych pól antyspamowych. Dla Lighthouse ukryte pole tekstowe bez etykiety jest takim samym błędem jak widoczne.

33 reguły Lighthouse dla agentów po ludzku

Kontrola „drzewo dostępności jest dobrze zbudowane” nie ma własnych testów. Bierze wyniki 33 reguł z silnika axe, tego samego, który liczy zwykłą ocenę ułatwień dostępu, i sprawdza, czy którakolwiek została naruszona. Wynik jest zero-jedynkowy: 33 reguły czyste to 1, jedno naruszenie to 0. Reguły dzielą się na cztery grupy.

Równie ważne jest to, czego na liście nie ma. Kontrola dla agentów nie sprawdza kontrastu kolorów, brakującego elementu main, kolejności nagłówków, atrybutu języka strony ani alt zwykłych obrazów, które nie są linkami. Te rzeczy obniżają ogólną ocenę ułatwień dostępu, ale nie ułamek w kategorii Przeglądanie agentowe. Strona główna emedia.pl ma 92 na 100 w ułatwieniach dostępu, w tym 19 elementów ze zbyt niskim kontrastem, a mimo to jedyną rzeczą, która oblała kontrolę dla agentów, były cztery ikony bez nazwy.

Pięć zasad ARIA w jednym akapicie

ARIA to zestaw atrybutów, którymi programista dopisuje do kodu rolę, stan i właściwości elementu, gdy zwykły HTML ich nie wyraża. Kurs Google podaje pięć zasad i pierwsza z nich brzmi: nie używaj ARIA. Zwykły przycisk button ma rolę, nazwę i obsługę klawiatury z natury; div z dopisaną rolą przycisku dostaje tylko rolę, a resztę trzeba dorobić ręcznie. Druga zasada: nie dokładaj ARIA do elementów, które już wszystko mają, bo nadmiar psuje więcej niż brak. Trzecia: każdy element interaktywny musi dać się obsłużyć klawiaturą. Czwarta: nie ukrywaj przed drzewem elementów, na które da się przejść Tabem, bo klawiatura je znajdzie, a czytnik i agent nie. Piąta: każdy element interaktywny ma nazwę dostępną. Piętnaście z 33 reguł Lighthouse pilnuje, czy ktoś nie złamał zasady pierwszej i drugiej.

Najczęstsze wpadki w WordPressie i jak je naprawić

Poniżej wpadki, które znaleźliśmy na emedia.pl i które powtarzają się w serwisach klientów. Przy każdej podajemy, gdzie w WordPressie leży naprawa.

Ikony social media w stopce

Najczęstszy błąd i najprostsza naprawa. Ikony wstawione jako galeria obrazków z linkami mają alt pusty, bo edytor tak je zapisuje domyślnie. W bloku stopki (blok galerii lub widget) klikasz każdy obrazek i wpisujesz alt: „Facebook nazwa firmy”, „Instagram nazwa firmy”. Jeśli stopka pochodzi z motywu, a nie z bloku, ta sama zmiana to jeden wiersz w pliku szablonu. Na emedia.pl chodziło o cztery obrazki w jednym bloku i ta poprawka podnosi wynik każdej podstrony serwisu.

Przycisk wyszukiwarki z samą lupą

Formularz wyszukiwania w motywie ma przycisk typu submit, w którym zamiast tekstu siedzi ikona lupy. Naprawa to atrybut aria-label=”Szukaj” na tym przycisku. W motywach blokowych zmienia się to w edytorze witryny, w klasycznych w pliku searchform.php albo przez filtr get_search_form w pliku functions.php motywu potomnego. Ten sam problem mają przyciski „zamknij” w pop-upach i strzałki w karuzelach.

Ukryte pole antyspamowe w formularzu

Wtyczki antyspamowe do Contact Form 7 dodają pole, którego człowiek nie widzi, a robot wypełnia. Dla Lighthouse to pole tekstowe bez etykiety. Część wtyczek antyspamowych ma w ustawieniach tryb dostępny, który dodaje polu etykietę i wyklucza je z drzewa; jeśli Twoja go nie ma, poproś programistę o aria-label i aria-hidden na tym polu, a przy okazji sprawdź, czy pole ma nadal wyłączone autouzupełnianie. Sam formularz kontaktowy potrzebuje etykiet przy każdym polu: w CF7 to znacznik label wokół pola w szablonie formularza, a placeholder go nie zastępuje.

Role ARIA dodawane skryptem

Skrypty motywów i wtyczek „ożywiających” treść potrafią dopisać nagłówkom rolę, która do nagłówka nie pasuje, na przykład rolę przycisku przy zwijanych sekcjach. W statycznym kodzie strony tego nie widać, bo atrybut pojawia się dopiero w przeglądarce. Lighthouse widzi stan po wykonaniu skryptów, dlatego raport pokazuje element z rolą, której w edytorze nie znajdziesz. Naprawa leży w skrypcie: przycisk zwijania ma być osobnym elementem button wewnątrz nagłówka, a nie rolą nadaną nagłówkowi.

Logo, banery i obrazki-linki

Logo w nagłówku prowadzi do strony głównej, więc jest linkiem i potrzebuje nazwy: alt „nazwa firmy, strona główna”. Banery promocyjne wstawione jako obraz z linkiem potrzebują alt z treścią oferty, nie z nazwą pliku. W bibliotece mediów WordPressa alt wpisuje się raz, ale bloki obrazu zapisują alt w treści strony w chwili wstawienia, więc zmiana w bibliotece nie naprawia obrazów już użytych. Trzeba poprawić każde wystąpienie albo zrobić to skryptem po bazie.

Pasek cookies i pop-upy

Okna zgody na cookies bywają zbudowane z div z rolą dialogu bez nazwy albo ukrywają przez aria-hidden warstwę, w której nadal są przyciski dostępne klawiaturą. Obie rzeczy łapią reguły z grupy ARIA. Większość wtyczek do cookies ma to poprawione w nowych wersjach, więc pierwszym krokiem jest aktualizacja, drugim sprawdzenie raportu Lighthouse z zaznaczonym elementem.

Grzegorz Wysocki
CEO emedia

Komentarz autora: nasza stopka z ikonami social media stoi w tym samym kształcie od dawna i nikt nie zgłosił, że czegoś w niej brakuje. Nie brakowało, dopóki jedynym czytelnikiem był człowiek. Wniosek z pomiaru jest dla mnie taki, że dostępność przestała być tematem „dla urzędów i dużych sklepów”. Jeśli agent klienta ma wysłać zapytanie przez nasz formularz, to formularz ma mieć etykiety, a ikony nazwy. To jest dziś warunek sprzedaży, nie dobra praktyka.

Test w 5 minut bez programisty

Trzy sprawdzenia, które wykonasz sam na dowolnej stronie. Google w kursie podaje, że automaty pokrywają około 30 procent kryteriów WCAG, a około 25 procent problemów z dostępnością to brak obsługi klawiatury, więc sam Lighthouse nie wystarczy.

1. Lighthouse, 2 minuty. Otwórz stronę w Chrome 150 lub nowszym, naciśnij F12, zakładka Lighthouse, zaznacz kategorie Accessibility i Agentic browsing, uruchom. Rozwiń pozycję „Accessibility tree is not well-formed” i spisz elementy z kolumny „Failing Element”. To Twoja lista dla programisty.
2. Klawiatura, 2 minuty. Odłóż mysz. Naciskaj Tab i patrz, czy widzisz, gdzie jesteś, i czy trafiasz po kolei w menu, treść, formularz i stopkę. Enter uruchamia link lub przycisk, spacja zaznacza pole wyboru, Esc zamyka pop-up. Jeśli fokus znika albo zapętla się w oknie cookies, masz problem, którego Lighthouse nie zgłosi.
3. Czytnik ekranu w telefonie, 1 minuta. Na iPhonie włącz VoiceOver, na Androidzie TalkBack, i przesuwaj palcem po nagłówku strony. Usłyszysz to, co słyszy agent: nazwy linków i przycisków. Ikona bez nazwy zostanie odczytana jako „link” albo nazwa pliku.

Po naprawie zmierz ponownie te same strony. Raport przy zaliczonej kontroli pokazuje komunikat „All audits passed”. Zachowaj oba raporty, przed i po, bo to najkrótszy dowód wykonanej pracy dla zarządu albo klienta.

WCAG, POUR i ustawa od 28 czerwca 2025

Reguły, które Lighthouse sprawdza dla agentów, nie wzięły się z niczego. To fragment WCAG (Web Content Accessibility Guidelines), międzynarodowego standardu dostępności od W3C. Aktualna wersja 2.2 ma 78 kryteriów sukcesu na trzech poziomach: 30 na poziomie A, 50 łącznie na AA i 78 łącznie na AAA. Wszystkie opierają się na czterech zasadach, które kurs Google skraca do POUR: treść ma być postrzegalna (każdy obraz ma alternatywę tekstową), obsługiwalna (wszystko da się zrobić klawiaturą), zrozumiała (etykiety i komunikaty błędów są jasne) i niezawodna (działa z technologiami wspomagającymi). Nazwa dostępna dla przycisku to kryterium z zasady pierwszej i czwartej naraz.

W Unii Europejskiej standardem technicznym jest EN 301 549, który odsyła do WCAG, a w Polsce od 28 czerwca 2025 obowiązuje ustawa o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Ustawa z 26 kwietnia 2024 wdraża Europejski Akt o Dostępności i obejmuje między innymi usługi handlu elektronicznego, rozumiane jako usługi świadczone przez strony internetowe i aplikacje w celu zawarcia umowy z konsumentem, także bezpłatne. Zwolnieni są mikroprzedsiębiorcy oraz firmy działające wyłącznie dla klientów biznesowych. Sama ustawa nie wpisuje WCAG jako wymogu; szczegółowych wytycznych każe szukać poza ustawą, a w praktyce audytów punktem odniesienia są właśnie WCAG. Organ nadzoru rynku może nałożyć karę do dziesięciokrotności przeciętnego wynagrodzenia miesięcznego. Szczegóły obowiązków i wyjątków zależą od rodzaju usługi, więc w konkretnej sprawie odsyłamy do prawnika; z naszej strony liczy się jedno: prace opisane wyżej są tożsame z pierwszymi punktami audytu WCAG.

Skala jest większa, niż sugeruje słowo „niepełnosprawność”. Światowa Organizacja Zdrowia szacuje, że 1,3 miliarda osób na świecie żyje z niepełnosprawnością, w tym 253 miliony z niepełnosprawnością wzroku. Kurs Google dodaje do tego osoby z ograniczeniami czasowymi (złamana ręka) i sytuacyjnymi (odblask na ekranie w słońcu). Badanie firmy Deque z 2019 roku, cytowane w kursie, wskazuje, że 67 procent błędów dostępności da się uniknąć, jeśli dostępność jest częścią projektowania, a nie poprawką po fakcie.

Jak emedia może w tym pomóc?

Prowadzimy strony na WordPressie, WooCommerce, Shoperze i IdoSell, więc naprawy z tego wpisu robimy na co dzień. Zaczynamy od pomiaru Lighthouse na kilku typach stron i od testu klawiaturą, potem spisujemy każdy element, który oblewa, z czasem naprawy. Ikony, przyciski i etykiety poprawiamy w bloku lub motywie potomnym, skrypty dodające role przepisujemy, a wynik dokumentujemy raportami przed i po. Ten zakres jest częścią usługi obsługi WordPressa i audytu SEO, w którym sprawdzamy też dostęp robotów AI do strony.

Podsumowanie

Agent AI i czytnik ekranu czytają stronę przez drzewo dostępności, w którym każdy element ma rolę i nazwę. Lighthouse sprawdza dla agentów 33 reguły, z czego 13 dotyczy nazwy dostępnej, i zeruje kontrolę przy jednym naruszeniu. W WordPressie najczęściej oblewają ikony w stopce z pustym alt, przycisk wyszukiwarki bez tekstu, ukryte pola formularzy bez etykiet i role dopisywane skryptami. Naprawa każdej z tych rzeczy to minuty lub pojedyncze godziny, a efekt sprawdzisz w tym samym raporcie, w którym znalazłeś błąd. Ta sama praca jest początkiem zgodności z wytycznymi WCAG, do których odsyła obowiązująca w Polsce od 28 czerwca 2025 ustawa o dostępności.

Przeczytaj także

• Jak pozycjonować firmę w AI, żeby ChatGPT i Gemini polecały ją klientom
• Jak przygotować stronę na agentów AI i dostać 3/3 w Lighthouse
• Jak zrobić plik llms.txt na stronie firmowej
• Jak poprawić Cumulative Layout Shift (CLS) w WordPressie, żeby strona przestała skakać
• Co to jest WebMCP i co przygotować na stronie, zanim agenci AI zaczną z niej korzystać
• GEO: jak być widocznym w chatbotach AI

Najczęstsze pytania

Jak to powstaje. Tematy, pomiary i ostatnie słowo: Grzegorz Wysocki. Redakcja i porządkowanie źródeł: Claude (Anthropic). Diagram: rysunek własny, zrzut makiety HTML. Model obrazu nie brał udziału.

Na czym to stoi. Chrome for Developers, „Accessibility for agents” i „Lighthouse accessibility scoring”, stan na 4 września 2026; kod źródłowy Lighthouse 13.4.1, plik agent-accessibility-tree.js z listą 33 reguł; kurs Learn Accessibility na web.dev, moduły ARIA and HTML, Images, Forms, Focus, Automated testing, Manual testing, Assistive Technology testing, How is digital accessibility measured, Why it matters; Światowa Organizacja Zdrowia (liczby cytowane w kursie); Deque, 2019 (cytowane w kursie); Infor.pl i Prawo.pl o ustawie o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług, w mocy od 28 czerwca 2025. Pomiary emedia.pl: 4 września 2026, Lighthouse 13.4.1, Chrome 151. Czego nie wiemy, o tym piszemy wprost: nie oceniamy, czy konkretna firma podlega ustawie.

Realizacja: artykuł zrealizowany przez człowieka we współpracy z systemami AI. Redakcję i publikację firmuje autor.

Opublikowano 05.09.2026

Więcej na ten temat: agenci AI Lighthouse dostępność Widoczność w AI