Zapytaj o wycenę

AKTUALNOŚCI

Agenty AI jako pośrednicy między użytkownikiem a niedostępną usługą: kto tu naprawdę odpowiada za dostępność?

Autor: Natalia Madej

Dwa poprzednie teksty z tej serii opisywały sytuacje, w których AI działa przy interfejsie: naprawia go w locie dla konkretnej osoby albo generuje go na nowo pod jej potrzeby.

Dwa poprzednie teksty z tej serii opisywały sytuacje, w których AI działa przy interfejsie: naprawia go w locie dla konkretnej osoby albo generuje go na nowo pod jej potrzeby. Trzeci wzorzec, który w 2026 roku przestał być teorią, jest inny jakościowo: AI nie poprawia interfejsu ani go nie tworzy — zastępuje użytkownika w kontakcie z nim. Osoba z niepełnosprawnością mówi agentowi, co chce osiągnąć („zarezerwuj wizytę”, „złóż zamówienie”, „wypełnij ten formularz urzędowy”), a agent sam klika, czyta ekran, wypełnia pola i loguje się — na stronie, która może pozostawać równie niedostępna jak wcześniej.

To rodzi pytanie, które prawnicy i audytorzy dopiero zaczynają sobie zadawać na poważnie: jeśli agent AI potrafi „obejść” niedostępną usługę i doprowadzić zadanie do końca, to czy usługa nadal łamie prawo?

Czym to się różni od AI naprawiającego interfejs i od Generative UI

Warto rozróżnić te trzy wzorce, bo w praktyce audytowej mieszają się i prowadzą do różnych wniosków:

AI naprawiające interfejs działa lokalnie, w przeglądarce tej samej osoby — dostosowuje kontrast, dogenerowuje brakujący alt tekst, poprawia strukturę nagłówków w locie. Użytkownik nadal sam prowadzi interakcję; AI tylko usuwa konkretne przeszkody.

Generative UI idzie dalej — zamiast łatać istniejący interfejs, tworzy dla użytkownika zupełnie nową reprezentację tej samej treści czy funkcji, dopasowaną do jego sposobu odbioru.

Agent jako pośrednik to jakościowo inny model: użytkownik przestaje bezpośrednio operować na interfejsie usługi w ogóle. Deleguje całe zadanie agentowi, który sam wchodzi w interakcję z formularzem, systemem logowania, mechanizmem płatności — a osoba z niepełnosprawnością widzi tylko wynik albo streszczenie tego, co się stało. To przesuwa punkt kontaktu z „człowiek + wspomagana percepcja interfejsu” na „człowiek + agent, który w ogóle nie musi tego interfejsu pokazywać”.

Co realnie istnieje już dziś

To nie jest scenariusz spekulatywny. W 2026 roku na rynku funkcjonuje już kilka kategorii takich narzędzi, każda z innymi ograniczeniami:

  • Agenty przeglądarkowe ogólnego przeznaczenia — Google Auto Browse (Gemini 3) i Microsoft Copilot Actions w Edge (tryby Light/Balanced/Strict) — działają w obrębie modelu bezpieczeństwa przeglądarki, wykorzystując zarówno kod strony, jak i zrzuty ekranu. Nie są projektowane specyficznie pod dostępność, ale bywają tak wykorzystywane.
  • Narzędzia dedykowane osobom niewidomym i słabowidzącym — przykładem opisywanym w branży jest „Guide”, aplikacja działająca na poziomie systemu operacyjnego (nie wewnątrz przeglądarki), która potrafi np. wykonać przeciąganie elementu w Salesforce Experience Cloud i na bieżąco narracyjnie opisuje wykonywane kroki.
  • Asystenci wizualni z człowiekiem lub AI w pętli — jak Be My Eyes zintegrowane z AI Microsoft — pomagające zinterpretować to, co dzieje się na ekranie, niekoniecznie działające autonomicznie.

Dlaczego to nie działa tak dobrze, jak brzmi w zapowiedziach

