QualiBooth

guides

Převod textu na řeč vs. čtečky obrazovky

Je častým nedorozuměním, že převod textu na řeč je totéž co čtečka obrazovky. Není tomu tak a doufáme, že tento mýtus vyvrátíme.

10 min read QualiBooth
Ilustrace porovnávající asistivní technologie převodu textu na řeč a čteček obrazovky.

Váš obsah má hlas

Technologie převodu textu na řeč (TTS) převádí psané informace na zvuk. Pomáhá lidem s nevidomostí, zrakovým postižením, dyslexií a ADHD konzumovat obsah způsobem, který jim vyhovuje. TTS se také hojně používá ve školách, studenty jazyků a profesionály, kteří korigují sluchem místo zrakem.

Protože jak TTS, tak čtečky obrazovky produkují syntetický hlas, lidé často předpokládají, že jde o totéž — nebo že přidání tlačítka „přečíst nahlas” na web jej činí přístupným pro nevidomé uživatele. Tento předpoklad je mylný a jednání podle něj vám může zanechat web, který zní přístupně, ale který je pro mnoho lidí ve skutečnosti nemožné používat. Tento článek vysvětluje, jak každá technologie funguje, kdo se na ni spoléhá, kde skutečně leží hranice mezi nimi a co je zapotřebí ke správnému vývoji pro čtečky obrazovky. Pokud si zapamatujete jen jednu věc, ať je to tato: widget pro čtení nahlas je funkce pro pohodlí, nikoli funkce přístupnosti.

Jak TTS funguje?

TTS zpracovává text ve třech širokých fázích:

  • Analýza textu — určení tónu, gramatiky a struktury, rozepsání čísel a symbolů („$5” se stává „pět dolarů”) a segmentace vět.
  • Lingvistické zpracování — výpočet výslovnosti, přízvuku a důrazu, často s využitím výslovnostního slovníku plus pravidel pro neznámá slova.
  • Syntéza zvuku — generování řeči z matematických hlasových modelů, stále častěji s využitím neuronových sítí, které znějí mnohem přirozeněji než starší zřetězovací enginy.

Moderní systémy nabízejí přizpůsobení hlasu, jako je rychlost, výška tónu, hlasová persona a výběr jazyka. Klíčovým bodem je to, co TTS bere jako vstup: blok textu, který někdo již vybral, vložil nebo na něj ukázal. TTS je v zásadě technologie typu obsah-ven. Říká to, co dostane. Nezkoumá rozhraní a nemá žádnou představu o tlačítkách, formulářových polích nebo struktuře stránky.

Jaká jsou omezení technologie TTS?

TTS je opravdu užitečný, ale není dokonalý a jeho omezení jsou důležitá pro nadcházející srovnání:

  • Mezery ve výslovnosti — může nesprávně vyslovovat neobvyklá slova, vlastní jména, lékařské nebo právní termíny a zkratky.
  • Nerovnoměrná jazyková podpora — mnoho nástrojů zvládá hlavní jazyky dobře, ale potýkají se s méně běžnými jazyky a regionálními dialekty.
  • Tón a nuance — TTS má potíže se sarkasmem, humorem a idiomatickými výrazy, takže obsah může být sdělen s nesprávným tónem.
  • Žádný model interakce — a to je ta zásadní věc: TTS čte; neumožňuje vám nic dělat. Nemůžete vyplnit pokladní formulář, zavřít modální okno ani se přesouvat mezi položkami nabídky pouze pomocí TTS.

Právě toto poslední omezení je přesně to, kde začíná záměna se čtečkami obrazovky.

Jaký je rozdíl mezi technologií převodu textu na řeč a čtečkou obrazovky?

Zde vzniká ono časté nedorozumění. Převod textu na řeč čte text nahlas — to je jeho hlavní funkce. Čtečka obrazovky dělá mnohem více: umožňuje uživatelům ovládat celý počítač nebo mobilní zařízení a navigovat v něm sluchem a klávesnicí (nebo dotykovými gesty).

