Czy agent AI potrafi skorzystać z Twojej strony? Formularze, nawigacja i semantyczny HTML w erze agentic web

Strona internetowa może wyglądać nowocześnie, działać szybko i dobrze prezentować się na telefonie, a mimo to sprawiać problemy agentowi AI. Powód jest prosty: człowiek i agent nie zawsze „widzą” witrynę w ten sam sposób.

Użytkownik rozpoznaje przycisk po kolorze, położeniu i wyglądzie. Wie, że pole z napisem „Telefon” służy do wpisania numeru. Rozumie, że ikona koszyka prowadzi do zamówienia. Agent AI może natomiast korzystać z kodu HTML, drzewa dostępności, nazw kontrolek i struktury formularzy. Jeśli te elementy są niejednoznaczne, nawet proste zadanie może stać się problemem.

W praktyce oznacza to, że w erze agentic web strona musi być nie tylko czytelna i indeksowalna, ale również operacyjna: agent powinien potrafić znaleźć właściwą funkcję, zrozumieć jej przeznaczenie i poprawnie wykonać kolejne kroki.

Co właściwie oznacza, że agent AI „korzysta” ze strony?

Nie chodzi wyłącznie o odczytanie artykułu czy pobranie informacji o produkcie. Agent może dostać od użytkownika zadanie obejmujące kilka etapów.

Przykładowe polecenie:

„Znajdź trzy firmy wykonujące strony WordPress, sprawdź, czy oferują również pozycjonowanie i wyślij zapytanie do tej, która najlepiej pasuje do małej firmy usługowej.”

Agent musi wtedy:

• odnaleźć odpowiednią stronę,
• rozpoznać ofertę,
• przejść do właściwej podstrony,
• znaleźć formularz,
• zrozumieć znaczenie poszczególnych pól,
• wprowadzić dane,
• wybrać odpowiednią akcję,
• sprawdzić, czy formularz został rzeczywiście wysłany.

To znacznie trudniejsze zadanie niż samo przeczytanie dokumentu.

Agent może korzystać z kilku warstw strony jednocześnie

Współczesny agent internetowy nie musi opierać się wyłącznie na obrazie strony. Może analizować również strukturę HTML, DOM czy accessibility tree.

Właśnie dlatego semantyka kodu zaczyna mieć praktyczne znaczenie wykraczające poza klasyczną dostępność.

Przycisk powinien być przyciskiem

Jednym z częstych błędów frontendowych jest tworzenie elementów interaktywnych przy pomocy zwykłego <div> albo <span>, a następnie nadawanie im wyglądu przycisku za pomocą CSS i obsługi kliknięcia w JavaScript.

Dla człowieka wszystko może wyglądać poprawnie.

Przykład:

<div class="button">Wyślij formularz</div>

Semantycznie jest to jednak nadal zwykły kontener.

Lepsze rozwiązanie:

<button type="submit">Wyślij formularz</button>

Druga wersja od razu komunikuje przeglądarce, technologii asystującej i potencjalnemu agentowi, że mamy do czynienia z elementem wykonującym konkretną akcję.

Podobna zasada dotyczy linków. Jeżeli element prowadzi do innej strony, naturalnym rozwiązaniem jest <a href="...">, a nie dowolny kontener z obsługą zdarzenia kliknięcia.

Formularze są jednym z najtrudniejszych miejsc

Formularz może wyglądać dla człowieka całkowicie oczywiście, a jednocześnie być bardzo słabo opisany w kodzie.

W3C od lat zaleca łączenie pól formularza z etykietami za pomocą elementu <label>. Dzięki temu technologia może jednoznacznie ustalić, które pole odpowiada za nazwisko, telefon, adres e-mail czy wiadomość.

Przykład:

<label for="email">Adres e-mail</label>
<input type="email" id="email" name="email">

To znacznie lepsze rozwiązanie niż:

<input type="text" placeholder="Wpisz e-mail">

Placeholder może zniknąć po rozpoczęciu wpisywania i nie powinien zastępować prawidłowej etykiety.

Co powinien mieć formularz przyjazny agentowi?

Warto zwrócić uwagę na kilka podstawowych elementów:

