Okiem niewidomego. Czytnik ekranu to nie konsola debuggera

Najdziwniejszymi problemami związanymi z dostępnością cyfrową, jakie coraz częściej widzę we współczesnych aplikacjach, nie są brakujące etykiety, popsute nagłówki ani nawet pułapki klawiaturowe.

Problem dotyczy samej komunikacji. A dokładniej: sposobu, w jaki programiści myślą o komunikatach czytnika ekranu. Mam wrażenie, że w końcu zrozumiałam, skąd częściowo bierze się ten problem.

 Okna podglądu mowy – pomocne narzędzie?

Wiele czytników ekranu posiada okna podglądu mowy. To bardzo przydatne narzędzia. Pozwalają osobom widzącym — programistom, testerom, pracownikom wsparcia technicznego czy infolinii produktowej — zrozumieć, co komunikuje czytnik ekranu. Pomagają też podczas zdalnego wspierania niewidomych użytkowników czy odtwarzania trudnych błędów.

Dla niewtajemniczonych wyjaśniam: okna podglądu mowy to takie małe panele, które zazwyczaj unoszą się u dołu ekranu ponad innymi oknami. Gdy tylko czytnik ekranu coś ogłasza, informacja ta jest pokazana na podobnej zasadzie jak napisy w filmie, ale w dedykowanym miejscu. Podobnie jak napisy, można zmieniać ustawienia takie jak kolor czcionki i jej wielkość. W niektórych czytnikach ekranu można przewinąć kilka komunikatów wstecz. W innych zaś widoczna jest tylko ogłaszana w danym momencie treść, i to też często nie w całości. Bo tak jak napisy w filmie, przewija się wraz ze słyszalnym tekstem.

Tyle że wizualnie te okna wyglądają niemal dokładnie jak coś innego: logi konsoli. I mam wrażenie, że to podobieństwo po cichu wpływa na sposób myślenia o dostępności. Bo kiedy komunikaty czytnika zaczynają wyglądać jak tekst w konsoli z błędami lub statusami, dostępność zaczyna być traktowana jak system emitowania zdarzeń.

• Stan się zmienił? Ogłośmy to.
• Walidacja się nie powiodła? Trzeba to ogłosić.
• Sekcja się zaktualizowała? No jasne że ogłaszamy.
• Pojawiły się trzy błędy? Wystrzelmy trzy alerty.
• Pojawiło się pięć błędów? No przecież pięć `role="alert"` też da się zrobić.
• Ładowanie zakończone? Ogłośmy sukces.
• Coś się odświeżyło ponownie? Ogłośmy to jeszcze raz, a co.

Technicznie informacja w większości przypadków rzeczywiście zaistnieje. No może poza tymi pięcioma `role="alert"`, które prawdopodobnie nie odpalą.

Tyle że ludzka komunikacja nie jest strumieniem telemetrycznym. Konsola może wygenerować setki linii na sekundę. I wasz agent AI może się w tym odnajdzie, chociaż pewnie i dla niego będzie to zbyt dużo informacji na raz. Człowiek natomiast z pewnością nie.

Mowa jest sekwencyjna. Czasowa. Przerywalna. Delikatna. Gdy zostanie przerwana, część kontekstu może po prostu zniknąć. Niewidomy użytkownik nie „parsuje eventów”. Słucha. A słuchanie ma koszt poznawczy.

Formularze ujawniają to najlepiej

Najbardziej odczuwalne jest to niestety podczas pracy z formularzami. Wyobraźcie sobie taki scenariusz: użytkownik wysyła formularz. I nagle:

• fokus się przemieszcza,
• strona przewija się,
• pojawia się podsumowanie błędów,
• w kilku miejscach `role=”alert”` odpala się jednocześnie,
• pojawiają się komunikaty błędów,
• aria-describedby się zmienia,
• przyciski się odświeżają,
• sekcje się rozwijają.

Wizualnie wszystko może wyglądać na perfekcyjnie dostępne. Ale rzeczywiste doświadczenie z czytnikiem ekranu zaczyna przypominać chaos:

• przerywane komunikaty,
• znikające alerty,
• duplikaty,
• urwane zdania,
• niestabilny fokus,
• albo całkowitą utratę orientacji.

Czasem odczyta się tylko pierwszy błąd, czasem tylko ostatni, a czasem w ogóle nic. Czasem czytnik zaczyna mówić jedno, podczas gdy fokus jest już gdzie indziej. I w ogóle to najlepiej przejść formularz od nowa, bo inaczej z pewnością coś przegapię.

A programista patrzy na podgląd mowy i myśli: „Przecież wszystko się poprawnie odpaliło.”

Tyle że dostępność nie polega na tym, czy wszystkie zdarzenia lub alerty odpaliły. Pytanie brzmi raczej: czy człowiek zrozumiał, co właśnie się wydarzyło? To ogromna różnica.

Programiści nie są źli

Co ciekawe, większość takich systemów powstaje w dobrej wierze. Programiści chcą poinformować użytkownika, że coś się zmieniło. Więc dodają kolejne komunikaty. I kolejne. Aż interfejs zaczyna bardziej przypominać nawałnicę powiadomień niż komunikację.

A efekt? No cóż, często jest dokładnie odwrotny od zamierzonego. Nie ze złej woli, tylko z konsoli, dosłownie.

Jako zaawansowana użytkowniczka i osoba niewidoma rzadko potrzebuję ogromnej ilości komunikatów. Nawet początkujący użytkownicy czytnika ekranu mogą być nimi przytłoczeni. Warto więc dostarczać komunikaty stabilne. Przewidywalne. Takie, z których da się odzyskać kontekst. Dobrze zaprojektowane komunikaty i interfejsy to takie, w których zespoły wytwórcze rozumieją, że ilość informacji audio, które mózg ludzki jest w stanie przetworzyć, jest ograniczona.

Nasi kursanci (osoby widzące), gdy uczą się korzystania z czytnika, często wspominają o bólach głowy lub ogromnym zmęczeniu już po krótkim czasie słuchania rzeczy ogłaszanych mową syntetyczną. Prawdą jest też, że posługiwanie się czytnikiem na co dzień wymaga wprawy, czasu i wyrobienia nawyków. Skoro jednak już po kilku lub kilkunastu minutach u kursantów następuje zmęczenie poznawcze, dlaczego zespoły wytwórcze zakładają, że u niewidomych użytkowników ono nie występuje?

Alternatywa

Czasem najlepszą decyzją dostępnościową nie jest: „ogłośmy wszystko”. Dużo częściej znacznie lepszym wyborem jest:

• mniej komunikatów,
• lepsza struktura,
• czytelniejsza nawigacja,
• stabilny fokus,
• oraz trwałe informacje, do których można wrócić świadomie.

Czytnik ekranu nie jest debuggerem (narzędziem do sprawdzania poprawności kodu). A niewidomy użytkownik nie śledzi logów w terminalu.

Dostępność to komunikacja. A komunikacja rozpada się zaskakująco szybko, gdy zapominamy, że po drugiej stronie znajduje się prawdziwy ludzki układ nerwowy.

Co więc z podglądem mowy?

Okna podglądu mowy to bardzo przydatne narzędzia. Wspierają komunikację i ułatwiają rozwiązywanie problemów na linii użytkownik czytnika ekranu – osoba widząca. Gdy jednak zaczniemy je traktować jak okna podglądu konsoli, efekty stają się opłakane.