Synteza mowy a czytniki ekranu

Twoje treści mają głos

Technologia syntezy mowy (TTS) przekształca informacje pisane w dźwięk. Pomaga osobom niewidomym, z wadami wzroku, dysleksją i ADHD przyswajać treści w sposób, który im odpowiada. TTS jest też szeroko stosowana w szkołach, przez osoby uczące się języków oraz przez profesjonalistów, którzy korygują tekst słuchem, a nie wzrokiem.

Ponieważ zarówno TTS, jak i czytniki ekranu generują syntetyczny głos, ludzie często zakładają, że to to samo — albo że dodanie do witryny przycisku „czytaj na głos” czyni ją dostępną dla użytkowników niewidomych. To założenie jest błędne, a działanie zgodnie z nim może zostawić Cię z witryną, która brzmi na dostępną, ale której wiele osób w rzeczywistości nie jest w stanie używać. Ten artykuł wyjaśnia, jak działa każda z technologii, kto na niej polega, gdzie naprawdę przebiega granica między nimi oraz czego potrzeba, aby poprawnie tworzyć z myślą o czytnikach ekranu. Jeśli masz zapamiętać tylko jedno, niech to będzie to: widżet czytania na głos to funkcja wygody, a nie funkcja dostępności.

Jak działa TTS?

TTS przetwarza tekst w trzech ogólnych etapach:

Analiza tekstu — określanie tonu, gramatyki i struktury, rozwijanie liczb i symboli („5 $” staje się „pięć dolarów”) oraz dzielenie zdań.
Przetwarzanie językowe — obliczanie wymowy, akcentu i emfazy, często z użyciem słownika wymowy oraz reguł dla nieznanych słów.
Synteza dźwięku — generowanie mowy na podstawie matematycznych modeli głosu, coraz częściej z wykorzystaniem sieci neuronowych, które brzmią znacznie bardziej naturalnie niż starsze silniki konkatenacyjne.

Nowoczesne systemy oferują dostosowanie głosu, takie jak szybkość, wysokość tonu, persona głosu i wybór języka. Kluczowe jest to, co TTS przyjmuje jako dane wejściowe: blok tekstu, który ktoś już zaznaczył, wkleił lub na który wskazał. TTS jest w istocie technologią wyprowadzania treści. Wypowiada to, co zostanie jej podane. Nie eksploruje interfejsu i nie ma pojęcia o przyciskach, polach formularzy ani strukturze strony.

Jakie są ograniczenia technologii TTS?

TTS jest naprawdę użyteczna, ale nie jest doskonała, a jej ograniczenia mają znaczenie dla nadchodzącego porównania:

Luki w wymowie — może błędnie wymawiać rzadkie słowa, nazwy własne, terminy medyczne lub prawne oraz skróty.
Nierówne wsparcie językowe — wiele narzędzi dobrze radzi sobie z popularnymi językami, ale ma trudności z mniej powszechnymi językami i dialektami regionalnymi.
Ton i niuans — TTS ma trudności z sarkazmem, humorem i wyrażeniami idiomatycznymi, więc treści mogą zostać przekazane w niewłaściwym tonie.
Brak modelu interakcji — i to jest ta najważniejsza kwestia: TTS czyta; nie pozwala Ci niczego zrobić. Używając samego TTS, nie wypełnisz formularza płatności, nie zamkniesz okna modalnego ani nie przejdziesz między pozycjami menu.

To właśnie ostatnie ograniczenie jest miejscem, w którym zaczyna się pomyłka z czytnikami ekranu.

Jaka jest różnica między technologią syntezy mowy a czytnika ekranu?

Tu właśnie powstaje powszechne nieporozumienie. Synteza mowy czyta tekst na głos — to jej podstawowa funkcja. Czytnik ekranu robi znacznie więcej: pozwala użytkownikom nawigować po całym komputerze lub urządzeniu mobilnym i obsługiwać je za pomocą słuchu i klawiatury (lub gestów dotykowych).

Czytniki ekranu ogłaszają etykiety interfejsu, pola formularzy, przyciski i odnośniki; odczytują tekst alternatywny obrazów, aby użytkownicy rozumieli treści wizualne; oraz udostępniają stan komponentów — czy pole wyboru jest zaznaczone, czy menu jest rozwinięte, czy zakładka jest wybrana lub czy pojawił się błąd. Zamieniają wizualny interfejs obsługiwany myszą w liniowy, słyszalny i możliwy do obsługi.

