Od lat zajmuję się dostępnością cyfrową: piszę o niej, mówię, popularyzuję ją i prowadzę szkolenia poświęcone temu tematowi. Bywam przy tym nazywany „ewangelistą dostępności” — określeniem, które sam czasem z uśmiechem podchwytuję. Bo rzeczywiście od lat staram się przekonywać, że dostępność nie jest technicznym dodatkiem dla wąskiej grupy użytkowników, ale sposobem myślenia o informacji i o tym, kto oraz w jaki sposób może z niej skorzystać.
Dlatego w artykułach, podczas szkoleń i zwykłych rozmów o dostępności regularnie wracam do jednego, z pozoru prostego pytania:
Dla kogo właściwie robimy dostępność?
Oczywiście przede wszystkim dla ludzi. Szczególnie dla osób najbardziej narażonych na wykluczenie: osób niewidomych i słabowidzących, niesłyszących, z niepełnosprawnością ruchową czy intelektualną. Ale także dla seniorów, osób znajdujących się chwilowo w trudnych warunkach, użytkowników mających problemy ze zrozumieniem języka czy obcokrajowców.
Od lat dodawałem do tej listy jeszcze jednego, dość nietypowego odbiorcę: wyszukiwarki internetowe. Nie dlatego, że wyszukiwarka jest człowiekiem i potrzebuje dostępności w takim samym znaczeniu jak osoba z niepełnosprawnością. Chodzi o coś innego. Dobrze zbudowana, uporządkowana i semantyczna strona daje się łatwiej odczytywać nie tylko ludziom korzystającym z różnych technologii, lecz także automatom.
Dzisiaj zaczynam dostrzegać kolejny etap tej historii. Do wyszukiwarek dołączają agenci sztucznej inteligencji. I tym razem zmiana może okazać się znacznie głębsza.
Internet od początku był pomysłem na dostęp do informacji
Cofnijmy się do początku. W marcu 1989 roku Tim Berners-Lee, pracujący w CERN, przygotował dokument zatytułowany „Information Management: A Proposal”. Nie zaczynał od projektowania efektownych stron internetowych. Próbował rozwiązać problem dostępu do ogromnej ilości rozproszonych informacji i powiązań między nimi.
Zaproponował wykorzystanie hipertekstu — dokumentów połączonych odsyłaczami. W 1990 roku rozwijany wspólnie z Robertem Cailliau pomysł otrzymał kształt World Wide Web. Powstały pierwszy serwer WWW i pierwsza przeglądarka, a następnie technologia zaczęła wychodzić poza CERN. W propozycji World Wide Web z 1990 roku Berners-Lee i Cailliau opisywali system pozwalający poprzez jeden interfejs docierać do różnych rodzajów informacji: dokumentacji, raportów, notatek czy baz danych.
To ważne. Pierwotną ideą WWW nie było przecież samo oglądanie stron. Chodziło przede wszystkim o docieranie do informacji poprzez sieć powiązań. Dopiero później Web stawał się coraz bardziej wizualny, interaktywny i skomplikowany. I właśnie wtedy coraz mocniej ujawniał się problem: nie każdy odbiera ten interfejs w taki sam sposób.
Co właściwie jest nagłówkiem?
Dla osoby widzącej odpowiedź może być banalna. Ten tekst jest nagłówkiem, bo jest duży, pogrubiony i stoi nad kilkoma akapitami. Tamto jest menu, bo znajduje się u góry strony. To wygląda jak przycisk, więc zapewne można go nacisnąć. Te pola należą do jednego formularza, bo wizualnie leżą obok siebie.
Człowiek potrafi ogromną część tych informacji wywnioskować z wyglądu, położenia, koloru czy wielkości elementów. Osoba niewidoma korzystająca z czytnika ekranu nie może polegać na takim mechanizmie.
Jeżeli coś jest nagłówkiem, dobrze byłoby więc zapisać w kodzie: to jest nagłówek. Jeżeli coś jest przyciskiem: to jest przycisk. Jeżeli tekst opisuje pole formularza, związek pomiędzy tekstem a polem powinien istnieć również programistycznie.
Z tego między innymi wyrasta znaczenie semantycznego HTML. Przeglądarka może następnie na podstawie kodu stworzyć również drzewo dostępności, czyli accessibility tree — reprezentację interfejsu zawierającą między innymi role, nazwy i stany elementów. Z takiej warstwy korzystają technologie asystujące, np. czytniki ekranu.
Osoba niewidoma nie musi więc wiedzieć, że jakiś tekst ma 28 pikseli, jest pogrubiony i ma większy odstęp od kolejnego akapitu. Może otrzymać znacznie ważniejszą informację: to jest nagłówek drugiego poziomu.
I właśnie tutaj pojawia się zasada, do której będziemy jeszcze wracać: jeżeli autor zna znaczenie informacji, nie powinien zmuszać odbiorcy do odgadywania tego znaczenia wyłącznie z jej wyglądu.
Alt też ma ciekawą historię
Dobrym przykładem jest tekst alternatywny obrazów. Dzisiaj atrybut alt bardzo mocno kojarzymy z dostępnością dla osób niewidomych. I słusznie — odpowiednik tekstowy informacji wizualnej jest jednym z podstawowych elementów dostępności treści nietekstowych. Ale sam mechanizm alternatywnego tekstu nie został początkowo wymyślony wyłącznie dla osób niewidomych.
Już specyfikacja HTML 2.0 z 1995 roku określała ALT jako tekst używany w miejsce obrazu, np. z powodu ograniczeń przetwarzania albo preferencji użytkownika. W czasach wolnych połączeń modemowych użytkownik mógł przecież również wyłączyć pobieranie grafik. HTML potrafił więc powiedzieć: jeżeli nie możesz lub nie chcesz odebrać tej informacji w postaci obrazu, oto jej reprezentacja tekstowa.
Rozwijający się ruch dostępności bardzo wyraźnie pokazał później, jak ogromne znaczenie ta zdolność HTML ma dla ludzi, którzy obrazu po prostu nie mogą zobaczyć. I jest to pierwszy ciekawy przykład szerszej prawidłowości: mechanizm pozwalający oddzielić informację od jednego konkretnego sposobu jej prezentacji zaczyna służyć również zastosowaniom, z myślą o których pierwotnie jej nie projektowano.
Dostępność zaczyna być porządkowana
W3C uruchomiło Web Accessibility Initiative w 1997 roku. 3 lutego 1998 roku ukazał się pierwszy publiczny szkic wytycznych WAI dotyczących tworzenia dostępnych stron, a 5 maja 1999 roku WCAG 1.0 stało się rekomendacją W3C. Później, 11 grudnia 2008 roku, opublikowano WCAG 2.0.
Już prace prowadzące do pierwszego WCAG mocno dotykały problemu oddzielenia treści i struktury od prezentacji. I z dzisiejszej perspektywy jest to niezwykle ważne. Bo jeśli znaczenie informacji nie jest przywiązane wyłącznie do tego, jak wygląda ona na konkretnym ekranie, można ją przedstawić inaczej. Wizualnie. Głosowo. W brajlu. Na mniejszym ekranie. W innej aplikacji. Za pomocą technologii, której w momencie tworzenia strony jeszcze nie było.
A potem pojawiły się wyszukiwarki
Na szkoleniach od dawna zwracam uwagę, że z dobrze uporządkowanej strony korzysta jeszcze jeden uczestnik tego systemu — automat indeksujący jej zawartość. Zanim przecież jakakolwiek informacja pojawi się w wynikach wyszukiwania, musi najpierw trafić do systemu wyszukiwarki. Roboty Google przemierzają sieć, odkrywają adresy stron, pobierają ich zawartość, renderują ją i analizują. Dopiero część tak przetworzonych informacji może trafić do indeksu Google, z którego później wyszukiwarka dobiera wyniki odpowiadające na nasze zapytania. Google opisuje ten proces w dokumentacji dotyczącej działania wyszukiwarki.
Na szkoleniach od lat używałem przy tym półżartobliwego określenia:
Googlebot jest największym niewidomym użytkownikiem Internetu.
Co ciekawe, podobnego porównania użył już w 2008 roku T.V. Raman — niewidomy informatyk i badacz Google. Określił crawler Google mianem „najbardziej wpływowego niewidomego użytkownika świata” i wskazywał przy tym na wspólne korzyści dobrze przygotowanej treści tekstowej dla osób niewidomych i robotów wyszukiwarki. Nie chodzi oczywiście o dosłowne porównanie robota do osoby niewidomej.
W obu przypadkach chodzi o zwrócenie uwagi na prostą rzecz: Googlebot nie korzysta ze strony w taki sposób jak człowiek patrzący na ekran. Nie wystarczy więc, że coś tylko wygląda jak nagłówek, menu czy ważna informacja i że człowiek sam domyśli się tego z koloru, rozmiaru czy położenia. Maszyna potrzebuje informacji, którą może programowo odczytać, przetworzyć i powiązać z innymi elementami.
Współczesny Googlebot jest oczywiście znacznie bardziej zaawansowany niż roboty sprzed kilkunastu czy kilkudziesięciu lat. Google używa do renderowania stron środowiska opartego na Chromium, wykonuje JavaScript i analizuje nie tylko surowy tekst, lecz także wiele elementów wyrenderowanej strony. Google opisuje ten proces szczegółowo w dokumentacji dotyczącej JavaScript SEO. Ale sedno metafory nadal pozostaje aktualne: automat nie powinien być zmuszany do odgadywania znaczenia wyłącznie z wizualnej prezentacji strony.
Nie należy oczywiście utożsamiać dostępności z SEO. To różne obszary i różne cele. Ale oba spotykają się w pewnym ważnym miejscu. Maszyna również korzysta na tym, że struktura dokumentu jest jawna, linki są sensownie opisane, treści nie istnieją wyłącznie w grafikach, a znaczenie elementów nie wynika tylko z ich wizualnego wyglądu. Jeżeli autor strony wie, że coś jest tytułem artykułu, sekcją, odnośnikiem albo opisem obrazu, dobrze jest przekazać tę wiedzę nie tylko człowiekowi patrzącemu na ekran.
Przez wiele lat wyszukiwarka pozostawała jednak przede wszystkim pośrednikiem prowadzącym człowieka do strony. Pytałem Google o coś, otrzymywałem listę wyników, wybierałem stronę i dopiero wtedy zaczynałem z niej korzystać. W dużym uproszczeniu wyglądało to tak: człowiek → wyszukiwarka → strona WWW.
Dla mnie jako osoby korzystającej z technologii asystujących w tym łańcuchu były oczywiście jeszcze przeglądarka i czytnik ekranu. To właśnie za ich pomocą odczytywałem i obsługiwałem konkretną witrynę. I teraz ten model zaczyna się zmieniać.
Moim interfejsem do internetu coraz częściej jest rozmowa z asystentem AI
Dostrzegam to bardzo wyraźnie również we własnym korzystaniu z sieci. Jestem osobą z niepełnosprawnością wzroku. Od lat korzystam z technologii asystujących i zawodowo zajmuję się dostępnością cyfrową.
Jeszcze stosunkowo niedawno większość internetowych poszukiwań oznaczała dla mnie przechodzenie przez kolejne witryny. Otwierałem wyszukiwarkę. Wybierałem wynik. Trafiałem na stronę. Poruszałem się po nagłówkach, linkach, formularzach i innych elementach przy pomocy czytnika ekranu. Oczywiście nadal to robię.
Ale coraz częściej moje podstawowe okno na internet wygląda inaczej. Jest nim rozmowa z asystentem sztucznej inteligencji — prowadzona w aplikacji albo na stronie takiego serwisu jak ChatGPT, Gemini czy Grok.
Przeglądarka czy czytnik ekranu oczywiście nie znikają. Jeżeli korzystam z takiego serwisu w przeglądarce, nadal obsługuję tę przeglądarkę. Jeżeli korzystam z aplikacji mobilnej, nadal posługuję się interfejsem aplikacji i technologią asystującą. Zmienia się jednak miejsce, w którym wykonuję większość właściwej interakcji z informacją.
Zamiast samodzielnie przechodzić przez kilka czy kilkanaście stron, mogę powiedzieć asystentowi AI, czego potrzebuję. Mogę poprosić o znalezienie informacji, porównanie wielu źródeł, sprawdzenie dokumentacji czy zestawienie ofert.
Jeżeli taki asystent sam korzysta z wyszukiwarki, stron internetowych, baz danych albo innych narzędzi, aby wykonać moje polecenie, możemy mówić o działaniu agenta AI. Nie muszę więc osobiście odwiedzać każdej wykorzystanej witryny. Agent może wyszukać źródła, dotrzeć do ich zawartości, odczytać ją, porównać i na tej podstawie przygotować odpowiedź.
W dużym uproszczeniu pojawia się więc nowy łańcuch: człowiek → interfejs rozmowy z asystentem AI → agent AI → strony WWW i inne źródła → odpowiedź dla człowieka.
Oczywiście pod spodem nadal działają przeglądarki, protokoły sieciowe, serwery, wyszukiwarki i inne elementy infrastruktury. Nie znikają. Z punktu widzenia użytkownika zmienia się jednak to, z czym bezpośrednio prowadzi rozmowę i gdzie wykonuje większość swojej pracy informacyjnej. I jest w tym jeszcze jedna bardzo ważna zmiana.
Mogę powiedzieć nie tylko czego szukam, ale również jak chcę to dostać
W tradycyjnej witrynie autor w dużej mierze decyduje o tym, w jakiej postaci przedstawia informację. Technologie asystujące pozwalają następnie tę informację odbierać inaczej — np. czytnik ekranu przedstawia strukturę strony za pomocą mowy lub brajla. W rozmowie z asystentem AI użytkownik może jednak pójść o krok dalej.
Mogę powiedzieć nie tylko: „znajdź mi tę informację” ale również: „przedstaw ją w taki sposób, żebym mógł z niej wygodnie skorzystać”.
Mogę poprosić o krótkie podsumowanie. O tekst podzielony logicznymi nagłówkami. O tabelę porównawczą. Albo przeciwnie — o odpowiedź bez tabeli. Mogę poprosić o wskazanie źródeł przy konkretnych twierdzeniach, prostszy język, krótszą wersję albo format nadający się do skopiowania do wiadomości.
Zmiana nie polega więc wyłącznie na tym, że sztuczna inteligencja pomaga mi znaleźć informację. Coraz częściej mogę również określić końcową reprezentację, w której chcę ją otrzymać. To bardzo ciekawie odwraca perspektywę. Po jednej stronie agent może pobierać informację z sieci w postaci dogodnej dla maszyny. Po drugiej może przedstawić ją konkretnemu człowiekowi w postaci, którą ten człowiek sam określił. I właśnie w tym miejscu idea jednej informacji i wielu sposobów jej reprezentowania zaczyna nabierać zupełnie nowego znaczenia.
Agent AI staje się nowym pośrednikiem
Nie powiedziałbym więc po prostu, że „sztuczna inteligencja jest nową grupą osób, dla których robimy dostępność”. To byłoby zbyt dużym uproszczeniem. Ostatecznym odbiorcą nadal jest człowiek. Ale agent staje się bezpośrednim odbiorcą informacji i jednocześnie pośrednikiem pomiędzy tą informacją a człowiekiem.
Ten kierunek widać również na poziomie samego W3C: we wrześniu 2026 roku wspólnie z GS1 organizuje ono warsztat „E-commerce for Humans and AI Agents”, którego punktem wyjścia jest właśnie rosnąca rola agentów AI jako pośredników między treścią WWW a użytkownikiem końcowym.
W 2026 roku na web.dev opublikowano poradnik „Build agent-friendly websites”. Opisuje on trzy podstawowe sposoby, w jakie agent może poznawać stronę: poprzez jej obraz, HTML oraz drzewo dostępności. To ostatnie jest szczególnie interesujące. Warstwa powstała między innymi po to, aby technologie asystujące mogły zrozumieć interfejs, okazuje się przydatna także dla agenta AI.
Zamiast próbować wywnioskować wszystko z pikseli, agent może dowiedzieć się: to jest przycisk, to jest pole tekstowe, to jest nagłówek, to jest menu, to jest aktualny stan elementu.
Accessibility tree może więc działać dla agenta jak semantyczna mapa funkcjonalności strony, pozbawiona znacznej części wizualnego „szumu”. Przygotowywanie serwisów bardziej zrozumiałych dla agentów prowadzi w dużej mierze z powrotem do dobrze zbudowanego, semantycznego i dostępnego Webu.
W pewnym sensie moje dawne określenie „największego niewidomego użytkownika Internetu” zyskuje więc dziś drugie życie. Pojawia się kolejna klasa oprogramowania, dla której wizualny wygląd strony może być tylko jednym z kilku sposobów poznawania jej zawartości — i niekoniecznie tym najbardziej efektywnym. Historia zatacza więc pierwsze koło. Ale na tym się nie kończy.
Czy agent w ogóle potrzebuje całej strony?
Nawet bardzo dobrze zbudowana strona internetowa nadal jest przecież interfejsem. Ma menu. Stopkę. Nawigację. Style. Skrypty. Bannery. Elementy układu. Przyciski i mechanizmy potrzebne człowiekowi korzystającemu z przeglądarki.
Jeżeli agent chce jedynie odpowiedzieć na proste pytanie, na przykład: „Jaki jest termin składania zgłoszeń?” albo: „Ile kosztuje dana usługa i co obejmuje jej cena?” to czy naprawdę musi za każdym razem analizować całą warstwę interfejsu strony?
Coraz więcej inicjatyw odpowiada: niekoniecznie. I właśnie w tym miejscu rozpoczyna się kolejny etap rozwoju.
Nie jeden nowy standard, ale cały kierunek
Nie chodzi przy tym o jeden nowy format, który miałby zastąpić dotychczasowy sposób publikowania stron. Równolegle rozwija się kilka różnych pomysłów odpowiadających na podobne pytanie: jak przekazać agentowi treść, strukturę albo funkcje serwisu w postaci, którą może łatwiej i efektywniej wykorzystać? Poszczególne rozwiązania podchodzą do tego problemu na różne sposoby.
llms.txt — prosty przewodnik dla agentów
Jednym z pomysłów jest llms.txt, którego pierwotna propozycja pojawiła się w 2024 roku. To niewielki dokument tekstowy zapisany w Markdownie, który może powiedzieć agentowi, czym jest dany serwis i gdzie znajdują się jego najważniejsze informacje. Nie jest to dzisiaj standard o pozycji porównywalnej z HTML czy robots.txt. Nie wszystkie systemy AI go wykorzystują i nie ma gwarancji, że samo utworzenie takiego pliku zmieni sposób, w jaki agent postrzega witrynę.
Znacznie ważniejsza jest sama idea: czy zamiast zmuszać agenta do każdorazowego rekonstruowania znaczenia z całej witryny nie możemy przedstawić mu informacji w prostszej postaci? I llms.txt jest tylko jedną z odpowiedzi.
Cloudflare: ta sama strona, inna reprezentacja
Bardzo interesujące rozwiązanie Cloudflare ogłosił w lutym 2026 roku. Firma udostępniła mechanizm Markdown for Agents.
Jeżeli właściciel witryny go włączy, człowiek odwiedzający stronę może nadal otrzymać normalny HTML. Agent może jednak pod tym samym adresem poprosić: Accept: text/markdown, czyli w praktyce: „Chcę tę samą informację, ale przedstawioną jako Markdown”. Cloudflare może wtedy pobrać aktualny HTML z serwera źródłowego i w locie przekształcić go w prostszą reprezentację Markdown.
Nie trzeba ręcznie utrzymywać drugiego artykułu „dla sztucznej inteligencji”. Mamy: jedną informację → kilka sposobów jej przedstawienia.
To bardzo ważne. Historia dostępności zna przecież problem „specjalnych wersji”. Normalna strona. Osobna „wersja dla niewidomych”. Po pewnym czasie jedna zostaje zaktualizowana, druga nie. Jedna ma wszystkie funkcje, druga tylko część.
Jeżeli teraz zbudujemy: wersję dla ludzi, wersję dla osób z niepełnosprawnościami, wersję dla wyszukiwarki, wersję dla AI, to nie rozwiązujemy problemu. Produkujemy kilka równoległych wersji prawdy. Znacznie ciekawszy jest model: jedno źródło informacji — wiele generowanych reprezentacji.
Dlaczego właśnie Markdown?
Nieprzypadkowo w wielu nowych rozwiązaniach pojawia się właśnie Markdown. Markdown został stworzony przez Johna Grubera na długo przed dzisiejszą generatywną sztuczną inteligencją. Jego podstawowym założeniem było stworzenie tekstowego zapisu, który pozostaje łatwy do czytania i pisania nawet w surowej postaci, a następnie może zostać przekształcony w HTML.
Jego zaleta polega na tym, że znajduje się gdzieś pomiędzy zwykłym tekstem a rozbudowanym HTML. Można w nim bardzo prosto powiedzieć: to jest nagłówek, to jest lista, to jest link, to jest cytat.
Brzmi znajomo? W dostępności od lat przekonujemy przecież, że znaczenie elementu nie powinno wynikać wyłącznie z jego wyglądu. Nagłówek powinien być nagłówkiem nie dlatego, że jest większy i pogrubiony, lecz dlatego, że jego rola została określona w strukturze dokumentu. Lista nie powinna być listą tylko dlatego, że ktoś ręcznie wpisał kilka myślników i odpowiednio poprzesuwał tekst. Link powinien mieć znaczący tekst, a nie jedynie niebieski kolor i podkreślenie.
Markdown działa oczywiście na innym poziomie i nie zastępuje semantycznego HTML. Ale opiera się na bardzo podobnej intuicji: najpierw struktura i znaczenie, dopiero potem sposób prezentacji.
Dla modelu językowego ma to dodatkową zaletę. Pełny HTML strony może zawierać bardzo dużo kodu i elementów interfejsu, które zajmują miejsce w kontekście modelu. Markdown pozostawia przede wszystkim właściwą treść i jej podstawową strukturę. Cloudflare potrafi nawet zwrócić informacje pozwalające porównać szacunkową liczbę tokenów wersji Markdown i pierwotnego HTML. Im mniej kontekstu zużywamy na techniczną otoczkę strony, tym więcej pozostaje na właściwą informację.
A może nawet Markdown będzie kiedyś zbyt ciężki?
llms.txt i Markdown nie są końcem tej historii. W 2026 roku przy W3C uruchomiono Web Content Browser for AI Agents Community Group. To ważne rozróżnienie: jest to W3C Community Group, czyli inicjatywa społecznościowa hostowana przez W3C, a nie formalny standard W3C. Grupa zwraca uwagę na problem przesyłania do modeli całego HTML lub dużych struktur DOM i pracuje nad bardziej zwartą, maszynową reprezentacją treści i interakcji.
A więc nawet Markdown nie musi okazać się ostateczną odpowiedzią. Być może za kilka lat używać będziemy zupełnie innego rozwiązania. I właśnie dlatego nie warto budować całej tej dyskusji wokół jednego pliku czy jednego formatu. Istotny jest kierunek: maszyna coraz częściej nie musi dostawać tego samego interfejsu, który został przygotowany do oglądania przez człowieka. Może dostać reprezentację informacji dopasowaną do swoich możliwości.
A może agent wcale nie powinien „klikać”?
Jeszcze dalej idą rozwiązania, które nie próbują nawet przedstawiać agentowi uproszczonej strony. Jeżeli człowiek chce dokonać rezerwacji, agent może oczywiście próbować zachowywać się dokładnie jak człowiek: znaleźć formularz, zrozumieć pola, wpisać dane, odnaleźć przycisk, nacisnąć go.
Ale można również powiedzieć agentowi wprost: „Oto funkcja służąca do dokonania rezerwacji. Oto dane, których potrzebuje”. W tym kierunku rozwijany jest między innymi Model Context Protocol — MCP. MCP pozwala aplikacjom wykorzystującym modele językowe łączyć się z zewnętrznymi danymi i narzędziami. System może więc udostępnić agentowi uporządkowane zasoby i funkcje zamiast zmuszać go do odkrywania wszystkiego poprzez interfejs przeznaczony dla człowieka.
Podobną ideę w kontekście samego WWW rozwija WebMCP. WebMCP jest rozwijanym, eksperymentalnym rozwiązaniem, które pozwala witrynie jawnie udostępniać agentowi ustrukturyzowane narzędzia i operacje. Zamiast patrzeć na przycisk i zgadywać: „chyba ten element służy do wykonania rezerwacji” agent może otrzymać jawnie opisaną funkcję: „zarezerwuj termin”. I znowu dochodzimy do tej samej zasady: jeżeli autor zna znaczenie, nie zmuszaj odbiorcy do odgadywania go z prezentacji.
Jedna informacja, wiele sposobów jej odbierania
Być może właśnie tutaj znajduje się najważniejszy punkt całej tej historii. Dostępność nauczyła nas, że informacja nie powinna być zakładnikiem jednej formy prezentacji. Nagłówek nie powinien istnieć wyłącznie jako „duży pogrubiony tekst”. Przycisk nie powinien istnieć wyłącznie jako „kolorowy prostokąt”. Znaczenie obrazu nie powinno istnieć wyłącznie w pikselach. Treść filmu nie powinna być dostępna wyłącznie poprzez słuch. Struktura tabeli nie powinna wynikać wyłącznie z wizualnego rozmieszczenia komórek.
Dzięki temu ta sama informacja może być prezentowana na różne sposoby. Graficznie. Głosowo. W brajlu. Na dużym ekranie. Na małym ekranie. Przez wyszukiwarkę. Przez API. Przez reprezentację przygotowaną dla agenta. A na końcu — w formie, którą sam użytkownik uzna za najwygodniejszą.
To ostatnie jest nowym i bardzo interesującym elementem. Agent może po jednej stronie otrzymywać informacje w formie dogodnej dla maszyny, a po drugiej przekształcać je w formę dogodną dla konkretnego człowieka.
Czy zatem robimy dostępność dla sztucznej inteligencji?
Powiedziałbym to inaczej. Nadal robimy dostępność dla ludzi. To człowiek ma prawo do informacji, usługi i możliwości wykonania działania.
Zmienia się natomiast zestaw technologii pośredniczących pomiędzy człowiekiem a informacją. Dla osoby niewidomej takim pośrednikiem od dawna jest między innymi czytnik ekranu. Dla wszystkich użytkowników ogromnym pośrednikiem stała się wyszukiwarka. A dzisiaj coraz częściej może nim być również agent AI.
Nie oznacza to, że wcześniejsze warstwy znikają. Czytnik ekranu nadal może odczytywać interfejs aplikacji lub witryny, w której rozmawiam z asystentem AI. Przeglądarka nadal może wyświetlać tę aplikację. Internet nadal dostarcza źródła.
Zmienia się jednak układ ról. Coraz częściej nie muszę samodzielnie wędrować po każdej stronie źródłowej. Mogę powiedzieć asystentowi, czego potrzebuję, a agent może wykonać znaczną część tej pracy za mnie.
Jeżeli człowiek mówi: „Znajdź mi tę informację, sprawdź ją i przedstaw w sposób, którego potrzebuję” to zdolność agenta do odczytania źródeł zaczyna bezpośrednio wpływać na zdolność człowieka do dotarcia do informacji. Nie oznacza to, że agent ma prawa dostępnościowe. Oznacza, że stał się częścią łańcucha dostępu człowieka do informacji.
Dostępność jako przygotowanie na odbiorcę, którego jeszcze nie znamy
I być może właśnie to jest dla mnie najciekawszym wnioskiem. Kiedy kilkanaście lat temu mówiłem na szkoleniach, że dobrze uporządkowana i dostępna strona jest korzystna również dla wyszukiwarek, dzisiejszych agentów AI jeszcze nie było.
A jednak wiele zasad, które wtedy stosowaliśmy, okazuje się dla nich przydatnych. Semantyka. Logiczna struktura. Opisowe linki. Tekstowe odpowiedniki. Oddzielenie treści od wyglądu. Programistycznie określone role i relacje.
Nie dlatego, że ktoś projektował WCAG z myślą o ChatGPT czy innych współczesnych asystentach i agentach AI. Właśnie odwrotnie. To pokazuje wartość projektowania informacji w sposób, który nie zakłada tylko jednego, znanego dziś odbiorcy.
Dzisiaj sam coraz częściej korzystam z internetu właśnie w taki sposób. Moim bezpośrednim interfejsem coraz częściej jest rozmowa z asystentem AI. Mówię, czego potrzebuję. Mogę również powiedzieć, jak chcę otrzymać wynik.
Agent może w moim imieniu wyszukiwać informacje, docierać do stron i innych źródeł, czytać je, porównywać i interpretować. A następnie asystent może przedstawić mi rezultat w postaci krótkiego podsumowania, uporządkowanego tekstu, tabeli, listy, odpowiedzi ze źródłami albo innej formy, o którą poproszę.
Dlatego kiedy patrzę dziś na llms.txt, Markdown dla agentów, nowe reprezentacje stron, MCP czy WebMCP, nie widzę wyłącznie kolejnych technologicznych ciekawostek ze świata sztucznej inteligencji. Widzę kolejny rozdział znacznie starszej historii. Historii o tym, że informacja jest najbardziej dostępna wtedy, kiedy nie uzależniamy jej od jednego odbiorcy, jednego urządzenia ani jednego sposobu prezentacji.
WWW zaczęło się jako sposób łączenia informacji. Dostępność nauczyła nas oddzielać znaczenie od wyglądu. Wyszukiwarki pokazały, że stronę czytają również maszyny. A agenci AI zaczynają pokazywać coś jeszcze: człowiek nie zawsze musi już osobiście odwiedzać stronę. Może chcieć po prostu dotrzeć do informacji albo wykonać działanie — a nawet zdecydować, w jaki sposób rezultat zostanie mu przedstawiony.
I być może właśnie dlatego jedno z pytań, które od lat powraca w moim pisaniu, szkoleniach i rozmowach o dostępności — „dla kogo właściwie to projektujemy?” — staje się dziś ciekawsze niż kiedykolwiek wcześniej.
