Chatbot zwykle pojawia się na stronie niewinnie. Niewielki przycisk w prawym dolnym rogu, dymek z pytaniem, czasem sympatyczna nazwa i obietnica, że „chętnie pomoże”. Na prezentacji wygląda świetnie. Nowocześnie, szybko, bez kolejek.
Problemy zaczynają się później.
Użytkownik chce sprawdzić termin złożenia wniosku, ale nie może otworzyć okna z klawiatury. Osoba korzystająca z czytnika ekranu wpisuje pytanie i nie wie, że odpowiedź już się pojawiła. Fokus nagle przeskakuje na początek strony. Chatbot odsyła do formularza, którego nie da się wypełnić. Albo przez kilka minut prowadzi rozmowę, po czym odpowiada, że tej sprawy jednak nie obsługuje.
Wtedy znika cała technologiczna otoczka. Zostaje człowiek, który nadal nie może załatwić swojej sprawy.
I właśnie od tego trzeba zacząć: chatbot urzędu nie jest ozdobą strony ani eksperymentalnym dodatkiem działu IT. Jeżeli pomaga znaleźć informację, kieruje do usługi, zbiera dane, odpowiada na pytania albo zastępuje część pracy konsultanta, staje się elementem usługi publicznej. A skoro tak, jego dostępność nie może być traktowana jako rzecz dodatkowa, którą poprawi się kiedyś, o ile zostanie trochę budżetu.
Chatbot nie działa obok usługi. On staje się jej częścią
Można oczywiście powiedzieć, że wszystkie informacje znajdują się również na stronie. W teorii użytkownik nie musi korzystać z chatbota. W praktyce bywa odwrotnie: nowy interfejs jest mocno eksponowany, wyszukiwarka zostaje schowana, treści są rozproszone, a użytkownikowi od początku sugeruje się rozmowę z „asystentem”.
Czasem chatbot ma tylko wskazać odpowiednią podstronę. Czasem przeprowadza przez wybór formularza. Bywa, że pyta o sytuację użytkownika, analizuje odpowiedzi i na tej podstawie podpowiada świadczenie, termin albo sposób postępowania. Im więcej zadań przejmuje, tym trudniej twierdzić, że jest jedynie opcjonalnym gadżetem.
Polska ustawa o dostępności cyfrowej nakłada na podmioty publiczne obowiązek zapewnienia dostępności ich stron internetowych i aplikacji mobilnych. Oficjalne wyjaśnienia rządowe podkreślają przy tym, że dostępność obejmuje nie tylko statyczne teksty, ale całe cyfrowe środowisko udostępniane użytkownikowi. Chatbot osadzony w serwisie urzędu jest funkcjonalnym elementem tego serwisu, nawet jeżeli technicznie dostarcza go zewnętrzna firma.
To dość oczywiste, kiedy spojrzymy na sytuację oczami mieszkańca. Nie wie on, która spółka stworzyła widget, kto odpowiada za integrację ani gdzie kończy się kod urzędu, a zaczyna kod dostawcy. Widzi stronę konkretnej instytucji i zakłada, że udostępnione na niej narzędzie jest częścią jej obsługi.
I ma do tego pełne prawo.
Bariera nie zawsze wygląda jak zepsuty przycisk
Najłatwiej zauważyć problemy techniczne. Okno rozmowy nie otwiera się z klawiatury. Przycisk nie ma dostępnej nazwy. Kolejność fokusu jest przypadkowa. Po zamknięciu chatbota użytkownik nie wraca do miejsca, z którego go uruchomił.
To są rzeczy konkretne, dość łatwe do opisania w raporcie. Ale prawdziwe skutki pojawiają się dopiero w trakcie rozmowy.
Wyobraźmy sobie osobę niewidomą, która wpisuje pytanie: „Do kiedy mogę złożyć wniosek?”. Na ekranie pojawia się odpowiedź, jednak czytnik ekranu jej nie ogłasza. Wizualnie wszystko działa. Tekst jest. System uznaje zadanie za zakończone. Tyle że użytkownik nadal czeka.
W interfejsach konwersacyjnych nowe wiadomości pojawiają się dynamicznie, bez przeładowania strony. WAI-ARIA przewiduje do takich sytuacji między innymi regiony na żywo i rolę log, dzięki którym technologie asystujące mogą informować o kolejnych wpisach bez wymuszania przenoszenia fokusu. Samo dodanie tekstu do kodu strony nie oznacza jeszcze, że czytnik ekranu przekaże go użytkownikowi we właściwym momencie.
Bywa też odwrotnie. Chatbot ogłasza wszystko: każdą zmianę statusu, animację pisania, trzy komunikaty techniczne i całą długą odpowiedź od początku. Użytkownik słyszy potok informacji, którego nie może zatrzymać ani uporządkować. Formalnie zastosowano mechanizm dostępności. Praktycznie stworzono nową barierę.
To dobrze pokazuje, dlaczego nie wystarczy odhaczyć kilku atrybutów ARIA. Interfejs trzeba sprawdzić w prawdziwej rozmowie.
Fokus, który żyje własnym życiem
Jednym z najbardziej irytujących problemów jest utrata fokusu.
Użytkownik otwiera chatbota z klawiatury, ale fokus pozostaje gdzieś pod oknem. Pisze, naciska Tab i nagle przechodzi do stopki strony. Innym razem po wysłaniu wiadomości fokus przeskakuje na przycisk zamknięcia, na początek dokumentu albo w niewidoczne miejsce. Człowiek nie wie już, gdzie jest.
Dla osoby korzystającej z myszy może to być niezauważalne. Kursor nadal znajduje się tam, gdzie został. W obsłudze klawiaturą fokus jest jednak odpowiednikiem wzroku — mówi, który element jest w danym momencie aktywny i co wydarzy się po naciśnięciu Enter.
Dobry chatbot powinien zachowywać się przewidywalnie. Po otwarciu prowadzić użytkownika do logicznego pierwszego elementu. Po wysłaniu wiadomości nie wyrywać go z pola edycji bez potrzeby. Po zamknięciu oddać fokus przyciskowi, który wcześniej otworzył rozmowę.
To nie są techniczne fanaberie. Gdy fokus się gubi, rozmowa się kończy. Czasem dosłownie po pierwszym pytaniu.
WCAG 2.2 obejmuje między innymi wymagania dotyczące obsługi klawiaturą, widoczności fokusu, przewidywalnego działania, komunikatów o stanie oraz identyfikowania błędów. Standard dotyczy zarówno treści, jak i kodu tworzącego interakcję w aplikacji internetowej.
Czas działa przeciwko użytkownikowi
Chatboty często mają limity sesji. Jeżeli użytkownik przez kilkadziesiąt sekund niczego nie wpisze, rozmowa wygasa. System chce oszczędzać zasoby albo chronić dane. Technicznie można to uzasadnić.
Tyle że nie każdy czyta i pisze w tym samym tempie.
Osoba korzystająca z czytnika ekranu musi najpierw odnaleźć odpowiedź, wysłuchać jej, czasem wrócić do wcześniejszego fragmentu, a dopiero potem przygotować kolejne pytanie. Ktoś z niepełnosprawnością ruchową może wpisywać tekst znacznie wolniej. Osoba z trudnościami poznawczymi potrzebuje chwili, by zrozumieć komunikat i zdecydować, co zrobić dalej.
Jeżeli w tym czasie system usuwa rozmowę, problem nie polega wyłącznie na wygodzie. Użytkownik traci wykonaną pracę, kontekst sprawy, a czasem także możliwość dotarcia do informacji.
Jeszcze gorzej, gdy ostrzeżenie o wygaśnięciu pojawia się na kilka sekund i jest dostępne tylko wzrokowo. Ktoś korzystający z technologii asystującej dowiaduje się o zakończeniu sesji dopiero wtedy, gdy próbuje wysłać kolejne pytanie.
Dostępność wymaga, by ograniczenia czasowe były uzasadnione, przewidywalne i — tam, gdzie to możliwe — możliwe do przedłużenia. Nie wystarczy komunikat: „Sesja wygasła. Zacznij od nowa”.
Chatbot może działać technicznie i nadal być niedostępny
Największym błędem byłoby sprowadzenie całego badania do kodu.
Załóżmy, że okno otwiera się z klawiatury. Fokus jest widoczny. Odpowiedzi są poprawnie ogłaszane. Kontrast spełnia wymagania. Wszystko wygląda obiecująco.
Potem użytkownik pyta: „Czy mogę otrzymać dodatek mieszkaniowy?”.
Chatbot odpowiada kilkunastozdaniowym blokiem tekstu, używa nazw ustaw, przywołuje wyjątki bez wyjaśnienia, podaje nieopisane skróty i kończy zdaniem: „W celu procedowania należy dokonać weryfikacji przesłanek formalnoprawnych we właściwej jednostce organizacyjnej”.
Technicznie dostępne. Po ludzku — niemal bezużyteczne.
Dostępność nie kończy się na tym, że odpowiedź można odczytać. Trzeba ją jeszcze zrozumieć. Użytkownik powinien wiedzieć, czy system odpowiedział na jego pytanie, skąd pochodzą informacje, co ma zrobić dalej i czy odpowiedź uwzględnia aktualny stan prawny.
Chatbot urzędowy nie może zasłaniać niepewności pewnym tonem. Jeżeli nie zna odpowiedzi, powinien to powiedzieć. Jeżeli wynik zależy od indywidualnej sytuacji, nie może udawać, że wydał wiążącą ocenę. Jeżeli korzysta z konkretnego źródła, dobrze, by pozwalał do niego przejść.
Brzmi banalnie, ale generatywne systemy potrafią pisać bardzo przekonująco także wtedy, gdy się mylą.
Pytania można poprawiać. Odpowiedzi również
Zwykła rozmowa ma naturalny mechanizm naprawczy. Możemy powiedzieć: „Nie o to mi chodziło”, „zacznijmy jeszcze raz”, „wyjaśnię inaczej”.
Chatbot często takiej swobody nie daje.
Użytkownik popełnia literówkę, a system zmienia temat. Pytanie zostało źle zinterpretowane, ale nie można go edytować. Nie da się wrócić do poprzedniego kroku. Przyciski szybkich odpowiedzi znikają po wybraniu jednej opcji. Gdy użytkownik orientuje się, że kliknął źle, musi zamknąć rozmowę i zacząć od początku.
Dla części osób będzie to drobna niedogodność. Dla kogoś, kto długo wpisywał odpowiedzi, korzysta z komunikacji alternatywnej albo ma trudności z pamięcią roboczą, może to być koniec całego procesu.
Dlatego dostępny chatbot powinien pozwalać poprawić pytanie, wrócić do wcześniejszego etapu, przerwać błędnie rozpoczęty scenariusz i zachować kontekst rozmowy. Nie każdy użytkownik przejdzie przez idealnie zaprojektowaną ścieżkę. Właściwie mało kto przejdzie.
Niejasny błąd jest ślepą uliczką
„Coś poszło nie tak”.
To jeden z najbardziej bezużytecznych komunikatów współczesnych interfejsów. Nie mówi, co się wydarzyło, czy wiadomość została wysłana, czy trzeba spróbować ponownie, ani czy problem leży po stronie użytkownika.
W chatbocie konsekwencje są poważniejsze, bo błąd może przerwać rozmowę bez ostrzeżenia. System przestaje odpowiadać. Kręci się animacja. Po chwili pojawia się prośba o rozpoczęcie nowej sesji, bez możliwości odzyskania wcześniejszych wiadomości.
Dostępny komunikat o błędzie powinien zostać rozpoznany przez technologie asystujące, wyjaśniać problem zrozumiałym językiem i wskazywać możliwe wyjście. W3C opisuje wykorzystanie regionów na żywo i roli alert właśnie po to, by dynamicznie wyświetlane błędy nie pozostały niezauważone przez użytkownika czytnika ekranu. W3C
Nie zawsze da się od razu naprawić awarię. Da się jednak napisać: „Nie udało się wysłać wiadomości. Jej treść pozostała w polu. Spróbuj ponownie albo skorzystaj z formularza kontaktowego”. To już jest informacja. Jest problem, ale jest też droga dalej.
Kto odpowiada: producent, integrator czy urząd?
Najczęstsza odpowiedź brzmi: „To zależy”.
I rzeczywiście zależy — ale głównie wtedy, gdy rozmawiamy o wzajemnych rozliczeniach między podmiotami. Z perspektywy użytkownika sprawa jest znacznie prostsza.
Producent odpowiada za dostępność samego produktu i komponentów, które dostarcza. Integrator odpowiada za sposób osadzenia rozwiązania, konfigurację, połączenie z serwisem i ewentualne modyfikacje. Administrator strony może odpowiadać za aktualizacje, treści, ustawienia i reakcję na zgłoszone problemy. Każdy z nich ma swój fragment układanki.
Jednak to urząd zdecydował, że chatbot zostanie udostępniony jako kanał obsługi. To urząd umieścił go na swojej stronie, powierzył mu określone zadania i zaprosił mieszkańców do korzystania.
Oficjalne materiały dotyczące dostępności cyfrowej konsekwentnie wskazują, że podmiot publiczny odpowiada za cyfrowe treści i rozwiązania, które udostępnia użytkownikom — także wtedy, gdy publikacja lub obsługa odbywa się z wykorzystaniem zewnętrznej platformy.
Umowa z dostawcą może określać, kto zapłaci za poprawki. Nie może jednak sprawić, że bariera przestanie być problemem urzędu.
Mieszkaniec nie powinien usłyszeć: „Proszę zgłosić to producentowi chatbota”. Tak samo jak nie odsyła się go do autora wtyczki, gdy nie może wysłać urzędowego formularza.
Wiele barier kupuje się razem z systemem
Problemy z dostępnością często nie zaczynają się podczas wdrożenia. Zaczynają się dużo wcześniej, w opisie zamówienia.
Urząd zamawia „inteligentnego asystenta”, określa liczbę obsługiwanych tematów, czas odpowiedzi, integrację z bazą wiedzy i wygląd okna rozmowy. Dostępność pojawia się w jednym zdaniu: „Rozwiązanie powinno być zgodne z WCAG”.
To za mało.
Nie wiadomo, którą wersję standardu przyjęto. Nie wiadomo, jaki zakres systemu będzie badany, kto przeprowadzi testy ani co stanie się po wykryciu błędów. Nie opisano działania czytnika ekranu, zarządzania fokusem, komunikatów dynamicznych, ograniczeń czasowych, powiększenia tekstu czy obsługi bez myszy. Nie określono też, jak ma wyglądać przekazanie rozmowy człowiekowi.
Europejska norma EN 301 549 zawiera wymagania dostępności odnoszące się do produktów i usług ICT, w tym stron internetowych, oprogramowania i rozwiązań wykorzystywanych w zamówieniach publicznych. Samo wpisanie nazwy normy lub WCAG nie zastępuje jednak funkcjonalnych wymagań, scenariuszy odbioru i odpowiedzialności za błędy.
Jeżeli dostępność nie zostanie opisana przed zakupem, urząd może otrzymać produkt, który świetnie prezentuje się na spotkaniu, ale nie przechodzi podstawowego testu klawiaturą. Potem zaczyna się klasyczna wymiana zdań: wykonawca twierdzi, że tego nie było w zakresie, integrator wskazuje na ograniczenia komponentu, a urząd zostaje z narzędziem, którego nie da się poprawić bez kolejnego zamówienia.
To nie jest awaria, która wydarzyła się po drodze. To skutek źle określonych wymagań.
Chatbot nie powinien udawać urzędnika
Ryzyko rośnie, gdy system przestaje tylko wyszukiwać informacje i zaczyna je interpretować.
Pytania o godziny otwarcia są stosunkowo bezpieczne. Pytania o prawo do świadczenia, bieg terminu, obowiązek dołączenia dokumentu albo konsekwencje niedopełnienia formalności — już nie.
Odpowiedź może brzmieć spokojnie i zdecydowanie, choć została wygenerowana na podstawie niepełnej informacji. Użytkownik może nie wiedzieć, że system nie uwzględnił wyjątku, lokalnej uchwały, szczególnej sytuacji rodzinnej czy zmiany przepisów.
AI Act wymaga, aby osoba wchodząca w bezpośrednią interakcję z systemem AI była poinformowana, że komunikuje się z AI, chyba że jest to oczywiste z okoliczności. Informacja ma być przekazana najpóźniej przy pierwszej interakcji i w formacie dostępnym dla osób z niepełnosprawnościami.
Taka informacja jest potrzebna, ale sama nie wystarcza.
Użytkownik musi również rozumieć granice systemu. Czy chatbot podaje wyłącznie informacje ogólne? Czy korzysta z aktualnej bazy? Czy odpowiedź może być podstawą działania? Czy sprawę można przekazać pracownikowi?
W komunikacji urzędowej zdanie „to tylko AI” nie może służyć za usprawiedliwienie błędnej odpowiedzi. Skoro urząd zdecydował się na takie narzędzie, musi zaprojektować również bezpieczne wyjście z sytuacji, w której system nie wie, nie rozumie albo się myli.
Człowiek powinien być dostępny naprawdę, nie tylko w regulaminie
W wielu chatbotach przycisk „połącz z konsultantem” istnieje, ale działa wyłącznie od poniedziałku do piątku w wąskim przedziale godzin. Poza nim użytkownik otrzymuje numer telefonu. Albo formularz. Albo informację, że powinien przyjść osobiście.
Formalnie alternatywa jest. Tylko czy jest równoważna?
Telefon nie będzie odpowiednim kanałem dla każdej osoby Głuchej. Formularz kontaktowy nie zastąpi rozmowy, gdy do końca terminu pozostała godzina. Wizyta osobista odbiera samodzielność osobie, która wybrała usługę cyfrową właśnie dlatego, że nie może łatwo dotrzeć do urzędu.
Alternatywny kanał ma sens wtedy, gdy pozwala osiągnąć ten sam cel bez dodatkowych kosztów, zbędnej zwłoki i utraty prywatności. Nie musi wyglądać identycznie. Musi jednak być realny.
Jeżeli chatbot odpowiada natychmiast osobom pełnosprawnym, a użytkownik technologii asystującej musi wysłać e-mail i czekać trzy dni, nie mamy równoważnego dostępu. Mamy obejście bariery, a to jednak co innego.
W dobrze zaprojektowanym systemie przejście do człowieka nie powinno oznaczać rozpoczęcia całej sprawy od początku. Konsultant powinien — za zgodą użytkownika i z poszanowaniem ochrony danych — otrzymać kontekst rozmowy. W przeciwnym razie człowiek po raz kolejny opisuje to samo. A przecież przyszedł po pomoc właśnie dlatego, że pierwszy kanał zawiódł.
Jak badać chatbota, żeby naprawdę coś sprawdzić?
Nie wystarczy uruchomić automatyczny skaner. Oficjalne materiały dotyczące testowania dostępności cyfrowej wyraźnie zaznaczają, że automatyczne narzędzia wykrywają tylko część problemów. Są użyteczne, ale nie zastępują badania ręcznego ani oceny całego procesu. Gov.pl
Chatbot powinien zostać przetestowany warstwowo.
Najpierw sam interfejs: przycisk otwierający, okno dialogowe, pole wpisywania, wysyłanie wiadomości, historia rozmowy, elementy sterujące i zamknięcie. Wszystko klawiaturą, przy powiększeniu, z czytnikiem ekranu i bez polegania na wzroku.
Potem komunikacja dynamiczna. Czy użytkownik wie, że system przetwarza pytanie? Czy otrzymuje informację o nowej odpowiedzi? Czy może przerwać odczyt? Czy kolejne wiadomości są ogłaszane we właściwej kolejności? Czy komunikat o błędzie nie ginie pomiędzy innymi aktualizacjami?
Następnie język i treść. Nie tylko poprawność gramatyczna, ale sens. Czy odpowiedź dotyczy pytania? Czy jest zrozumiała? Czy odróżnia informację ogólną od indywidualnej porady? Czy wskazuje źródło i datę aktualności? Czy użytkownik wie, co ma zrobić dalej?
Trzeba też sprawdzić sytuacje, które nie mieszczą się w idealnym scenariuszu. Literówkę. Niepełne pytanie. Dwa problemy w jednym zdaniu. Zmianę tematu. Rezygnację w połowie. Brak połączenia. Wygaśnięcie sesji. Odpowiedź, której system nie zna.
Na końcu pozostaje przejście do człowieka. Nie sam przycisk, ale cały proces: godziny dostępności, sposób połączenia, zachowanie historii rozmowy, prywatność, czas oczekiwania i możliwość wybrania innego kanału.
Dopiero wtedy wiadomo, czy chatbot jest dostępny. Nie wtedy, gdy narzędzie pokaże zielony wynik.
Najważniejsza odpowiedź jest dość niewygodna
Kto odpowiada za niedostępnego chatbota?
Producent może odpowiadać za wadliwy komponent. Integrator za błędne wdrożenie. Administrator za zaniedbaną aktualizację. Autor treści za niezrozumiałe odpowiedzi. W praktyce odpowiedzialność może być podzielona między kilka podmiotów i opisana w umowach.
Dla użytkownika odpowiedź jest jednak krótsza: odpowiada urząd, który udostępnił narzędzie jako część swojej usługi.
Nie oznacza to, że urząd ma samodzielnie naprawiać kod zewnętrznego dostawcy. Oznacza, że musi wybrać dostępne rozwiązanie, wpisać wymagania do zamówienia, zbadać produkt przed odbiorem, reagować na zgłoszenia i zapewnić skuteczny kanał zastępczy do czasu usunięcia bariery.
Nie można zaprosić mieszkańców do rozmowy, a potem tłumaczyć, że drzwi są cudze.
Chatbot jest częścią usługi cyfrowej dokładnie tak samo jak formularz, wyszukiwarka czy system rezerwacji. Jego dostępność nie jest osobnym dodatkiem. Wpływa na to, czy człowiek znajdzie informację, zrozumie odpowiedź i załatwi sprawę.
I właśnie za ten rezultat odpowiada instytucja.