Czy czytnik ekranu wie, że rozmawiasz z AI? Jak naprawdę oznaczać systemy sztucznej inteligencji

O tym, kiedy AI Act wymaga poinformowania użytkownika, że ma do czynienia z systemem sztucznej inteligencji, pisaliśmy już wcześniej w materiale „AI Act od 2 sierpnia 2026 r. Obowiązki urzędów i dostępność AI”. Tam najważniejszy był zakres obowiązków: kiedy informacja o AI jest potrzebna, kto za nią odpowiada i dlaczego nie każda treść przygotowana z pomocą modelu generatywnego podlega takim samym zasadom. Warto jednak pójść krok dalej, bo prawidłowe ustalenie obowiązku nie daje jeszcze odpowiedzi na bardzo praktyczne pytanie: jak tę informację pokazać użytkownikowi, żeby rzeczywiście ją otrzymał?

To pytanie jest szczególnie istotne w przypadku chatbotów i innych interaktywnych systemów osadzanych na stronach internetowych. Można przecież przygotować estetyczne okno rozmowy, dodać obok nazwy niewielką plakietkę „AI”, zastosować charakterystyczny kolor i uznać sprawę za załatwioną. Dla części użytkowników informacja będzie oczywista. Osoba korzystająca z czytnika ekranu może jednak usłyszeć tylko nazwę usługi i od razu przejść do pola wpisywania wiadomości. Jeżeli plakietka jest zwykłą grafiką bez odpowiednika tekstowego albo została ukryta przed warstwą dostępności, z jej perspektywy informacja o AI po prostu nie istnieje.

W tym miejscu problem przestaje być abstrakcyjną kwestią zgodności z przepisami. Chodzi o to, czy użytkownik rozumie charakter rozmowy, zanim zacznie polegać na odpowiedziach systemu.

Najpierw trzeba sprawdzić, co naprawdę dostaje użytkownik

Podstawowy błąd polega na ocenianiu interfejsu wyłącznie wzrokiem. Projektant widzi ikonę, nazwę chatbota, plakietkę „AI” i krótką informację pod nagłówkiem, więc zakłada, że kontekst jest jasny. Czytnik ekranu nie analizuje jednak strony tak, jak człowiek patrzący na ekran. Korzysta z informacji dostępnych programowo: struktury dokumentu, semantyki HTML, nazw elementów, ról, stanów i właściwości przekazywanych przez przeglądarkę oraz interfejs dostępności systemu operacyjnego.

WAI-ARIA powstało właśnie po to, aby bardziej złożone aplikacje internetowe mogły przekazywać technologiom asystującym znaczenie elementów, których nie da się poprawnie opisać samym wyglądem. W3C wskazuje, że ARIA pozwala przekazywać między innymi role elementów, ich stany, relacje oraz informacje o obszarach dynamicznie zmieniających swoją zawartość. Nie zmienia to podstawowej zasady: jeśli da się użyć poprawnego natywnego HTML, jest on zwykle lepszą podstawą niż budowanie interfejsu z przypadkowych divów i późniejsze próby naprawiania go atrybutami ARIA. Źródło: W3C WAI – WAI-ARIA Overview.

W przypadku informacji „rozmawiasz z systemem AI” najbezpieczniejszym rozwiązaniem często będzie więc zwyczajny, widoczny tekst umieszczony w logicznym miejscu interfejsu. Nie trzeba od razu szukać skomplikowanych mechanizmów. Jeśli informacja jest tekstem, znajduje się przed rozpoczęciem rozmowy, ma odpowiedni kontrast i pojawia się w sensownym miejscu kolejności odczytu, użytkownik czytnika ekranu oraz osoba widząca otrzymują tę samą podstawową wiadomość.

Sama etykieta „AI” może znaczyć za mało

Warto przy tym zastanowić się, czy samo oznaczenie literami „AI” rzeczywiście przekazuje to, czego potrzebuje użytkownik. Z punktu widzenia projektanta taka plakietka może wydawać się oczywista, ale odbiorca nie musi wiedzieć, czy oznacza ona system generujący odpowiedzi, funkcję podpowiadania tekstu, automatyczne tłumaczenie, eksperymentalny tryb wyszukiwarki czy tylko nazwę produktu.

W interfejsie urzędowego asystenta bardziej użyteczny będzie komunikat w rodzaju: „Rozmawiasz z systemem sztucznej inteligencji. Odpowiedzi są generowane automatycznie i mogą wymagać weryfikacji.” Nie chodzi o to, aby przed każdą rozmową wyświetlać pół strony regulaminu. Chodzi o podanie użytkownikowi informacji wystarczającej do zrozumienia, z czym ma do czynienia.