Szybki sposób, by poczuć różnicę: TTS odpowiada na pytanie „co mówi ten akapit?”. Czytnik ekranu odpowiada na „gdzie jestem, co mogę tu zrobić i co się właśnie stało?”. Pierwsze dotyczy przyswajania treści. Drugie — sterowania oprogramowaniem.

Jak użytkownik czytnika ekranu faktycznie porusza się po stronie

Osoby widzące skanują stronę w kilka sekund. Użytkownik czytnika ekranu buduje model mentalny sekwencyjnie i polega na strukturze, by poruszać się efektywnie. W praktyce:

Przeskakują między nagłówkami, aby zrozumieć układ strony (dlatego poprawna hierarchia nagłówków ma tak duże znaczenie).
Wywołują listę wszystkich odnośników lub wszystkich pól formularza, aby nawigować po punktach orientacyjnych zamiast czytać od góry do dołu.
Korzystają z obszarów orientacyjnych (baner, nawigacja, treść główna, stopka), aby przeskoczyć od razu do treści, której chcą.
Przechodzą między elementami interaktywnymi klawiszem Tab i oczekują, że fokus trafi w widoczne i logiczne miejsce.
Nasłuchują komunikatów na żywo, gdy coś się zmienia bez pełnego przeładowania strony.

Nic z tego nie działa, dopóki leżący u podstaw kod nie opisuje strony uczciwie. Funkcja „czytaj na głos” nie zapewnia żadnego z tych udogodnień nawigacyjnych — po prostu narratoruje dowolny tekst na ekranie, w kolejności wizualnej, bez możliwości obsługi elementów sterujących.

Kto z czego korzysta i dlaczego to ma znaczenie

TTS jest używana przez szerokie grono odbiorców, często sytuacyjnie: osoby z dysleksją, ADHD lub słabym wzrokiem; osoby wykonujące wiele zadań naraz; osoby uczące się języków; oraz każdego, kto po prostu woli słuchać. Większość tych użytkowników wciąż widzi ekran i może korzystać z myszy.

Wśród użytkowników czytników ekranu są osoby niewidome lub z poważnymi wadami wzroku, a także niektóre osoby z niepełnosprawnościami poznawczymi lub ruchowymi, które polegają na tej technologii, by w ogóle móc korzystać z urządzenia. Dla nich nie jest to warstwa preferencji nałożona na używalny interfejs — to jest interfejs. Najpopularniejsze narzędzia to NVDA i JAWS w systemie Windows, VoiceOver na urządzeniach Apple oraz TalkBack w systemie Android. Każde z nich interpretuje tę samą stronę internetową nieco inaczej, co jest jednym z powodów, dla których testowanie we wszystkich ma znaczenie.

Dlaczego widżety czytania na głos nie zastępują dostępności

Coraz więcej witryn doczepia przycisk „posłuchaj tej strony” lub widżet innej firmy, który podświetla i odczytuje tekst. Narzędzia te mogą pomóc niektórym czytelnikom i nie ma nic złego w oferowaniu jednego z nich dla wygody. Problemem jest traktowanie go jako zamiennika prawdziwej obsługi czytników ekranu. Nim nie jest, z kilku konkretnych powodów.

Tylko czytają; nie obsługują. Widżet czytania na głos odczyta Twoją tabelę cen, ale nie pozwoli niewidomemu użytkownikowi wybrać planu, otworzyć koszyka, wprowadzić danych płatności i sfinalizować zakupu. Prawdziwe zadania wymagają elementów sterujących możliwych do obsługi, a nie narracji.
Nie potrafią udostępnić stanu ani ról. Czy przycisk jest wciśnięty, czy pole jest wymagane, czy sekcja jest zwinięta, czy właśnie pojawił się komunikat o błędzie — nic z tego nie jest przekazywane przez odczytywanie widocznego tekstu. Czytniki ekranu polegają na rolach, nazwach i stanach w kodzie, aby to ogłosić.
Użytkownicy czytników ekranu już mają narzędzie. Niewidomi użytkownicy przynoszą własny czytnik ekranu, precyzyjnie dostrojony do ich preferencji i pamięci mięśniowej. Widżet na poziomie strony konkuruje z nim, czasem mu przeszkadza i nic nie robi, by naprawić wadliwy kod, na którym ich czytnik ekranu się zacina.
Maskują problemy, zamiast je naprawiać. Jeśli pole formularza nie ma etykiety, widżet pominie je tak samo jak czytnik ekranu — tyle że teraz brakująca etykieta jest ukryta za funkcją, która wygląda na pomocną. Leżąca u podstaw wada pozostaje.