Čtečky obrazovky oznamují popisky rozhraní, formulářová pole, tlačítka a odkazy; čtou alternativní text obrázků, aby uživatelé porozuměli vizuálnímu obsahu; a zpřístupňují stav komponent — zda je zaškrtávací pole zaškrtnuté, zda je nabídka rozbalená, zda je vybraná karta, nebo zda se objevila chyba. Mění vizuální rozhraní ovládané myší na lineární, slyšitelné, ovladatelné rozhraní.

Rychlý způsob, jak pocítit rozdíl: TTS odpovídá na otázku „Co říká tento odstavec?” Čtečka obrazovky odpovídá na otázku „Kde jsem, co tady mohu dělat a co se právě stalo?” První se týká konzumace obsahu. Druhé se týká ovládání softwaru.

Jak se uživatel čtečky obrazovky skutečně pohybuje po stránce

Vidící uživatelé prohlédnou stránku během několika sekund. Uživatel čtečky obrazovky si sekvenčně buduje mentální model a spoléhá na strukturu, aby se mohl pohybovat efektivně. V praxi:

  • Přeskakují mezi nadpisy, aby porozuměli osnově stránky (proto je správná hierarchie nadpisů tak důležitá).
  • Vyvolají seznam všech odkazů nebo všech formulářových polí, aby navigovali podle orientačních bodů místo čtení shora dolů.
  • Používají orientační oblasti (banner, navigace, hlavní obsah, zápatí), aby skočili rovnou k obsahu, který chtějí.
  • Pohybují se mezi interaktivními prvky pomocí klávesy Tab a očekávají, že fokus přistane někde viditelně a logicky.
  • Naslouchají živým oznámením, když se něco změní bez úplného znovunačtení stránky.

Nic z toho nefunguje, pokud podkladový kód popisuje stránku poctivě. Funkce „přečíst nahlas” neposkytuje žádnou z těchto navigačních možností — pouze přednese, jaký text je na obrazovce, ve vizuálním pořadí, bez možnosti ovládat ovládací prvky.

Kdo používá kterou technologii a proč na tom záleží

TTS používá široké publikum, často situačně: lidé s dyslexií, ADHD nebo slabozrakostí; multitaskeři; studenti jazyků; a kdokoli, kdo prostě dává přednost poslechu. Většina těchto uživatelů stále vidí obrazovku a může používat myš.

Mezi uživatele čteček obrazovky patří lidé, kteří jsou nevidomí nebo mají těžké zrakové postižení, a také někteří lidé s kognitivním nebo motorickým postižením, kteří jsou na této technologii závislí, aby vůbec mohli zařízení používat. Pro ně to není vrstva preferencí navrch použitelného rozhraní — to je rozhraní. Nejčastějšími nástroji jsou NVDA a JAWS ve Windows, VoiceOver na zařízeních Apple a TalkBack na Androidu. Každý interpretuje stejnou webovou stránku trochu jinak, což je jeden z důvodů, proč na testování napříč nimi záleží.

Proč widgety pro čtení nahlas nejsou náhradou přístupnosti

Rostoucí počet webů na sebe připojuje tlačítko „poslechnout si tuto stránku” nebo widget třetí strany, který zvýrazňuje a vyslovuje text. Tyto nástroje mohou některým čtenářům pomoci a na nabídnutí takového nástroje pro pohodlí není nic špatného. Problém je v tom, že se s ním zachází jako s náhradou skutečné podpory čteček obrazovky. Tou není, a to z několika konkrétních důvodů.

  • Pouze čtou; neovládají. Widget pro čtení nahlas přednese vaši cenovou tabulku, ale neumožní nevidomému uživateli vybrat tarif, otevřít košík, zadat platební údaje a dokončit nákup. Skutečné úkoly vyžadují ovladatelné ovládací prvky, nikoli přednes.
  • Nemohou zpřístupnit stav ani role. Zda je tlačítko stisknuté, zda je pole povinné, zda je sekce sbalená, nebo zda se právě objevila chybová zpráva — nic z toho se nepřenese čtením viditelného textu. Čtečky obrazovky se spoléhají na role, názvy a stavy v kódu, aby to oznámily.
  • Uživatelé čteček obrazovky už nástroj mají. Nevidomí uživatelé si přinášejí vlastní čtečku obrazovky, jemně vyladěnou podle jejich preferencí a svalové paměti. Widget na úrovni stránky s ní soupeří, někdy ji ruší a nedělá nic pro nápravu rozbitého kódu, na kterém se jejich čtečka obrazovky zadrhává.
  • Maskují problémy místo toho, aby je řešily. Pokud formulářové pole nemá popisek, widget jej přeskočí stejně jako čtečka obrazovky — ale nyní je chybějící popisek skrytý za funkcí, která vypadá užitečně. Základní vada zůstává.