To szczególnie istotne wtedy, gdy projekt interfejsu przypomina klasyczny komunikator. Avatar, imię własne, animacja pisania i naturalny język mogą skutecznie zacierać granicę między rozmową z człowiekiem a systemem. W takim przypadku dyskretna plakietka w rogu może formalnie istnieć, ale niekoniecznie spełniać swoją funkcję informacyjną.

Kolor nie powinien decydować o tym, czy użytkownik rozpozna AI

Kolejny łatwy do popełnienia błąd to oznaczanie pochodzenia treści wyłącznie kolorem. Odpowiedzi systemu AI mogą mieć na przykład niebieskie tło, odpowiedzi konsultanta białe, a komunikaty techniczne szare. Wizualnie taki układ może wyglądać przejrzyście, ale część użytkowników nie rozpozna znaczenia różnicy.

W3C przypomina, że kolor nie powinien być jedynym środkiem przekazywania informacji. Jeśli zmiana barwy niesie znaczenie, potrzebny jest dodatkowy sposób identyfikacji, na przykład tekst lub symbol mający dostępny odpowiednik. Źródło: W3C WAI – Designing for Web Accessibility.

W praktyce oznacza to, że jeśli odpowiedź została wygenerowana przez AI, można wizualnie odróżnić ją kolorem, ale obok powinno pojawić się także jednoznaczne oznaczenie tekstowe. Nie musi być długie. W zależności od kontekstu wystarczy „Odpowiedź AI”, „Wygenerowane przez AI” albo inny komunikat, którego znaczenie jest jasne również bez widzenia zastosowanej kolorystyki.

aria-label nie powinno służyć do ukrywania ważnej informacji

Częstym odruchem podczas poprawiania dostępności jest dodanie aria-label. Projektant zostawia na ekranie niewielką ikonę, a osobie korzystającej z czytnika ekranu przekazuje rozszerzoną informację poprzez dostępny opis. Technicznie może to działać, ale nie zawsze jest dobrym rozwiązaniem.

Jeżeli informacja jest istotna dla wszystkich użytkowników, powinna być widoczna dla wszystkich. Ukrycie pełnego komunikatu wyłącznie w warstwie dostępności tworzy dwie różne wersje interfejsu: osoba niewidoma dowiaduje się czegoś, czego nie widzi osoba korzystająca ze strony wzrokowo. W drugą stronę problem wygląda jeszcze gorzej — plakietka jest widoczna, ale nie ma żadnego programowo określonego odpowiednika.

aria-label jest przydatne tam, gdzie trzeba nadać dostępną nazwę elementowi, którego znaczenie nie wynika wystarczająco jasno z samej treści. Nie powinno jednak zastępować zwykłego widocznego tekstu tylko dlatego, że projektant chce utrzymać minimalistyczny wygląd strony. W3C w swoich materiałach dotyczących ARIA podkreśla znaczenie właściwych dostępnych nazw i opisów elementów interaktywnych, ale semantyka nie jest sposobem na ukrywanie przed częścią odbiorców informacji istotnych dla wszystkich.

Najwięcej problemów zaczyna się wtedy, gdy interfejs się zmienia

Statyczna informacja na początku rozmowy jest stosunkowo łatwa do przygotowania. Trudniej robi się wtedy, gdy status systemu zmienia się już podczas korzystania z usługi. Wyobraźmy sobie platformę, w której pierwsze odpowiedzi generuje AI, a później rozmowę przejmuje pracownik. Albo odwrotnie: konsultant kończy dyżur i dalsze odpowiedzi zaczyna tworzyć automat.

Osoba patrząca na ekran może zobaczyć komunikat „Rozmowę przejął konsultant” albo zmianę etykiety przy avatarze. Użytkownik czytnika ekranu nie musi jednak automatycznie dowiedzieć się o zmianie, jeśli aktualizacja pojawiła się poza aktualnym miejscem odczytu.

W takich sytuacjach przydatne są mechanizmy live regions. W3C opisuje je jako sposób przekazywania technologii asystującej informacji o treści, która zmieniła się bez przeładowania strony. aria-live="polite" pozwala zwykle ogłosić komunikat w odpowiednim momencie bez gwałtownego przerywania bieżącej wypowiedzi czytnika. Dla bardziej pilnych informacji istnieją rozwiązania o wyższym priorytecie, ale trzeba używać ich ostrożnie, ponieważ nadmierne przerywanie użytkownika samo staje się barierą. Źródło: W3C WAI – User Notifications oraz WAI-ARIA – Alert Pattern.

Nie oznacza to, że każdy tekst wygenerowany przez AI powinien trafiać do agresywnego role="alert". Wręcz przeciwnie. Jeśli każda nowa odpowiedź chatbota będzie przerywała użytkownikowi aktualnie czytaną treść, rozmowa stanie się męcząca albo wręcz nieużywalna. Trzeba dobrać mechanizm do znaczenia komunikatu, a następnie przetestować go z rzeczywistą technologią asystującą.