Ta sama logika dotyczy, jeszcze mocniej, tak zwanych nakładek dostępności (overlays) — skryptów, które obiecują natychmiastową zgodność poprzez nałożenie automatycznych poprawek i paska narzędzi na istniejącą witrynę. Nie naprawiają one leżącego u podstaw kodu, często kolidują z własną technologią wspomagającą użytkowników i nie są w stanie zapewnić rzeczywistej zgodności. Wiarygodna droga to naprawienie źródła. Pełniejsze wyjaśnienie, dlaczego powierzchowne poprawki nie wystarczają, znajdziesz w naszym przewodniku po prawdziwej dostępności cyfrowej.

Konkretny przykład: kasa, która „mówi”

Wyobraź sobie sklep internetowy, który dodał widżet czytania na głos i jest przekonany, że witryna jest już dostępna. Niewidoma klientka przychodzi z własnym uruchomionym czytnikiem ekranu. Opis produktu czyta się dobrze — ta część to tylko tekst. Ale element „Dodaj do koszyka” to ostylowany div z procedurą obsługi kliknięcia zamiast prawdziwego przycisku, więc czytnik ekranu nigdy nie ogłasza go jako przycisku, a klawiatura nie może go osiągnąć. Selektor ilości aktualizuje sumę bez obszaru na żywo, więc zmiana jest bezgłośna. Pole kodu promocyjnego ma tekst zastępczy, ale brak powiązanej etykiety, więc jest ogłaszane tylko jako „edytuj tekst”. Formularz wysyłki pokazuje wizualnie czerwony błąd, ale błąd nie jest powiązany z polem i nie jest w ogóle ogłaszany. Widżet czytania na głos radośnie narratoruje widoczny tekst i niczego z tego nie zmienia. Klientka może usłyszeć treści marketingowe, ale nie może sfinalizować zakupu. Ta przepaść — między usłyszeniem treści a obsługą produktu — to cała różnica między funkcją wygody a dostępnością.

Czego naprawdę wymaga tworzenie z myślą o czytnikach ekranu

Wspieranie czytników ekranu nie polega na dodaniu funkcji — polega na zbudowaniu stron tak, aby znaczenie, struktura i zachowanie były dostępne dla oprogramowania, a nie tylko dla ludzkiego oka. Kluczowe składniki:

Semantyczny, ustrukturyzowany HTML

Używaj prawdziwych nagłówków (h1–h6) w logicznej kolejności, natywnych przycisków i odnośników do właściwych celów, list do list oraz elementów orientacyjnych dla regionów strony. Semantyczny HTML niesie informacje o dostępności za darmo; ściana z ogólnych kontenerów nie niesie żadnych.

Alternatywy tekstowe dla treści nietekstowych

Każdy znaczący obraz potrzebuje dokładnego tekstu alternatywnego, a obrazy dekoracyjne powinny być oznaczone tak, by były pomijane. Ikony pełniące funkcję przycisków potrzebują dostępnych nazw. Wykresy i infografiki potrzebują tekstowego odpowiednika, który przekazuje tę samą informację.

Dostępne nazwy, role i stany

Pola formularzy potrzebują etykiet powiązanych programowo. Niestandardowe komponenty — zakładki, akordeony, pola kombinowane, okna modalne — potrzebują poprawnych ról i stanów, aby czytnik ekranu ogłaszał, czym są i jak się zachowują. Tam, gdzie natywny HTML nie wystarcza, ARIA wypełnia lukę, ale musi być używana precyzyjnie; nieprawidłowa ARIA jest gorsza niż żadna.

Obsługa za pomocą klawiatury i zarządzanie fokusem

Wszystko, co działa za pomocą myszy, musi działać za pomocą klawiatury, kolejność fokusu musi być logiczna, wskaźnik fokusu musi być widoczny, a zmiany dynamiczne (otwarcie okna dialogowego, ujawnienie błędu) muszą odpowiednio przenosić lub ogłaszać fokus. Obsługa klawiatury i obsługa czytników ekranu są ze sobą głęboko powiązane.

Ogłaszanie zmian dynamicznych

Gdy treść aktualizuje się bez przeładowania strony — komunikat walidacji formularza, licznik koszyka, stan ładowania — używaj obszarów na żywo, aby czytnik ekranu powiedział użytkownikowi, że coś się stało. Bezgłośne aktualizacje są niewidoczne dla osób, które nie widzą ekranu.