• każde pole powinno mieć jednoznaczną etykietę,
• pola powinny używać odpowiednich typów, np. email, tel, date,
• pola wymagane powinny być jasno oznaczone,
• komunikaty błędów powinny wskazywać konkretny problem,
• przycisk powinien jasno mówić, co się wydarzy po jego użyciu,
• po wysłaniu formularza powinno pojawić się jednoznaczne potwierdzenie.

Zamiast przycisku:

„Dalej”

często lepiej użyć:

„Przejdź do płatności”

albo:

„Wyślij zapytanie”.

Opis funkcji jest wtedy czytelniejszy zarówno dla człowieka, jak i systemu.

Błędy formularzy muszą być możliwe do zinterpretowania

Załóżmy, że agent wprowadza nieprawidłowy numer telefonu i strona wyświetla jedynie czerwoną ramkę wokół pola.

Człowiek prawdopodobnie domyśli się, że wystąpił problem. Agent analizujący strukturę strony może jednak nie wiedzieć:

• które pole jest błędne,
• dlaczego dane są nieprawidłowe,
• jaki format jest wymagany,
• czy formularz został wysłany.

Znacznie lepszy jest komunikat:

„Numer telefonu powinien zawierać 9 cyfr.”

Dobra obsługa błędów jest więc nie tylko kwestią UX. Jest również sposobem na stworzenie interfejsu, którego działanie można jednoznacznie interpretować.

Nawigacja musi być przewidywalna

Agent próbujący odnaleźć ofertę potrzebuje podobnej logiki jak zwykły użytkownik. Problemy zaczynają się, gdy strona posiada kilka różnych systemów nawigacji, niejednoznaczne nazwy albo ważne elementy dostępne wyłącznie po wykonaniu nietypowej interakcji.

Dobrym przykładem jest menu, które otwiera się wyłącznie po najechaniu kursorem. Użytkownik mobilny nie ma hover, a agent automatyzujący stronę może również nie wykonać tej interakcji w oczekiwany sposób.

Warto więc dbać o:

• spójne nazwy pozycji menu,
• logiczne linkowanie pomiędzy podstronami,
• widoczną strukturę nagłówków,
• jasno opisane linki,
• możliwość obsługi strony klawiaturą,
• brak funkcji zależnych wyłącznie od hover.

Accessibility tree staje się szczególnie istotne

Accessibility tree przedstawia stronę w uproszczony sposób. Zamiast opisywać każdy kontener i każdą klasę CSS, koncentruje się na znaczeniu elementów.

Agent może dzięki temu otrzymać informacje w rodzaju:

• przycisk: „Dodaj do koszyka”,
• pole tekstowe: „Adres e-mail”,
• nagłówek: „Oferta”,
• link: „Kontakt”,
• checkbox: „Akceptuję regulamin”,
• status: zaznaczony / niezaznaczony.

To znacznie prostsze niż próba odtworzenia funkcjonalności strony wyłącznie na podstawie jej wyglądu.

W3C od lat definiuje sposób udostępniania ról, stanów i właściwości elementów interfejsu do technologii asystujących. Rozwój agentów AI sprawia, że te same mechanizmy zaczynają mieć znaczenie również poza klasycznym obszarem dostępności.

ARIA pomaga, ale nie zastępuje poprawnego HTML

WAI-ARIA pozwala przypisywać niestandardowym elementom role i stany, na przykład informować, że określony komponent jest menu, suwakiem czy przyciskiem.

Nie oznacza to jednak, że warto wszystko budować na <div> i później naprawiać przy pomocy ARIA.

Najpierw powinno się użyć właściwego elementu HTML, jeżeli taki istnieje.

Nowy kierunek: strona może jawnie udostępnić agentowi swoje funkcje

Ciekawym przykładem rozwoju agentic web jest WebMCP rozwijane w ekosystemie Chrome. Koncepcja polega na tym, że strona może nie tylko posiadać interfejs przeznaczony dla człowieka, ale również opisać agentowi konkretne działania, które można wykonać.

Formularz może więc zostać przedstawiony nie tylko jako grupa pól do kliknięcia, ale jako ustrukturyzowane narzędzie, na przykład:

„wyszukaj produkt”,

„sprawdź dostępność”,

