Opis zdjęcia: Dłoń trzymająca smartfon, na którego ekranie widoczna jest aplikacja do wysyłania wiadomości z rozmowami na czacie.
Chatboty dla każdego
Chatboty dla wszystkich: tworzenie sztucznej inteligencji, która naprawdę sprzyja integracji
Co szósta osoba żyje z niepełnosprawnością. Gdy konwersacyjna sztuczna inteligencja ich zawodzi, nie jest to przeoczenie projektowe — to złamana obietnica. Oto jak jej dotrzymać.
Sztuczna inteligencja konwersacyjna stała się jedną z najważniejszych zmian w sposobie, w jaki ludzie wchodzą w interakcję z technologią. Chatboty obsługują obecnie obsługę klienta, segregację medyczną, zapytania bankowe, wdrażanie nowych pracowników oraz coraz szerszy zakres codziennych zadań. Jednak dla zbyt wielu osób — tych, które poruszają się po świecie za pomocą czytników ekranu, sterowania głosowego, osób z zaburzeniami funkcji poznawczych, ograniczeniami motorycznymi lub słabym wzrokiem — te same chatboty są pełne barier, z którymi żaden widzący, w pełni sprawny użytkownik nigdy by się nie spotkał.
Nie jest to odosobniony przypadek. Światowa Organizacja Zdrowia szacuje, że 1,3 miliarda osób – czyli około 16% światowej populacji – boryka się z jakąś formą poważnej niepełnosprawności. Liczba ta obejmuje szerokie spektrum schorzeń; nie każda niepełnosprawność wpływa w ten sam sposób na korzystanie z interfejsów cyfrowych, ale znaczna część z nich ma bezpośredni wpływ na to, jak ludzie korzystają z technologii konwersacyjnych. Termin dostosowania się sektora prywatnego do wymogów unijnej ustawy o dostępności upływa w czerwcu 2025 r. — choć okresy przejściowe dla niektórych umów o świadczenie usług i terminali samoobsługowych sięgają 2030 r. lub później, w zależności od kontekstu i wdrożenia przez poszczególne państwa członkowskie. Amerykańska ustawa o osobach niepełnosprawnych (Americans with Disabilities Act) jest stosowana w odniesieniu do interfejsów cyfrowych w coraz większej liczbie jurysdykcji, choć sytuacja prawna w Stanach Zjednoczonych pozostaje niejednolita w poszczególnych okręgach sądowych. W regionie Azji i Pacyfiku podobne regulacje są wprowadzane w coraz szybszym tempie. Dostępność nie jest już tylko dodatkową opcją, którą dodaje się po uruchomieniu produktu: jest to obowiązek prawny, imperatyw komercyjny i podstawowa norma etyczna.
W AIOPSGROUP, spółce należącej do valantic, współpracujemy z przedsiębiorstwami wdrażającymi konwersacyjną sztuczną inteligencję na szeroką skalę. Nieustannie dostrzegamy rozbieżność między ambicjami związanymi z wdrożeniem a rzeczywistymi doświadczeniami wszystkich użytkowników. W niniejszym artykule opisujemy tę rozbieżność, wskazujemy główne przeszkody i przedstawiamy praktyczne wytyczne dotyczące tworzenia chatbotów, które naprawdę służą wszystkim.
Key insight
Projektowanie z uwzględnieniem dostępności nie jest ograniczeniem — to czynnik zwiększający jakość. Każde ulepszenie wprowadzone z myślą o użytkownikach z niepełnosprawnościami zazwyczaj poprawia komfort korzystania ze strony dla wszystkich użytkowników: prostszy język zmniejsza ryzyko nieporozumień dla wszystkich; sprawna nawigacja za pomocą klawiatury przynosi korzyści zaawansowanym użytkownikom; a jasne komunikaty o błędach pomagają zarówno początkującym, jak i ekspertom.
Dlaczego chatboty dostosowane do potrzeb osób niepełnosprawnych stanowią priorytet strategiczny
Argumenty biznesowe przemawiające za tworzeniem chatbotów dostosowanych do potrzeb osób niepełnosprawnych są silniejsze, niż zdaje sobie sprawę większość organizacji. Wystarczy spojrzeć na potencjalny rynek: w samych Stanach Zjednoczonych osoby niepełnosprawne dysponują łącznie dochodem do dyspozycji przekraczającym 490 miliardów dolarów. W skali globalnej organizacja Return on Disability Group szacuje, że szerszy „rynek osób niepełnosprawnych” — obejmujący osoby niepełnosprawne oraz ich przyjaciół i rodziny, którzy preferują marki dostępne dla wszystkich — ma wpływ na wydatki rzędu ponad 13 bilionów dolarów rocznie. Jest to szacunek oparty na danych własnych, a definicje mogą się różnić, ale nawet ostrożne interpretacje bezpośredniego rynku docelowego sięgają setek miliardów dolarów. Niedostępny chatbot to nie tylko niedogodność; to aktywnie przeciekający lejek.
Ryzyko prawne potęguje argumenty natury handlowej. Orzeczenie Sądu Apelacyjnego Dziewiątego Okręgu z 2019 r. w sprawie Robles przeciwko Domino’s Pizza – które uchyliło oddalenie sprawy przez sąd okręgowy i zezwoliło na jej dalsze prowadzenie – miało decydujący wpływ na ustalenie, że roszczenia wynikające z ADA dotyczące stron internetowych mogą być rozpatrywane przez sąd, jednak nie zawierało ostatecznego stwierdzenia, że ADA ma kategoryczne zastosowanie do wszystkich stron internetowych. Sprawa została ostatecznie rozstrzygnięta ugodą. Krajobraz prawny w Stanach Zjednoczonych pozostaje rozdrobniony. Utrzymuje się rozbieżność między okręgami sądowymi: niektóre z nich wymagają „powiązania” z fizyczną lokalizacją, aby ADA miała zastosowanie, podczas gdy inne tego nie wymagają. Warto zauważyć, że w marcu 2022 r. Departament Sprawiedliwości wydał formalne wytyczne stwierdzające, że ADA ma zastosowanie do stron internetowych i aplikacji nawet bez powiązania z fizyczną lokalizacją, co znacząco zmieniło krajobraz regulacyjny jeszcze przed uzyskaniem jasności legislacyjnej. Kierunek zmian zmierza jednak w stronę szerszego zakresu stosowania, a liczba pozwów dotyczących dostępności w Stanach Zjednoczonych osiągnęła w ostatnich latach rekordowy poziom. Dyrektywa UE w sprawie dostępności stron internetowych oraz szersza ustawa UE o dostępności nakładają na państwa członkowskie jasne obowiązki ustawowe dotyczące usług cyfrowych zarówno w sektorze publicznym, jak i prywatnym. Handel detaliczny, usługi finansowe i opieka zdrowotna pozostają wśród sektorów najczęściej objętych tymi przepisami — a są to właśnie branże, które najaktywniej wdrażają chatboty.
Istnieje również aspekt wizerunkowy. Marki, które przodują w zakresie dostępności, osiągają wyraźnie wyższe wskaźniki lojalności wśród użytkowników z niepełnosprawnościami i ich otoczenia. Z drugiej strony, post, który rozprzestrzenia się w sieci, opisujący niedostępne doświadczenie — na przykład sytuację, w której użytkownik czytnika ekranu nie jest w stanie poruszać się po czacie botowym, lub gdy klient niesłyszący nie ma dostępu do pomocy tekstowej, ponieważ interfejs opiera się wyłącznie na komunikatach głosowych — może spowodować szkody wizerunkowe nieproporcjonalne do nakładu pracy wymaganego do usunięcia usterki technicznej.
„Tworząc rozwiązania dla osób niepełnosprawnych, często rozwiązuje się problemy, z którymi jutro zmierzy się ogół społeczeństwa. Dostępne chatboty nie są kompromisem — to wczesne opracowanie właściwych rozwiązań”.Dział sztucznej inteligencji konwersacyjnej w AIOPSGROUP
Przegląd otoczenia regulacyjnego
Różnorodność przepisów prawnych na całym świecie może wydawać się przytłaczająca dla zespołów w przedsiębiorstwach. Poniżej znajduje się zbiorcze zestawienie zawierające ramy prawne o największym znaczeniu dla organizacji wdrażających chatboty na głównych rynkach.
| Rozporządzenie | Geografia | Najważniejsze obowiązki chatbota | Status egzekucji | Standard zgodności |
|---|---|---|---|---|
| Tytuł III ustawy ADA | Stany Zjednoczone | Interfejsy cyfrowe przeznaczone dla użytkowników muszą być dostępne | Toczące się postępowania sądowe | WCAG 2.1 AA (de facto) |
| Sekcja 508 | Stany Zjednoczone (władze federalne) | Technologia informacyjno-komunikacyjna (ICT) nabywana lub wykorzystywana przez agencje federalne musi być zgodna z | Wprowadzony | WCAG 2.0 AA oraz przepisy sekcji 508 |
| Unijna ustawa o dostępności | Unia Europejska | Produkty i usługi cyfrowe sektora prywatnego muszą spełniać te wymogi; w przypadku niektórych umów o świadczenie usług i terminali samoobsługowych przewidziano okresy przejściowe do 2030 r. | Czerwiec 2025 r. (termin składania wniosków; terminy mogą się różnić) | WCAG 2.1 AA / EN 301 549 |
| Dyrektywa w sprawie dostępności stron internetowych | Unia Europejska (sektor publiczny) | Strony internetowe i aplikacje sektora publicznego muszą być zgodne z przepisami | Wprowadzony | EN 301 549 / WCAG 2.1 AA |
| Ustawa o równości z 2010 r. | Wielka Brytania | Niezbędne racjonalne dostosowania w usługach cyfrowych | Wprowadzony | WCAG 2.1 AA (zalecane) |
| AODA (WCAG 2.0 AA) | Ontario, Kanada | Duże organizacje muszą spełniać wymagania WCAG 2.0 poziom AA we wszystkich swoich zasobach cyfrowych | Wprowadzony | WCAG 2.0 AA |
| Ustawa o zakazie dyskryminacji ze względu na niepełnosprawność | Australia | Usługi cyfrowe nie mogą dyskryminować osób niepełnosprawnych | oparte na skargach | WCAG 2.1 AA (zalecenia) |
WCAG 2.2 AA: Niezbędne wymagania podstawowe
Wytyczne dotyczące dostępności treści internetowych (WCAG), opublikowane przez konsorcjum W3C, stanowią uznany na całym świecie standard w zakresie dostępności cyfrowej. Wersja 2.2 — aktualny standard normatywny — dodaje dziewięć nowych kryteriów sukcesu do wersji 2.1, z których kilka ma bezpośrednie znaczenie dla interfejsów chatbotów. Ważne jest, aby jasno określić, czym jest WCAG 2.2 AA, a czym nie jest: jest to przyjęty minimalny poziom prawny na większości głównych rynków, a nie pułap ani gwarancja projektowania sprzyjającego włączeniu społecznemu. Przejście automatycznego audytu WCAG nie oznacza, że każdy użytkownik będzie miał równie dobre wrażenia — oznacza to, że spełniłeś określony zestaw kryteriów technicznych. Prawdziwa inkluzywność wymaga pójścia o krok dalej: prostego języka, testów użytkowników z udziałem osób niepełnosprawnych oraz ciągłego doskonalenia. Mając to na uwadze, zrozumienie WCAG poprzez jego cztery podstawowe zasady daje nam najjaśniejszy obraz projektowania chatbotów.
Wyczuwalny
Informacje i elementy interfejsu użytkownika muszą być przedstawiane użytkownikom w sposób dla nich zrozumiały. Wszystkie komunikaty chatbota, ikony i wskaźniki stanu muszą mieć odpowiedniki tekstowe. Żadnych informacji nie należy przekazywać wyłącznie za pomocą kolorów.
Działające
Wszystkie elementy interaktywne muszą być dostępne za pomocą klawiatury. Pola wprowadzania tekstu w czacie, przyciski wysyłania, okienka z sugestiami oraz załączniki plików muszą umożliwiać ustawienie na nich kursora, obsługiwane bez użycia myszy oraz mieć odpowiednie rozmiary elementów docelowych (co najmniej 24×24 piksele zgodnie z wytycznymi WCAG 2.2).
To zrozumiałe
Odpowiedzi chatbota muszą być sformułowane prostym językiem. Komunikaty o błędach muszą jasno wyjaśniać, co poszło nie tak i jak to naprawić. W przypadku przekroczenia limitu czasu sesji użytkownicy muszą otrzymać odpowiednie ostrzeżenie z wyprzedzeniem. Spójne schematy interakcji zmniejszają obciążenie poznawcze.
Solidny
Chatbot musi działać niezawodnie w połączeniu z różnymi technologiami wspomagającymi — czytnikami ekranu (NVDA, JAWS, VoiceOver), oprogramowaniem do sterowania głosowego (Dragon NaturallySpeaking) oraz przy powiększeniu przeglądarki do 400%. Dynamiczne aktualizacje treści muszą być sygnalizowane za pomocą regionów ARIA live.
Nowości w WCAG 2.2: Jakie wymagania muszą spełniać chatboty
W standardzie WCAG 2.2 wprowadzono kryteria dotyczące typowych schematów występujących w interfejsach użytkownika współczesnych chatbotów. Największe znaczenie dla interfejsów konwersacyjnych mają:
| Kryterium | Poziom | Czego to wymaga | Znaczenie chatbotów | Tryb awarii |
|---|---|---|---|---|
| 2.4.11 Ostrość nie jest zasłonięta (minimum) | AA | Element „Focused” nie jest całkowicie zasłonięty przez treść przyklejoną | Nagłówki i stopki widżetu czatu nie mogą zasłaniać pola wprowadzania danych lub wiadomości, na którym znajduje się kursor | Przeglądarka z przyklejonym paskiem narzędzi ukrywa przycisk wysyłania, na którym spoczywa kursor |
| 2.4.12 Ostrość niezakłócona (ulepszona) | AAA | Element, na którym skupiono uwagę, jest w pełni widoczny, a nie częściowo zasłonięty | Żadna część elementu aktywnego nie jest zasłonięta przez elementy interfejsu użytkownika typu sticky | Częściowo zasłonięte żetony z podpowiedziami |
| 2.5.3 Wielkość celu (minimalna) | AA | Docelowy rozmiar elementów wejściowych typu pointer wynosi co najmniej 24×24 piksele CSS | Przycisk „Wyślij”, selektor emotikonów, ikony załączników oraz przycisk „Zamknij” muszą mieć wymiary co najmniej 24×24 piksele | Przyciski zawierające wyłącznie ikony o rozmiarze 16 pikseli |
| 2.5.7 Ruchy przeciągania | AA | Czynności wymagające przeciągania można wykonać za pomocą jednego wskaźnika | Uchwyty do zmiany rozmiaru w widżetach czatu muszą mieć opcję alternatywną, niezależną od przeciągania | Rozmiar widżetu można zmieniać wyłącznie poprzez przeciągnięcie |
| 3.2.6 Spójna pomoc | AA | Mechanizmy pomocy są rozmieszczone w tej samej kolejności na każdej stronie | Ikona uruchamiająca czat musi wyświetlać się w tym samym miejscu na całej witrynie | Widżet przechodzi między stronami |
| 3.3.7 Zbędny wpis | AA | Dane wprowadzone podczas tej samej sesji są automatycznie uzupełniane lub można je wybrać | Chatbot nie powinien prosić użytkowników o ponowne wprowadzanie informacji podanych wcześniej w tej samej sesji | Proszenie o podanie adresu e-mail, mimo że użytkownik już go podał |
| 3.3.8 Uwierzytelnianie dostępne (wymagania minimalne) | AA | Etapy uwierzytelniania nie opierają się wyłącznie na testach funkcji poznawczych | Jeśli chatbot wywołuje proces logowania, CAPTCHA musi mieć dostępną alternatywę | CAPTCHA wyłącznie wizualna, bez alternatywnego rozwiązania |
Siedem najczęstszych przeszkód w dostępności chatbotów
W ramach naszych działań związanych z audytowaniem wdrożeń chatbotów u klientów z branży usług finansowych, handlu detalicznego, opieki zdrowotnej oraz sektora publicznego zidentyfikowaliśmy powtarzające się schematy niepowodzeń. Nie są to rzadkie, skrajne przypadki — pojawiają się one zarówno we wdrożeniach produkcyjnych dużych dostawców, jak i w rozwiązaniach tworzonych na zamówienie.
1. Brakujące regiony aktywne ARIA
Kiedy bot udziela odpowiedzi, użytkownicy czytników ekranu tego nie słyszą, ponieważ nowe wiadomości są wstawiane do modelu DOM bez wywoływania komunikatu głosowego.
- Dotyczy: użytkowników czytników ekranu (NVDA, JAWS, VoiceOver)
- Częstotliwość: bardzo często — stwierdzane w około 70% kontroli
- Rozwiązanie:
aria-live="polite"w kontenerze wiadomości
2. Pułapki związane z klawiaturą
Użytkownicy korzystający z nawigacji za pomocą klawiatury utknęli w okienku czatu i nie mogą przejść do pozostałej części strony za pomocą klawisza Tab bez zamknięcia karty przeglądarki.
- Dotyczy: osób korzystających wyłącznie z klawiatury, osób z niepełnosprawnością ruchową
- Częstotliwość: często — wywoływane przez nakładki modalne
- Rozwiązanie: Klawisz Escape powoduje zamknięcie okna; fokus powraca do elementu wyzwalającego
3. Niewystarczający kontrast kolorów
Dymki wiadomości wysyłanych przez boty nie spełniają wymogu proporcji 4,5:1 obowiązującego dla zwykłego tekstu, przez co są nieczytelne dla użytkowników ze słabym wzrokiem lub w jasnym oświetleniu otoczenia.
- Dotyczy: słabego wzroku, ślepoty barw (ok. 8% mężczyzn)
- Częstotliwość występowania: niezwykle powszechne — motywy kosmetyczne rzadko są przedmiotem badań
- Rozwiązanie: Sprawdź wszystkie pary kolorów za pomocą urządzenia do pomiaru kontrastu
4. Elementy formularza bez etykiet
Pola wprowadzania tekstu i przyciski wysyłania nie mają etykiet programowych (<label> lub aria-label), więc czytniki ekranu odczytują je jako „edytuj tekst” bez podania kontekstu.
- Dotyczy: użytkowników czytników ekranu
- Częstotliwość występowania: bardzo często spotykane w komputerach budowanych na zamówienie
- Rozwiązanie: Każde pole wprowadzania danych i każdy przycisk muszą mieć opisową etykietę
5. Złożony język
Odpowiedzi botów zawierają żargon, długie zdania i konstrukcje bierne, co może stanowić trudność dla użytkowników o odmiennych zdolnościach poznawczych, niskim poziomie umiejętności czytania i pisania lub tych, którzy czytają w języku obcym.
- Dotyczy: osób z zaburzeniami funkcji poznawczych, osób z dysleksją, osób uczących się języków
- Częstotliwość: niezwykle powszechne w botach tworzonych przez przedsiębiorstwa
- Rozwiązanie: W przypadku botów konsumenckich należy dążyć do osiągnięcia wyniku w skali Flescha–Kincaida na poziomie 8 klasy lub niższym
6. Brak ostrzeżenia o wygaśnięciu sesji
Sesje wygasają bez ostrzeżenia, co powoduje, że użytkownicy piszący wolno (z powodu zaburzeń motorycznych lub poznawczych) tracą swoje postępy. WCAG 2.1.4 wymaga ostrzeżenia z co najmniej 20-sekundowym wyprzedzeniem przed wygaśnięciem sesji.
- Dotyczy: zaburzeń motorycznych, niepełnosprawności intelektualnej
- Częstotliwość: często spotykane w sesjach czatu wymagających uwierzytelnienia
- Poprawka: ostrzegawcze okno modalne dostosowane do potrzeb osób niepełnosprawnych; opcja przedłużenia
7. Błędy związane z celami dotykowymi
W aplikacji mobilnej przyciski funkcyjne (wyślij, sugerowane odpowiedzi, zamknij) mają rozmiar mniejszy niż 24×24 piksele, co utrudnia ich pewne użycie użytkownikom cierpiącym na drżenie rąk lub mającym ograniczoną zdolność motoryczną.
- Dotyczy: zaburzeń motorycznych, osób starszych
- Częstotliwość: bardzo często spotykane w rozwiązaniach zaprojektowanych z myślą o urządzeniach mobilnych
- Poprawka: Minimalny rozmiar elementów dotykowych to 44×44 pikseli (WCAG AAA: minimum 24 pikseli dla poziomu AA)
Częstość występowania barier w audytach firmowych chatbotów
Na podstawie zbiorczych wyników audytów dostępności przeprowadzonych przez AIOPSGROUP w ponad 40 wdrożeniach chatbotów w przedsiębiorstwach (2023–2024). Liczby te odnoszą się do dedykowanych interfejsów chatbotów, a nie do szeroko pojętej sieci; dla kontekstu, audyt WebAIM z 2024 r. obejmujący 1 milion najpopularniejszych stron głównych wykazał niezgodność z WCAG w 95,9% przypadków — liczba ta dotyczy głównie starszych i nieaktualizowanych witryn i nie powinna być traktowana jako reprezentatywna dla nowoczesnych narzędzi chatbotów korporacyjnych.
-
Brakujące lub uszkodzone regiony ARIA 71%
-
Niewystarczający kontrast kolorów w dymkach czatu 68%
-
Trudny język (poziom czytania powyżej 10 klasy) 65%
-
Pola bez etykiet / przyciski z samą ikoną 58%
-
Błędy związane z rozmiarem elementów dotykowych na urządzeniach mobilnych 54%
-
Funkcja automatycznego wypełniania przy otwieraniu/zamykaniu okienka 47%
-
Brak ostrzeżenia o wygaśnięciu sesji 39%
Wdrożenie: praktyczne ramy
Dostępności nie da się zapewnić poprzez audyt po uruchomieniu systemu. Należy ją zaprojektować i wdrożyć od samego początku. Poniższy model — stosowany przez AIOPSGROUP w korporacyjnych programach chatbotów — porządkuje działania związane z dostępnością w czterech obszarach, w których najczęściej dochodzi do nieprawidłowości: struktura, interakcja, treść i operacje.
Poziom 1: Wymagania konstrukcyjne i techniczne
Są to podstawowe, niepodlegające negocjacjom wymagania techniczne, za które odpowiada zespół inżynierów. Większość z nich można zweryfikować za pomocą narzędzi automatycznych, takich jak axe, Lighthouse czy IBM Equal Access Checker, choć automatyzacja pozwala wykryć jedynie około 30–40% wszystkich problemów związanych z WCAG — zawsze konieczne jest przeprowadzenie testów przez ludzi.
Poziom 2: Projektowanie interakcji
Projektowanie interakcji stanowi punkt styku dostępności i użyteczności. Przedstawione poniżej wzorce dotyczą sposobu, w jaki użytkownicy poruszają się po rozmowie, reakcji interfejsu na wprowadzane dane oraz sposobu zgłaszania błędów.
Stopniowe ujawnianie informacji
Przedstawiaj informacje w przystępnych porcjach. Długie odpowiedzi należy podzielić na kilka części lub dodać opcję „czytaj więcej” z łatwymi w obsłudze przyciskami do rozwijania i zwijania treści.
- Use
aria-expandedon toggle controls - Announce expanded content via live region
- Ensure collapsed state doesn’t hide critical info
Odzyskiwanie po awarii
Gdy bot nie zrozumie pytania, powinien zaproponować konkretne sposoby rozwiązania problemu, a nie tylko odpowiedzieć: „Nie zrozumiałem”. Należy opisać, w czym może pomóc, i zaproponować alternatywne rozwiązania.
- Never dead-end a conversation
- Offer human escalation with accessible controls
- Keep error messages under two sentences
Nawigacja w rozmowie
Użytkownicy z zaburzeniami funkcji poznawczych czerpią korzyści z jasnych wskazówek dotyczących tego, na którym etapie wieloetapowego procesu się znajdują. Wskaźniki postępu muszą być przekazywane do technologii wspomagających.
- Use
aria-label="Step 2 of 4"on progress - Allow easy navigation to previous steps
- Summarise collected info before final submission
Wprowadzanie danych z wielu źródeł
Obsługuj różne metody wprowadzania danych: pisanie, wprowadzanie głosowe (z wykorzystaniem interfejsów API przeglądarki do obsługi mowy), sugerowane odpowiedzi oraz formularze strukturalne. Nigdy nie wymagaj stosowania metody, która wyklucza jakąkolwiek grupę użytkowników.
- Test voice input with real users
- Provide text transcript of any voice response
- Ensure suggested replies are scrollable on mobile
Warstwa 3: Treść i język
Najskuteczniejszym i najtańszym sposobem poprawy dostępności, dostępnym dla większości przedsiębiorstw, jest poprawa jakości językowej odpowiedzi chatbotów. Jasny, prosty język zmniejsza obciążenie poznawcze wszystkich użytkowników – a także znacznie ułatwia zrozumienie treści osobom z niepełnosprawnością poznawczą, o niskim poziomie umiejętności czytania i pisania lub posługującym się językiem obcym.
Common mistake
Organizacje poświęcają miesiące na opracowanie warstwy interakcji, a tworzenie treści pozostawiają zespołowi, który akurat jest dostępny w momencie uruchomienia serwisu. Efekt: technicznie zgodna struktura otaczająca treści niedostępne pod względem poznawczym. Traktuj jakość treści jako priorytetowy wymóg dostępności, wyposażony we własną listę kontrolną do weryfikacji oraz zatwierdzenie przez ekspertów.
| Kontekst | Brak odpowiedzi | Odpowiedź dostosowana do potrzeb osób niepełnosprawnych | Poprawa |
|---|---|---|---|
| Sprawdzenie salda konta | „Potwierdzenie wypłaty wynagrodzenia jest obecnie w trakcie przetwarzania w ramach naszego procesu uzgadniania rozliczeń finansowych”. | „Twoja płatność jest obecnie przetwarzana. Powinna zostać zaksięgowana w ciągu 2 dni roboczych.” | Klasa 14 → Klasa 5 |
| Komunikat o błędzie | „Wystąpił nieokreślony błąd. Spróbuj ponownie.” | „Nie udało się wysłać wiadomości. Sprawdź połączenie internetowe, a następnie naciśnij przycisk „Wyślij” ponownie.” | Praktyczne + konkretne |
| Potwierdzenie formularza | „Twoje zgłoszenie zostało pomyślnie otrzymane i zostanie rozpatrzone zgodnie z naszymi standardowymi procedurami”. | „Rozumiemy! Otrzymaliśmy Twoją wiadomość. Odpowiemy na nią e-mailem w ciągu 24 godzin.” | Klasa 16 → Klasa 4 |
| Przekazanie do agenta | „Ze względu na złożony charakter Twojego zapytania zalecamy skontaktowanie się z konsultantem na czacie na żywo”. | „Skontaktuję cię z osobą, która może ci pomóc. Zwykle zajmuje to dwie minuty.” | Określa oczekiwania; forma czynna |
| Odpowiedź wykraczająca poza zakres | „Obawiam się, że wykracza to poza zakres moich wyznaczonych funkcji”. | „W tej sprawie nie mogę pomóc, ale mogę pomóc w sprawie [temat A], [temat B] lub [temat C]. W czym mogę pomóc?” | Oferuje alternatywne rozwiązania; nie prowadzi w ślepą uliczkę |
Kalkulator zwrotu z inwestycji: Koszt braku dostępności
Inwestycje w dostępność są często kwestionowane ze względów finansowych. Poniższy kalkulator pozwala oszacować łączne koszty wynikające z braku dostępności — w tym utracone konwersje spowodowane wykluczeniem użytkowników, ryzyko prawne oraz eskalacje zgłoszeń do pomocy technicznej — a także szacowany zwrot z wprowadzonych zmian.
Wprowadź dane dotyczące wdrożenia, aby oszacować wpływ projektowania chatbotów dostosowanych do potrzeb osób niepełnosprawnych na działalność firmy.
Metodologia i założenia
Kalkulator ten stosuje ostrożny wskaźnik wykluczenia oparty na podawanej przez WHO globalnej częstości występowania niepełnosprawności wynoszącej 16% — przy czym należy pamiętać, że nie wszystkie rodzaje niepełnosprawności w równym stopniu wpływają na korzystanie z chatbotów, więc rzeczywisty wpływ będzie się znacznie różnił w zależności od kontekstu wdrożenia. Mnożnik ryzyka prawnego dla danej branży (wahający się od 1,1× dla branży turystycznej do 1,8× dla opieki zdrowotnej) odzwierciedla względną historyczną częstotliwość egzekwowania przepisów; są to szacunki orientacyjne, a nie wyceny aktuarialne. Wzrost eskalacji zakłada o 30% wyższy wskaźnik dla użytkowników napotykających bariery dostępu, w oparciu o benchmarki klientów AIOPSGROUP. Wszystkie dane są szacunkami na potrzeby planowania. Formalny audyt dostępności i program badań użytkowników dostarczą bardziej precyzyjnych danych dotyczących konkretnego wdrożenia i bazy użytkowników.
Praktyczne przykłady: dostępność w praktyce
Abstrakcyjne zasady nabierają konkretnego kształtu, gdy przyglądamy się im przez pryzmat rzeczywistych doświadczeń użytkowników. Poniższe scenariusze pokazują, jak niedociągnięcia i sukcesy w zakresie dostępności przejawiają się w rzeczywistych interakcjach z chatbotami w typowych sytuacjach biznesowych.
Bankowość | Użytkownicy czytników ekranu
Maria, 34 lata — niewidoma, korzysta z programu JAWS i przeglądarki Chrome
Maria chce sprawdzić, czy jej nadpłata kredytu hipotecznego została zaksięgowana. Otwiera chatbota banku. Wpisuje swoje zapytanie. Nic się nie dzieje — nie otrzymuje żadnej odpowiedzi, ponieważ w kontenerze wiadomości brakuje regionu ARIA live.
Po 30 sekundach naciska klawisz Tab, odkrywa, że utknęła w pętli klawiszowej, i musi całkowicie zamknąć kartę przeglądarki. Zamiast tego dzwoni na infolinię.
Wynik: Chatbot całkowicie zawodzi. Konieczne jest przekierowanie sprawy do obsługi telefonicznej, co wiąże się z kosztem około 12 euro. Znacznie obniża to poziom zadowolenia klienta.
Handel detaliczny | Dostępność kognitywna
, 52 — Uraz mózgu, trudności w przetwarzaniu informacji
James chce zwrócić wadliwy produkt. Chatbot posługuje się językiem technicznym („proszę podać numer referencyjny zamówienia związanego z ostatnią transakcją”) i po 3 minutach sesja wygasa bez ostrzeżenia.
Musi przeczytać każdą wiadomość kilka razy. Sesja wygasa, zanim zdąży zakończyć wysyłanie odpowiedzi. W końcu całkowicie rezygnuje z tej czynności.
Wynik: Problem z procesem zwrotu nie został rozwiązany. Duża frustracja. Prawdopodobna utrata lojalności wobec marki — szacowana strata wartości klienta na całym okresie współpracy wynosząca ponad 600 euro.
Opieka zdrowotna | Projektowanie sprzyjające dostępności ✓
Priya, 28 lat — niepełnosprawność ruchowa, korzysta z obsługi za pomocą przełącznika
Priya porusza się po stronie za pomocą urządzenia skanującego z jednym przełącznikiem. Niedawno przeprojektowany chatbot szpitala został stworzony zgodnie z wytycznymi WCAG 2.2 AA. Wszystkie elementy mają obszary docelowe o rozmiarze co najmniej 44 pikseli, są w pełni obsługiwane za pomocą klawiatury i mają logiczną kolejność fokusowania.
Umówiła się na wizytę ambulatoryjną, korzystając z gotowych szablonów odpowiedzi, które doskonale współpracują z interfejsem przełącznikowym. Cała procedura zajęła 4 minuty — tyle samo, ile zajęłoby to użytkownikowi bez niepełnosprawności.
Wynik: Płynna i profesjonalna obsługa w trybie samoobsługowym. Brak konieczności eskalacji sprawy. Pacjent wyraził najwyższy możliwy poziom zadowolenia.
HR | Projektowanie sprzyjające dostępności ✓
Riku, 46 lat — jest osobą niesłyszącą, woli komunikację tekstową; podczas rozmów telefonicznych korzysta z pomocy tłumacza języka migowego
Riku musi sprawdzić zasady dotyczące urlopów obowiązujące w jego firmie. Chatbot działu kadr działa w trybie tekstowym, obsługuje się go za pomocą klawiatury i nie zawiera żadnych elementów wyłącznie audio. Poziom trudności odpowiedzi odpowiada 7. klasie szkoły podstawowej. Linki do szczegółowych informacji na temat zasad prowadzą do dokumentów PDF w formacie dostosowanym do potrzeb osób niepełnosprawnych.
Kończy sprawdzanie w ciągu 3 minut bez konieczności angażowania pracownika. Jeśli w treści pojawiają się osadzone pliki wideo, dostępne są do nich napisy.
Wynik: Zadanie wykonane w całości. Dla Riku chatbot tekstowy jest bardziej dostępny niż obsługa telefoniczna — preferowanym kanałem komunikacji jest samoobsługa.
Porównanie platform chatbotów: funkcje ułatwień dostępu
Nie wszystkie platformy chatbotów zapewniają taki sam poziom dostępności. Poniżej przedstawiono ogólną ocenę głównych platform pod kątem kluczowych aspektów dostępności. Należy pamiętać, że możliwości platformy stanowią jedynie górną granicę, a nie gwarancję — o tym, czy rozwiązanie będzie rzeczywiście dostępne, decyduje ostatecznie jakość wdrożenia.
| Typ platformy | Pomoc techniczna ARIA | Nawigacja za pomocą klawiatury | Sprawdzono pod kątem zgodności z czytnikami ekranu | Dokumentacja WCAG 2.2 | Niestandardowe haki ARIA | Ogólnie rzecz biorąc |
|---|---|---|---|---|---|---|
| Systemy dostosowane do potrzeb przedsiębiorstw (SAP, Salesforce) | Dobrze | Dobrze | Udokumentowane | Dostępne | Ograniczona | Silny |
| Platformy typu low-code / no-code | Częściowy | Częściowy | Zmienna | Minimalny | Brak | Umiarkowany |
| Oprogramowanie open source / Konfiguracja niestandardowa | Pełna kontrola | Pełna kontrola | Zależne od zespołu | nie dotyczy | Pełna | Największy potencjał |
| Wbudowani asystenci oparci na modelach językowych (LLM) | Częściowy | Częściowy | Rzadko testowane | Nieobecny | Ograniczona | Powstające |
| Asystenci głosowi | Nie dotyczy | Nie dotyczy | Rodzimy | Zmienna | nie dotyczy | Dobre rozwiązanie dla osób z wadami wzroku; słabe dla użytkowników niesłyszących |
Best practice
Oceniając platformy, poproś o udostępnienie dokumentu VPAT (Voluntary Product Accessibility Template) lub raportu zgodności z wymogami dostępności (ACR) zgodnego z wytycznymi WCAG 2.2 / normą EN 301 549. Dostawca, który nie jest w stanie dostarczyć tej dokumentacji, nie może wiarygodnie twierdzić, że spełnia wymogi dostępności. Traktuj dokument VPAT jako punkt wyjścia, a nie gwarancję — zawsze przeprowadzaj własne testy.
Stopień dojrzałości w zakresie dostępności: czterostopniowy plan działania
Zapewnienie i utrzymanie dostępności chatbotów to proces ciągły, a nie jednorazowe przedsięwzięcie. Przedstawiony poniżej model dojrzałości opisuje przejście od reaktywnego dostosowywania się do przepisów do proaktywnego, zorientowanego na użytkownika przywództwa w zakresie dostępności.
Etap 1
Reaktywny
Rozwiązywanie problemów wyłącznie w przypadku zgłoszenia skargi lub wszczęcia postępowania sądowego. Brak proaktywnych testów. Brak uwzględnienia kwestii dostępności w kryteriach zamówień publicznych.
Etap 2
Zgodny
Osiągnięto poziom zgodności z wytycznymi WCAG 2.2 AA. Przeprowadzane są coroczne audyty. Dostępność uwzględniono w kryteriach odbioru. Przy zamówieniach sprawdzane są raporty VPAT.
Etap 3
Wbudowane
Dostępność jest integralną częścią systemu projektowego i biblioteki komponentów. Każdy sprint obejmuje przegląd pod kątem dostępności. W skład panelów badawczych wchodzą osoby niepełnosprawne.
Etap 4
Wiodący
Dostępność stanowi czynnik wyróżniający na tle konkurencji. Współpraca projektowa ze społecznościami osób niepełnosprawnych. Proaktywne przygotowanie do standardu WCAG 3.0. Publiczne oświadczenie dotyczące dostępności oraz plan działania.
Przejście z etapu 1 do etapu 2: 90-dniowy sprint
W przypadku organizacji znajdujących się obecnie na etapie reaktywnym, dzięki ukierunkowanemu 90-dniowemu sprintowi można osiągnąć zgodność z podstawowymi wymaganiami WCAG 2.2 AA w odniesieniu do istniejącej implementacji chatbota. W poniższej tabeli przedstawiono działania o największym znaczeniu w podziale na etapy.
| Faza | Tygodnie | Główne działania | Właściciel | Wskaźnik sukcesu |
|---|---|---|---|---|
| Sprawdź i ustal priorytety | 1–3 | Automatyczne skanowanie (Axe/Lighthouse), ręczna weryfikacja przez ekspertów, testy użytkowników z udziałem 3–5 osób niepełnosprawnych, klasyfikacja problemów według stopnia ważności | Specjalista ds. dostępności + kierownik zespołu programistów | Rejestr problemów uszeregowanych według priorytetów wraz z przyporządkowanymi do każdego z nich kryteriami WCAG |
| Najważniejsze poprawki | 4–6 | Należy usunąć wszystkie błędy poziomu A; poprawić aktywne obszary ARIA; dodać brakujące etykiety; wyeliminować pułapki klawiaturowe; usunąć błędy związane z kontrastem | Zespół inżynierów | Brak błędów na poziomie zerowym; czytnik ekranu może wykonać podstawowe sekwencje czynności |
| Ukończenie programu AA | 7–10 | Wdrożenie wymagań WCAG 2.2 poziomu AA; dostosowanie treści do prostego języka; wdrożenie ostrzeżeń o wygaśnięciu sesji; zapewnienie współczynnika kontrastu 4,5:1 w całym serwisie | Zespół ds. inżynierii i treści | Wskaźnik zgodności z wytycznymi WCAG 2.2 AA wynoszący co najmniej 95% w wyniku automatycznego skanowania; zatwierdzenie przez eksperta |
| Sprawdź poprawność i udokumentuj | 11–13 | Przeprowadź ponowne testy z udziałem użytkowników niepełnosprawnych; opublikuj raporty VPAT/ACR; wdroż system bieżącego monitorowania; przeszkol zespół; ustal kryteria akceptacji w zakresie dostępności | Kontrola jakości + Produkt + Dział prawny | Opublikowano ACR; kwestie dostępności uwzględniono w definicji zakończenia zadania; panel monitorowania działa |
Szacunkowy stosunek kosztów dostosowania istniejącego chatbota do wymogów dostępności w porównaniu z wbudowaniem tych funkcji od samego początku. Każda decyzja dotycząca dostępności podjęta na etapie projektowania kosztuje około jednej jednostki nakładu pracy; ta sama decyzja podjęta po uruchomieniu serwisu kosztuje czterdzieści.
Strategia testowania: więcej niż tylko automatyczne skanowanie
Narzędzia do automatycznego testowania dostępności — axe, Lighthouse, IBM Equal Access Checker, Deque WorldSpace — są cennymi narzędziami do wstępnej oceny, ale wykrywają jedynie 30–40% problemów związanych z WCAG. Skuteczna strategia testowania chatbotów łączy w sobie cztery uzupełniające się metody.
Testowanie automatyczne
Szybkie, skalowalne, zintegrowane z CI/CD. Niezawodnie wykrywa błędy strukturalne. Najlepsze rozwiązanie do zapobiegania regresji.
- Zakres: ~30–40% problemów związanych z WCAG
- Narzędzia: axe-core, Playwright + axe, Lighthouse CI
- Uruchamianie: przy każdej kompilacji w potoku CI
- Najlepsze zastosowanie: kontrast, etykiety, struktura ARIA
Profesjonalna weryfikacja ręczna
Szczegółowa prezentacja przeprowadzona przez specjalistę ds. dostępności: najpierw wyłącznie za pomocą klawiatury, następnie z wykorzystaniem czytnika ekranu, a na koniec przy powiększeniu 200% i 400%.
- Zakres: ~70–80% problemów związanych z WCAG
- Narzędzia: NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari
- Częstotliwość aktualizacji: główne wersje; co kwartał w przypadku botów działających na żywo
- Najlepiej sprawdza się w: schematach interakcji, zarządzaniu zadaniami
Testy użytkowników z udziałem osób niepełnosprawnych
Sesje jakościowe z udziałem prawdziwych użytkowników z niepełnosprawnościami. Pozwalają one zidentyfikować przeszkody w obsłudze, które całkowicie umykają uwadze podczas testów technicznych.
- Zakres: Żadne narzędzie nie pozwala przewidzieć powstawania barier powierzchniowych
- Rekrutacja za pośrednictwem: organizacji osób niepełnosprawnych, wyspecjalizowanych agencji
- Przeprowadzane przy: gruntownych zmianach konstrukcyjnych; co roku w fazie produkcji
- Najlepsze w zakresie: obciążenia poznawczego, przejrzystości językowej, płynności w rzeczywistych sytuacjach
Analizy i monitorowanie
Wskaźniki ilościowe na podstawie danych operacyjnych: tempo wzrostu, odsetek porzuconych sesji w podziale na typy urządzeń, wskaźnik zakończonych rozmów na czacie, częstotliwość występowania błędów.
- Zakres: Ujawnia ogólne prawidłowości w szerokiej perspektywie
- Narzędzia: Niestandardowe narzędzia analityczne, narzędzia do rejestrowania sesji
- Czas trwania: w trybie ciągłym; przegląd co miesiąc
- Najlepiej nadaje się do: określenia, które przepływy mają największy wpływ na bariery
Wniosek: Obietnica dostępnej sztucznej inteligencji konwersacyjnej
Krzywa dostępności cyfrowej powoli, ale wyraźnie zmierza w kierunku integracji. W ciągu ostatniej dekady każda z głównych platform technologicznych poprawiła swoje rozwiązania w zakresie dostępności. Przepisy prawne są rozszerzane, a nie ograniczane. Oczekiwania użytkowników rosną. A argumenty biznesowe – niegdyś kwestionowane – znajdują obecnie solidne potwierdzenie w wielu branżach i regionach.
Chatboty znajdują się na wyjątkowym skrzyżowaniu dróg: dla większości użytkowników są one wizytówką sztucznej inteligencji, obsługując codziennie miliony interakcji w świecie rzeczywistym. Mogą one albo pogłębiać wykluczenie, które charakteryzowało znaczną część historii internetu, albo stać się wzorem tego, jak wygląda i działa prawdziwie inkluzywna sztuczna inteligencja. Złożoność techniczna wymagana do zapewnienia dostępności chatbota nie jest przeszkodą nie do pokonania. Kryteria WCAG są jasno określone. Wzorce działania są udokumentowane. Narzędzia są dostępne.
W większości organizacji brakuje dotychczas instytucjonalnej woli, by traktować dostępność jako priorytetowy wymóg inżynieryjny i projektowy – nie jako punkt na liście kontrolnej po uruchomieniu produktu, nie jako pozycję do odhaczenia w celu zapewnienia zgodności z przepisami, ale jako prawdziwe zobowiązanie do obsługi pełnego spektrum użytkowników. AIOPSGROUP współpracuje z przedsiębiorstwami, aby wbudować to zobowiązanie w ich programy dotyczące konwersacyjnej sztucznej inteligencji już od pierwszego sprintu projektowego.
W końcu chatbot, który sprawdza się w przypadku każdego, jest po prostu lepszym chatbotem.
Next steps with AIOPSGROUP
Chcesz poddać swój chatbot audytowi zgodności z wytycznymi WCAG 2.2 AA lub wdrożyć rozwiązania zapewniające dostępność w nowym projekcie od samego początku? Nasz zespół ds. konwersacyjnej sztucznej inteligencji w AIOPSGROUP, spółce należącej do valantic, oferuje audyty dostępności, sprinty naprawcze oraz zarządzanie programami wdrażania dostępności. Skontaktuj się z nami na stronie aiopsgroup.com.