Wszystkie te oczekiwania są skodyfikowane w kryteriach sukcesu WCAG 2.2, które stanowią techniczny kręgosłup European Accessibility Act oraz ADA w zastosowaniu do sieci. Jeśli chcesz praktycznych szczegółów, nasz przewodnik po testowaniu z czytnikami ekranu krok po kroku pokazuje, jak zweryfikować każde z tych zachowań przy użyciu prawdziwych narzędzi.

Dlaczego „mnie czyta się dobrze” wprowadza w błąd

Widzący programista może włączyć funkcję czytania na głos, usłyszeć czyste zdania i wywnioskować, że strona jest dostępna. Pułapka polega na tym, że czytanie na głos odtwarza widoczną kolejność czytania i widoczny tekst, które oba już mają sens dla kogoś patrzącego na ekran. Nie mówi nic o tym, czy niestandardowa lista rozwijana ogłasza swoje opcje, czy fokus jest uwięziony wewnątrz otwartego okna dialogowego, czy przycisk złożony tylko z ikony ma nazwę ani czy kolejność tabulacji odpowiada układowi wizualnemu. To właśnie te rzeczy psują się dla użytkowników czytników ekranu i właśnie tych rzeczy demonstracja czytania na głos nie jest w stanie ujawnić. Jedynym sposobem, by się dowiedzieć, jest testowanie tak, jak robią to faktyczni użytkownicy.

Jak testować pod kątem obu — i dlaczego sama automatyzacja nie wystarczy

Nie potwierdzisz, że strona działa dla użytkowników czytników ekranu, słuchając przycisku czytania na głos. Potwierdzasz to, sprawdzając strukturę, nazwy, role, stany, obsługę klawiatury oraz rzeczywiste doświadczenie z czytnikiem ekranu w wielu narzędziach i na wielu platformach.

Solidny proces łączy trzy warstwy:

Skanowanie automatyczne, aby wychwycić liczne, wykrywalne maszynowo problemy — brakujący tekst alternatywny, puste etykiety, uszkodzone odwołania ARIA, niewystarczający kontrast. Nasze oprogramowanie do skanowania dostępności oraz bezpłatne skanowanie dostępności to szybki sposób, by ustalić punkt wyjścia.
Ręczne testy ekspertów, aby ocenić wszystko, czego automatyzacja nie potrafi osądzić: czy nazwa jest znacząca, czy kolejność fokusu ma sens, czy niestandardowy widżet jest naprawdę możliwy do obsługi. Uzasadnienie tej warstwy omawia nasz przewodnik po ręcznych audytach dostępności.
Testowanie z prawdziwą technologią wspomagającą i prawdziwymi użytkownikami. Nic nie zastąpi obsługi strony za pomocą NVDA, JAWS, VoiceOver i TalkBack — a najlepiej obserwowania osób, które codziennie używają tych narzędzi. Nasze audyty prowadzone przez osoby z niepełnosprawnościami wnoszą właśnie tę przeżytą wiedzę.

Narzędzia automatyczne zwykle wykrywają jedynie część kryteriów sukcesu WCAG 2.2; reszta wymaga ludzkiego osądu. Traktowanie zaliczonego skanu automatycznego jako dowodu dostępności to ten sam rodzaj błędu, co traktowanie widżetu czytania na głos jako wsparcia dla czytników ekranu.

Gdzie wpisuje się QualiBooth

QualiBooth testuje Twoją witrynę pod kątem zarówno przypadków użycia TTS, jak i czytników ekranu, aby Twoje treści były dostępne dla użytkowników polegających na którejkolwiek z tych technologii — i aby osoby, które zależą od czytnika ekranu, mogły nie tylko usłyszeć Twoje treści, ale faktycznie obsługiwać Twój produkt. Nasz zestaw narzędzi do dostępności oraz platforma Agora łączą skanowanie z ustrukturyzowanym przeglądem ręcznym, a nasz zespół doradztwa w zakresie dostępności pomaga naprawić to, co ujawniają testy, oraz dostosować się do wymagań WCAG 2.2, EAA i ADA.

Wniosek jest prosty. Nadanie treściom głosu to miły dodatek. Sprawienie, by treści dały się przeglądać, obsługiwać i były poprawnie ogłaszane czytnikowi ekranu, to dostępność — a tylko jedno z tych dwóch zaspokaja prawo i osoby, które ono chroni.