Nie wystarczy, że nowa odpowiedź „jest w DOM”

W dynamicznych chatbotach można spotkać jeszcze jeden problem. Nowa wiadomość pojawia się poprawnie w kodzie strony, ale czytnik ekranu niczego nie ogłasza. Użytkownik wysyła pytanie, czeka, a następnie nie wie, czy system odpowiedział. Zaczyna poruszać się po stronie w poszukiwaniu nowej treści albo ponownie aktywuje przycisk wysyłania.

Przeciwna skrajność również jest częsta. Źle skonfigurowany obszar live powoduje, że po każdej aktualizacji czytnik odczytuje ponownie całą historię rozmowy: pytanie użytkownika, wszystkie poprzednie odpowiedzi i dopiero na końcu nowy komunikat. Po kilku wiadomościach korzystanie z systemu staje się praktycznie niemożliwe.

To jeden z powodów, dla których audytu takiego rozwiązania nie da się zrobić wyłącznie automatycznym skanerem. Narzędzie może wykryć brak nazwy przycisku albo część błędów ARIA, ale nie oceni sensownie przebiegu rozmowy. Trzeba faktycznie uruchomić czytnik ekranu, wysłać wiadomość, poczekać na odpowiedź, sprawdzić sposób jej ogłoszenia, przejść po historii i ocenić, czy użytkownik wie, gdzie się znajduje.

Fokus nie może skakać za każdą odpowiedzią AI

Innym pomysłem na „pomoc” użytkownikowi jest automatyczne przenoszenie fokusu na każdą nową odpowiedź. Teoretycznie gwarantuje to, że osoba korzystająca z klawiatury lub czytnika ekranu dowie się, że system odpowiedział. W praktyce może równie skutecznie odebrać jej kontrolę nad interfejsem.

Jeśli użytkownik w tym samym czasie sprawdza poprzednią wiadomość, wraca do pola wpisywania tekstu albo korzysta z innego elementu strony, nagłe przeniesienie fokusu zmienia jego położenie bez decyzji z jego strony. W większości zwykłych aktualizacji lepszym rozwiązaniem jest pozostawienie fokusu tam, gdzie użytkownik go ustawił, i przekazanie nowej informacji przez odpowiednio skonfigurowany mechanizm statusu lub live region.

W3C w opisie wzorca alertu zwraca uwagę, że komunikaty tego typu powinny zwracać uwagę użytkownika bez niepotrzebnego przerywania wykonywanego zadania, a zwykły alert nie powinien sam przejmować fokusu. Jeśli sytuacja rzeczywiście wymaga przerwania pracy i reakcji użytkownika, istnieją do tego inne wzorce, na przykład dialog alertowy. Źródło: W3C APG – Alert Pattern.

Informacja o AI musi przetrwać powiększenie

Czytnik ekranu jest najbardziej oczywistym przykładem technologii asystującej, ale nie jedynym. Użytkownik słabowidzący może korzystać z powiększenia przeglądarki albo narzędzia systemowego, przez co widzi tylko fragment interfejsu. Komunikat znajdujący się w prawym górnym rogu okna chatbota może wtedy wypaść poza aktualny obszar ekranu.

Problem robi się szczególnie widoczny w komponentach projektowanych jako sztywne panele o określonej wysokości i szerokości. Przy większym powiększeniu informacje zaczynają się nakładać, znikają przyciski zamknięcia, a użytkownik musi przewijać jednocześnie całe okno i wewnętrzną historię rozmowy. Oznaczenie AI może formalnie nadal istnieć, ale dotarcie do niego staje się trudniejsze niż sama rozmowa.

Dlatego test oznaczenia systemu powinien obejmować nie tylko pytanie „czy napis jest na ekranie”, ale też zachowanie komponentu przy zmianie rozmiaru tekstu, powiększeniu i w wąskim widoku. Jeżeli kluczowa informacja znika albo zostaje zasłonięta, trudno uznać taki sposób jej przekazania za skuteczny.

Najlepiej nie sprawdzać samej etykiety, tylko cały początek rozmowy

Jeżeli chcemy ocenić, czy użytkownik rzeczywiście wie, że korzysta z AI, nie warto ograniczać testu do wyszukania odpowiedniego napisu w kodzie. Lepiej przejść przez system tak, jak zrobi to osoba korzystająca z usługi po raz pierwszy.