Stejná logika platí, dokonce ještě silněji, pro takzvané překryvné vrstvy přístupnosti (overlay) — skripty, které slibují okamžitý soulad navrstvením automatizovaných oprav a nástrojové lišty na stávající web. Neopravují podkladový kód, často kolidují s vlastní asistivní technologií uživatelů a nemohou zajistit skutečnou shodu. Spolehlivou cestou je opravit zdroj. Podrobnější vysvětlení, proč povrchové opravy nestačí, najdete v našem průvodci skutečnou digitální přístupností.

Konkrétní příklad: pokladna, která „mluví”

Představte si internetový obchod, který přidal widget pro čtení nahlas a je přesvědčen, že web je nyní přístupný. Přichází nevidomý zákazník se spuštěnou vlastní čtečkou obrazovky. Popis produktu se čte v pořádku — ta část je jen text. Ale ovládací prvek „Přidat do košíku” je nastylovaný div s obslužnou rutinou kliknutí místo skutečného tlačítka, takže jej čtečka obrazovky nikdy neoznámí jako tlačítko a klávesnice se k němu nedostane. Výběr množství aktualizuje součet bez živé oblasti, takže změna je tichá. Pole pro slevový kód má zástupný text, ale žádný přidružený popisek, takže je oznámeno pouze jako „upravit text”. Formulář pro dopravu vizuálně zobrazuje červenou chybu, ale chyba není propojena s polem a není vůbec oznámena. Widget pro čtení nahlas vesele přednáší viditelný text a nic z toho nemění. Zákazník slyší marketingový text, ale nemůže dokončit nákup. Tato propast — mezi slyšením obsahu a ovládáním produktu — je celým rozdílem mezi funkcí pro pohodlí a přístupností.

Co skutečně vyžaduje vývoj pro čtečky obrazovky

Podpora čteček obrazovky není o přidání funkce — jde o konstrukci vašich stránek tak, aby význam, struktura a chování byly dostupné softwaru, nejen lidskému oku. Hlavní ingredience:

Sémantické, strukturované HTML

Používejte skutečné nadpisy (h1h6) v logickém pořadí, nativní tlačítka a odkazy pro správné účely, seznamy pro seznamy a orientační prvky pro oblasti stránky. Sémantické HTML nese informace o přístupnosti zdarma; zeď generických kontejnerů nenese žádné.

Textové alternativy pro netextový obsah

Každý smysluplný obrázek potřebuje přesný alternativní text a dekorativní obrázky by měly být označeny tak, aby byly přeskočeny. Ikony, které fungují jako tlačítka, potřebují přístupné názvy. Grafy a infografiky potřebují textový ekvivalent, který sděluje stejnou informaci.

Přístupné názvy, role a stavy

Formulářová pole potřebují programově přidružené popisky. Vlastní komponenty — karty, akordeony, komboboxy, modální okna — potřebují správné role a stavy, aby čtečka obrazovky oznámila, co jsou a jak se chovají. Tam, kde nativní HTML nestačí, vyplní mezeru ARIA, ale musí se používat přesně; nesprávná ARIA je horší než žádná.

Ovladatelnost klávesnicí a správa fokusu

Vše, co funguje s myší, musí fungovat s klávesnicí, pořadí fokusu musí být logické, indikátor fokusu musí být viditelný a dynamické změny (otevření dialogu, odhalení chyby) musí fokus vhodně přesunout nebo oznámit. Podpora klávesnice a podpora čteček obrazovky jsou hluboce propojené.

Oznamování dynamických změn