Środowisko osób niewidomych, które najwcześniej testowało te narzędzia, opisuje rozczarowanie równie często jak nadzieję. Kilka realnych barier technicznych, które sprawiają, że agent „obchodzi” niedostępność tylko częściowo:

  • Shadow DOM, iframe’y i dynamiczne renderowanie — stosowane np. w Salesforce Experience Cloud — fragmentują to, co agent w ogóle widzi jako stronę, bo ukrywają wewnętrzną strukturę komponentu przed zewnętrznymi skryptami.
  • Interakcje typu drag-and-drop wymagają od agenta utrzymywania dokładnego, aktualnego obrazu geometrii strony — a agenty oparte na analizie zrzutów ekranu (przechwycenie obrazu → decyzja → działanie, z typowym opóźnieniem 1–2 sekund) regularnie „spóźniają się” względem limitów czasowych takich interakcji.
  • Model bezpieczeństwa przeglądarki, zaprojektowany właśnie po to, by ograniczać dostęp między stronami, blokuje część automatyzacji z założenia — co jest dobre dla bezpieczeństwa, ale utrudnia legalne, chciane przez użytkownika działanie agenta.
  • CAPTCHA, logowanie wieloskładnikowe i treści renderowane wyłącznie przez JavaScript bez żadnych danych strukturalnych pozostają twardą barierą — nieklasyfikowaną formalnie jako „niespełnienie dostępności”, bo to bariery wymierzone w boty, nie w ludzi z niepełnosprawnościami.
  • Szersza powierzchnia ataku — szerokie uprawnienia agenta bywają nadużywane. W 2026 roku odnotowano podatność (CVE-2026-0628), w której złośliwe rozszerzenie przeglądarki mogło przejąć uprzywilejowany interfejs agenta Gemini.

Z badań i relacji środowiska wynika wniosek, który dobrze podsumowuje ten wątek: osoby niewidome często oceniają łatanie niedostępnego interfejsu warstwą AI jako mniej skuteczne niż rozwiązanie problemu semantycznego bezpośrednio w kodzie strony.

Status prawny: trzy poziomy, żaden jeszcze nie domknięty

1. WCAG 3.0 — dyskusja w toku, brak przyjętego stanowiska. W kwietniu 2026 r. Thea Eaton, była ekspertka zaproszona W3C z dwudziestoletnim doświadczeniem w dostępności edukacyjnej, zgłosiła w repozytorium WCAG 3.0 propozycję rozszerzenia definicji „user agent” o autonomiczne agenty AI działające w imieniu użytkownika — jako „primary and proxy users”. Zwróciła uwagę na realną lukę: strona może być w pełni zgodna z WCAG, a jednocześnie praktycznie niedostępna dla agenta (i odwrotnie), a obecne reguły nie odróżniają szkodliwej automatyzacji od autoryzowanej pomocy dla osoby z niepełnosprawnością. Zaproponowała zestaw wytycznych roboczo nazwanych AGAG (Agent Accessibility Guidelines), mapujących zasady POUR na potrzeby agentów. Zgłoszenie zostało oznaczone do dalszej odpowiedzi grupy roboczej — nie ma na razie decyzji o przyjęciu, odrzuceniu czy harmonogramie.

2. EAA / ADA / WCAG jako norma dla treści, nie dla obejścia. Tu nie ma jeszcze precedensu sądowego dotyczącego konkretnie agentów AI — zjawisko jest zbyt nowe. Jest jednak bardzo świeża i pouczająca analogia: rynek „nakładek dostępności” (accessibility overlays, jak np. AccessiBe). Ponad 800 firm korzystających z takich nakładek zostało pozwanych w latach 2023–2024 mimo wdrożonego narzędzia, a w 2025 r. amerykańska FTC nałożyła karę na AccessiBe za wprowadzające w błąd twierdzenia o automatycznym osiąganiu zgodności z ADA. Logika prawna stojąca za tymi sprawami jest prosta i przenosi się wprost na agentów: istnienie technologicznego obejścia, które w praktyce pozwala pewnej liczbie osób ukończyć zadanie, nie jest tym samym, co treść zgodna z WCAG/EN 301 549. Obowiązek dotyczy stanu samej usługi, nie tego, czy da się ją jakoś obsłużyć z pomocą zewnętrznego narzędzia. To zastrzeżenie warto traktować jako ostrzeżenie branżowe, nie jako potwierdzony wyrok w sprawie agentów AI — ale kierunek interpretacji jest czytelny.