„wyślij zapytanie”.

Chrome eksperymentuje między innymi z deklaratywnym API, które pozwala przekształcić standardowy formularz HTML w narzędzie dostępne dla agenta poprzez dodatkowe opisanie jego nazwy i przeznaczenia.

Przykład: sklep internetowy

Użytkownik wydaje agentowi polecenie:

„Znajdź czarny fotel biurowy do 1500 zł, dostępny od ręki, dodaj najlepszy do koszyka, ale niczego nie kupuj.”

Agent musi rozpoznać:

1. wyszukiwarkę produktów,
2. filtr koloru,
3. filtr ceny,
4. informację o dostępności,
5. listę produktów,
6. przycisk dodania do koszyka,
7. moment, w którym powinien zakończyć zadanie.

Jeżeli filtry są poprawnie opisane, przyciski mają jasne role, a stan produktu jest czytelny w kodzie, zadanie jest stosunkowo proste.

Jeżeli filtr działa tylko poprzez niestandardowy element JavaScript, dostępność wyświetlana jest wyłącznie kolorem, a przycisk nie ma nazwy, liczba potencjalnych błędów gwałtownie rośnie.

Jak przeprowadzić prosty audyt strony pod kątem agentów?

Nie trzeba czekać na nowe standardy. Już dzisiaj można wykonać kilka podstawowych testów.

Sprawdź:

• czy całą stronę można obsłużyć klawiaturą,
• czy wszystkie pola formularzy posiadają etykiety,
• czy przyciski mają jednoznaczne nazwy,
• czy nagłówki tworzą logiczną hierarchię,
• czy błędy formularza są opisane tekstowo,
• czy interaktywne elementy mają właściwe role,
• czy po wykonaniu akcji strona jasno komunikuje jej rezultat.

Jeżeli strona przechodzi takie testy, zwykle staje się jednocześnie bardziej dostępna, łatwiejsza do automatyzacji i przyjemniejsza dla zwykłych użytkowników.

Dostępność i agentic web zaczynają się spotykać

To jeden z ciekawszych efektów rozwoju agentów AI. Przez lata dostępność była traktowana przez część firm głównie jako wymóg dla określonych grup użytkowników lub kwestia zgodności ze standardami.

Dzisiaj okazuje się, że poprawnie opisany interfejs może być łatwiejszy w obsłudze także dla systemów AI.

Semantyczny HTML, właściwe etykiety, logiczne formularze i przewidywalna nawigacja nie są więc wyłącznie „optymalizacją pod roboty”. Są przykładem projektowania strony w sposób, który sprawia, że jej funkcje można jednoznacznie zrozumieć.

Najważniejszy wniosek

Agent AI nie potrzebuje specjalnej, całkowicie oddzielnej wersji strony. W wielu przypadkach wystarczy, że obecna witryna jest dobrze zbudowana.

Największe znaczenie mają:

• semantyczny HTML,
• jednoznaczne formularze,
• poprawne etykiety,
• przewidywalna nawigacja,
• jasne komunikaty błędów i sukcesu,
• poprawnie określone role elementów.

Do tej pory takie praktyki kojarzyły się głównie z dostępnością i dobrym frontendem. W erze agentic web zyskują kolejne zastosowanie.

Dlatego podczas projektowania strony warto zacząć zadawać jeszcze jedno pytanie:

„Czy ktoś, kto nie widzi interfejsu dokładnie tak jak człowiek, będzie w stanie jednoznacznie zrozumieć, co można tutaj zrobić?”

Jeżeli odpowiedź brzmi „tak”, witryna jest znacznie lepiej przygotowana nie tylko na dzisiejszych użytkowników, ale również na świat, w którym część wizyt i działań będzie wykonywana przez agentów AI.

Źródła

• W3C Web Accessibility Initiative – zasady budowania dostępnych formularzy, etykiet i komunikatów.
• W3C – Core Accessibility API Mappings i WAI-ARIA.
• Chrome for Developers – dokumentacja WebMCP i narzędzi dla agent-friendly websites.
• Chrome for Developers – deklaratywne API WebMCP dla standardowych formularzy HTML.
• Google web.dev – materiały dotyczące przygotowywania witryn do obsługi przez agentów AI.