Když se obsah aktualizuje bez znovunačtení stránky — zpráva o validaci formuláře, počitadlo košíku, stav načítání — použijte živé oblasti, aby čtečka obrazovky uživateli řekla, že se něco stalo. Tiché aktualizace jsou neviditelné pro lidi, kteří nevidí na obrazovku.

Všechna tato očekávání jsou kodifikována v kritériích úspěchu WCAG 2.2, která tvoří technickou páteř European Accessibility Act a ADA ve své aplikaci na web. Pokud chcete praktické detaily, náš průvodce testováním čteček obrazovky krok za krokem provází tím, jak ověřit každé z těchto chování pomocí skutečných nástrojů.

Proč je „mně se to čte v pořádku” zavádějící

Vidící vývojář může zapnout funkci čtení nahlas, slyšet čisté věty a usoudit, že stránka je přístupná. Past spočívá v tom, že čtení nahlas reprodukuje viditelné pořadí čtení a viditelný text, které oba již dávají smysl někomu, kdo se dívá na obrazovku. Neříká nic o tom, zda vlastní rozbalovací nabídka oznamuje své možnosti, zda je fokus uvězněn uvnitř otevřeného dialogu, zda má tlačítko obsahující pouze ikonu název, nebo zda pořadí tabulátoru odpovídá vizuálnímu rozvržení. To jsou přesně ty věci, které se rozbijí pro uživatele čteček obrazovky, a přesně ty věci, které ukázka čtení nahlas nemůže odhalit. Jediný způsob, jak to zjistit, je testovat tak, jak to dělají skuteční uživatelé.

Jak testovat obojí — a proč samotná automatizace nestačí

Nemůžete potvrdit, že stránka funguje pro uživatele čteček obrazovky, posloucháním tlačítka pro čtení nahlas. Potvrdíte to kontrolou struktury, názvů, rolí, stavů, ovládání klávesnicí a skutečného zážitku se čtečkou obrazovky napříč více nástroji a platformami.

Solidní proces kombinuje tři vrstvy:

  • Automatizované skenování k zachycení vysokoobjemových, strojově detekovatelných problémů — chybějící alternativní text, prázdné popisky, rozbité odkazy ARIA, selhání kontrastu. Náš software pro skenování přístupnosti a bezplatné skenování přístupnosti jsou rychlý způsob, jak zjistit, kde stojíte.
  • Odborné manuální testování k vyhodnocení všeho, co automatizace nemůže posoudit: zda je název smysluplný, zda pořadí fokusu dává smysl, zda je vlastní widget skutečně ovladatelný. Úvahy za touto vrstvou jsou popsány v našem průvodci manuálními audity přístupnosti.
  • Testování se skutečnou asistivní technologií a skutečnými uživateli. Nic nenahradí ovládání stránky pomocí NVDA, JAWS, VoiceOver a TalkBack — a v ideálním případě pozorování lidí, kteří tyto nástroje používají každý den. Naše audity prováděné lidmi s postižením přinášejí přesně tuto žitou odbornost.

Automatizované nástroje obvykle detekují pouze část kritérií úspěchu WCAG 2.2; zbytek vyžaduje lidský úsudek. Považovat úspěšné automatizované skenování za důkaz přístupnosti je stejná kategorie chyby jako považovat widget pro čtení nahlas za podporu čteček obrazovky.

Kde zapadá QualiBooth

QualiBooth testuje váš web proti případům použití jak TTS, tak čteček obrazovky, aby byl váš obsah přístupný uživatelům spoléhajícím se na kteroukoli technologii — a aby lidé závislí na čtečce obrazovky mohli váš obsah nejen slyšet, ale skutečně ovládat váš produkt. Naše sada nástrojů pro přístupnost a platforma Agora kombinují skenování se strukturovaným manuálním přezkumem a náš tým poradenství v oblasti přístupnosti vám pomáhá napravit to, co testy odhalí, a sladit se s požadavky WCAG 2.2, EAA a ADA.

Závěr je jednoduchý. Přidání hlasu k vašemu obsahu je pěkný detail. Učinit váš obsah navigovatelným, ovladatelným a správně oznámeným čtečce obrazovky je přístupnost — a pouze jedno z toho splňuje zákon a lidi, které chrání.

Nejste si jisti, zda váš web funguje se čtečkou obrazovky?