3. Obowiązek transparentności z AI Act — osobna warstwa, też dotyczy agentów. Art. 50 unijnego AI Act, którego przepisy o transparentności zaczęły obowiązywać dostawców i podmioty wdrażające od 2 sierpnia 2026 r., nakłada obowiązek poinformowania człowieka, że wchodzi w interakcję z AI — najpóźniej w momencie pierwszej interakcji, w formie „jasnej i rozróżnialnej”, zgodnej z wymogami dostępności. Wytyczne do artykułu wprost potwierdzają, że obejmuje to agenty AI — również wtedy, gdy taki agent wchodzi w interakcję z człowiekiem (np. z konsultantem czatu na infolinii usługi) w imieniu swojego użytkownika. To rodzi realne tarcie: agent musi się ujawnić jako AI, a jednocześnie wiele usług ma w regulaminie zakaz automatyzacji/botów — więc „legalny” z perspektywy AI Act agent może formalnie naruszać ToS usługi, z której korzysta w imieniu osoby z niepełnosprawnością.

Dodatkowy kontekst z USA: amerykański Departament Sprawiedliwości w wydanym w 2026 r. Interim Final Rule wprost przyznał, że przeszacował gotowość narzędzi opartych na AI do automatycznego naprawiania dostępności i na tej podstawie przesunął termin zgodności z ADA Title II dla części podmiotów. To nie jest zakaz stosowania AI w tym obszarze, ale oficjalne, pisemne stanowisko regulatora, że automatyczna naprawa całych stron i generowanie alt-textu bez kontroli człowieka nie zastępują rzeczywistego audytu i rzeczywistej zgodności.

Ryzyko, o którym mniej się mówi: „dostępność” zoptymalizowana pod AI, nie pod ludzi

Równolegle do rozwoju agentów rośnie osobny, ale łatwy do pomylenia trend: strony zaczynają publikować dokumentację i strukturę danych myślaną wyłącznie pod modele językowe — pliki llms.txt, instrukcje dla LLM osadzone w HTML, integracje przez Model Context Protocol (MCP). To bywa nazywane „dostępnością” w komunikacji marketingowej firm, choć adresuje zupełnie inny problem niż potrzeby osób z niepełnosprawnościami: niezróżnicowany, płaski tekst dobry dla modelu językowego to nie to samo, co hierarchia nagłówków, landmarki, opisowe linki i tekst alternatywny potrzebne człowiekowi korzystającemu z czytnika ekranu. Krytycy tego zjawiska ostrzegają przed efektem, w którym infrastruktura budowana od dekad na żądanie środowiska osób z niepełnosprawnościami zostaje w praktyce przechwycona i przemianowana na potrzeby wygody systemów automatycznych — a opinia publiczna, widząc hasło „dostępność dla AI”, może błędnie uznać, że problem dostępności dla ludzi jest już rozwiązany, co osłabia presję na realne wdrożenia.

Co to oznacza w praktyce — dla różnych sytuacji