Po otwarciu chatbota użytkownik powinien móc ustalić, czym jest uruchomione narzędzie, czy odpowiada człowiek czy system, jak rozpocząć rozmowę oraz — jeśli ma to znaczenie — gdzie znajdują się informacje o ograniczeniach usługi i alternatywnym sposobie kontaktu. Dopiero później można oceniać sam formularz wiadomości, przycisk wysyłania i historię czatu.

Taki sposób badania daje dużo więcej informacji niż kontrola pojedynczego kryterium WCAG. Może się okazać, że każdy przycisk posiada nazwę, wszystkie pola są dostępne, a mimo to osoba korzystająca z czytnika ekranu nie ma pojęcia, że rozmawia z AI. Technicznie poszczególne elementy wyglądają poprawnie, ale cały proces przekazuje użytkownikowi niepełny obraz sytuacji.

Co właściwie powinno zostać przetestowane?

W przypadku systemu interaktywnego warto sprawdzić przynajmniej kilka różnych sposobów korzystania. Pierwszy to klasyczna obsługa myszą i wzrokowa kontrola interfejsu. Drugi to pełna obsługa klawiaturą bez używania myszy. Trzeci to praca z czytnikiem ekranu, najlepiej w konfiguracji odpowiadającej rzeczywistemu środowisku użytkowników. Do tego dochodzi powiększenie, zmiana rozmiaru tekstu oraz sprawdzenie zachowania komponentu na małym ekranie.

Podczas takiego testu znaczenie mają rzeczy, których nie widać na zrzucie ekranu. Czy informacja o AI jest odczytana przed pierwszym polem rozmowy? Czy nazwa chatbota jest sensowna? Czy po pojawieniu się odpowiedzi użytkownik dowiaduje się o niej tylko raz? Czy może wrócić do poprzednich wiadomości? Czy status „AI” i „konsultant” jest przekazywany także poza kolorem? Czy zamknięcie okna zwraca fokus w logiczne miejsce? Czy użytkownik może w dowolnym momencie przerwać rozmowę i wybrać inną formę kontaktu?

Właśnie takie pytania pokazują, że dostępność chatbota nie sprowadza się do dodania kilku atrybutów ARIA.

Dobre oznaczenie nie musi być skomplikowane

Paradoksalnie najskuteczniejsze rozwiązania są często dość proste. Użytkownik otwiera okno i przed pierwszą interakcją otrzymuje krótki, widoczny komunikat: rozmawia z systemem AI, odpowiedzi są generowane automatycznie, a w razie potrzeby może skorzystać z kontaktu z człowiekiem. Informacja znajduje się w normalnej strukturze strony i jest odczytywana przez technologie asystujące.

Nowe odpowiedzi pojawiają się w historii rozmowy w przewidywalnym miejscu. System informuje o ich nadejściu bez przenoszenia fokusu. Każda wiadomość ma jednoznacznie oznaczonego nadawcę — „Ty”, „Asystent AI” albo „Konsultant” — i to oznaczenie nie zależy od samego koloru czy położenia dymku. Jeśli rozmowę przejmuje człowiek, zmiana jest przekazywana również czytnikowi ekranu. Jeśli użytkownik chce opuścić czat, może to zrobić klawiaturą bez walki z pułapką fokusu.

Nie ma tu żadnej szczególnie egzotycznej technologii. Potrzebne są dobrze dobrany HTML, przemyślana semantyka, ostrożne użycie ARIA i przede wszystkim test całego procesu.

AI tworzy nowe interfejsy, ale stare zasady nadal działają

Sztuczna inteligencja zmienia sposób, w jaki budujemy usługi cyfrowe, ale nie unieważnia podstawowych zasad dostępności. Użytkownik nadal powinien wiedzieć, gdzie się znajduje, co właśnie się wydarzyło, co może zrobić dalej i jaki skutek będzie miało jego działanie. Różnica polega na tym, że w systemach AI pojawiła się dodatkowa informacja, która często wpływa na interpretację całej usługi: kto — albo co — właśnie do niego mówi.

Dlatego pytanie „czy oznaczyliśmy AI?” jest zbyt proste. Sensowniejsze brzmi: czy każdy użytkownik otrzymał tę informację w momencie, w którym jej potrzebuje, i czy potrafi ją odróżnić od reszty interfejsu?

To można sprawdzić dopiero podczas rzeczywistego używania systemu. Nie wystarczy zobaczyć plakietkę na makiecie ani znaleźć tekst w kodzie. Trzeba otworzyć usługę klawiaturą, uruchomić czytnik ekranu, powiększyć interfejs, wysłać wiadomość i sprawdzić, co faktycznie dzieje się po drugiej stronie.

Dopiero wtedy dowiemy się, czy informacja „rozmawiasz z AI” naprawdę jest informacją dla użytkownika, czy tylko kolejnym elementem graficznym dodanym do projektu.