Co to oznacza w praktyce — dla różnych sytuacji
SytuacjaOcenaCo zrobić
Klient/użytkownik z niepełnosprawnością korzysta z agenta AI, by ukończyć zadanie na niedostępnej stronie usługodawcyUsługa nadal narusza wymogi dostępnościW audycie nie traktować możliwości obejścia jako dowodu zgodności; raportować braki tak, jakby agenta nie było
Firma komunikuje „nasza strona jest dostępna dzięki integracji z agentami AI”Wysokie ryzyko wprowadzającego w błąd twierdzenia (analogia do spraw ws. nakładek)Zweryfikować, czy istnieje realna zgodność z WCAG/EN 301 549, zanim taki komunikat zostanie zaakceptowany
Specyfikacja przetargu zakłada, że „zgodność zapewni integracja z agentem AI” zamiast konkretnych wymogów WCAG/EN 301 549Nie spełnia obowiązków wynikających z EAA/WADOdwołać się wprost do klauzul normy i poziomu WCAG, niezależnie od planowanych integracji AI
Dokumentacja llms.txt / structured data „pod AI” prezentowana jako poprawa dostępnościCzęściowo pomocne, ale nie substytut POURSprawdzić, czy równolegle wdrożono realne wymogi WCAG dla ludzi, a nie tylko strukturę dla botów
Osoba niewidoma korzysta z wyspecjalizowanego agenta (np. działającego na poziomie systemu) do obsługi formularza w systemie legacy bez planu remediacjiUzasadnione zastosowanie tymczasoweUdokumentować jako środek przejściowy, nie jako docelowe rozwiązanie zwalniające dostawcę z obowiązku
Rekomendacja klientowi konkretnego narzędzia agentowego o szerokich uprawnieniach w przeglądarceDodatkowe ryzyko bezpieczeństwa, nie tylko dostępnościOcenić model uprawnień i historię podatności narzędzia, zanim zostanie polecone jako obejście

Co zrobić już teraz

Nie wliczaj możliwości obejścia agentem AI do oceny zgodności. W raporcie z audytu dostępność strony ocenia się względem jej własnej struktury i kodu, a nie względem tego, czy istnieje zewnętrzne narzędzie, które da się do niej dopasować.

Pisz specyfikacje przetargowe wprost do norm, nie do technologii obejścia. Odwołania do WCAG 2.2 AA i konkretnych klauzul EN 301 549 pozostają jedyną podstawą dającą domniemanie zgodności — obietnica „będzie działać z agentami AI” nią nie jest.

Traktuj hasło „dostępność dla AI” jako osobną kategorię do zweryfikowania, nie jako dowód dostępności dla ludzi. llms.txt i podobne konwencje adresują inny problem niż POUR i nie powinny pojawiać się jako argument w rozmowie o zgodności z WCAG.

Śledź prace nad WCAG 3.0 i propozycją AGAG. To pierwsza próba formalnego uregulowania miejsca agentów w modelu „user agent” — warto obserwować, jak grupa robocza odpowie na zgłoszenie z kwietnia 2026 r.

Dla systemów legacy bez planu remediacji dopuszczaj agenta AI jako most tymczasowy — pod warunkiem jasnej dokumentacji. To uczciwe zastosowanie „AI jako siatki bezpieczeństwa”, pod warunkiem że nie zastępuje planu docelowej naprawy.

Zwracaj uwagę klientom na ryzyko bezpieczeństwa, nie tylko dostępności, przy szeroko uprawnionych agentach przeglądarkowych. Szerszy dostęp agenta do konta i danych użytkownika to nowa powierzchnia ataku, którą warto ocenić razem z zespołem bezpieczeństwa.

Pamiętaj o obowiązku transparentności z Art. 50 AI Act przy ocenie samego agenta. Jeśli klient wdraża własnego agenta wchodzącego w interakcję z ludźmi, od 2 sierpnia 2026 r. musi on jasno i w sposób dostępny ujawniać, że jest AI — to osobny obowiązek prawny, niezależny od kwestii dostępności obsługiwanej usługi.

Najważniejsza zasada

Agent AI może dać jednej osobie dostęp do jednej usługi w jednym konkretnym momencie — i to bywa realną, wartościową pomocą, zwłaszcza tam, gdzie na naprawę systemu trzeba będzie jeszcze poczekać. Nie zmienia to jednak stanu prawnego samej usługi. Dostępność pozostaje własnością treści i kodu, nie funkcją narzędzia, które ktoś przy nich postawi — a im więcej firm będzie próbowało pomylić jedno z drugim, tym ważniejsza staje się rola audytora, który tego rozróżnienia pilnuje.

Źródła

Przeczytaj również