Testování čteček obrazovky: NVDA, JAWS, VoiceOver

Stránka může projít každou automatizovanou kontrolou, být dodána s platným HTML a přesto být nepoužitelná pro někoho, kdo se po webu pohybuje sluchem. Automatizované nástroje zachytí zhruba třetinu problémů s přístupností; zbytek se nachází v mezeře mezi tím, co strom přístupnosti technicky obsahuje, a tím, co čtečka obrazovky uživateli skutečně ohlásí. Uzavření této mezery znamená předložit vaše rozhraní stejným nástrojům, na které vaše publikum spoléhá — a přesně k tomu testování čteček obrazovky slouží.

Tento průvodce prochází tím, jak se hlavní čtečky obrazovky liší, proč testování jen jedné z nich nikdy nestačí, co přesně testovat, které kombinace čtečky a prohlížeče použít a úskalí, na která narážejí i zkušené týmy. Je psán pro vývojáře, QA inženýry a specialisty na přístupnost, kteří chtějí testovat uvážlivě, nikoli hádat. Pokud byste raději přenechali práci specialistům, kteří tyto nástroje používají každý den, naše služba vyhodnocení čtečky obrazovky dělá přesně to.

Proč čtečka obrazovky není nástroj na „čtení nahlas“

Nejčastější mylná představa je, že čtečka obrazovky jednoduše vyslovuje text na stránce. Dělá mnohem víc než to a pochopení tohoto rozdílu je základem dobrého testování. Čtečka obrazovky si z prohlížečova stromu přístupnosti vytváří paralelní, nevizuální model rozhraní. Ohlašuje název každého prvku („Odeslat, tlačítko“), jeho roli (tlačítko, odkaz, nadpis, zaškrtávací pole) a jeho stav (zaškrtnuto, rozbaleno, zakázáno, povinné). Umožňuje uživateli přeskakovat mezi nadpisy, orientačními body, formulářovými poli a odkazy, aniž by se dotkl vizuálního rozvržení. Vyslovuje dynamické změny — chybové zprávy, výsledky vyhledávání, aktualizace stavu — pokud jsou tyto změny správně vystaveny.

To se zásadně liší od převodu textu na řeč, který převádí blok textu na zvuk bez jakéhokoli konceptu rolí, stavů či navigace. Tento rozdíl rozebíráme podrobně v článku převod textu na řeč versus čtečky obrazovky a zde je důležitý, protože testování jednoho netestuje druhé. Uživatel čtečky obrazovky nekonzumuje vaši stránku odshora dolů; pohybuje se po ní strukturálně a očekává, že každý interaktivní prvek prohlásí, co je a co dělá.

Jak se NVDA, JAWS, VoiceOver a TalkBack liší

Čtyři čtečky, na kterých většině týmů musí záležet, se chovají dostatečně odlišně, takže „funguje to v jedné“ vám o ostatních neřekne téměř nic.

NVDA (Windows)

NVDA je bezplatná čtečka s otevřeným zdrojovým kódem a celosvětově nejpoužívanější čtečka obrazovky. Nejpřirozeněji se pojí s Firefoxem a Chromem. NVDA obvykle úzce dodržuje sémantiku ARIA a HTML, což z ní činí vynikající výchozí bod: pokud je něco rozbité ve vašem kódu, NVDA to často zřetelně odhalí. Má dva klíčové režimy — režim prohlížení (pro čtení a strukturální navigaci) a režim zaměření (pro psaní do formulářů a ovládání widgetů) — a častým zdrojem chyb jsou widgety, které nedokáží spustit správné přepnutí režimu.

JAWS (Windows)

JAWS je dlouho zavedená komerční čtečka, stále dominantní v podnicích, státní správě a na mnoha pracovištích. Pojí se s Chromem a Edgem. JAWS je proslulý svou „ochotou“: uplatňuje heuristiky, které odhadují význam, někdy ohlašuje věci, o nichž NVDA mlčí, a občas zahlazuje chyby v kódu, které by měly být opraveny. Tato ochota má dvě ostří — kód, který „funguje v JAWS“, může selhat v NVDA nebo VoiceOveru, protože JAWS problém zamaskoval. Má také vlastní virtuální kurzor a chování režimu formulářů, které se jemně liší od NVDA.

VoiceOver (macOS a iOS)

VoiceOver je vestavěný v každém Macu, iPhonu a iPadu a pojí se téměř výhradně se Safari. Na macOS probíhá navigace přes rotor a klávesové zkratky VO; na iOS je zcela ovládán gesty — přejetím se pohybujete, dvojitým ťuknutím aktivujete, rotor otočením dvou prstů. VoiceOver je obecně nejpřísnější ze čtyř, pokud jde o ARIA: často raději umlkne, než aby hádal, když chybí názvy nebo role, takže ovládací prvek, který JAWS ohlásí, nemusí ve VoiceOveru říct vůbec nic. Desktopový a mobilní VoiceOver se také navzájem liší, takže se počítají jako dva samostatné testovací cíle.

TalkBack (Android)

TalkBack je vestavěná čtečka Androidu, spárovaná s Chromem. Stejně jako iOS VoiceOver je založen na gestech, ale jeho gesta, chování zaměření a zacházení s živými oblastmi a vlastními ovládacími prvky se od VoiceOveru liší. Mobilní čtečky obecně odhalují problémy, které se na desktopu nikdy neobjeví: dotykové cíle, které nelze dosáhnout přejetím, zaměření, které neočekávaně skáče po přechodu obrazovky, a obsah, který je vizuálně přítomen, ale lineárním pořadím gest zcela přeskočen.

Proč je testování více čteček nezbytné

Protože se tyto čtečky rozcházejí v tom, jak interpretují naprosto stejný kód, testování jen jedné čtečky vytváří falešný pocit bezpečí. Opakovaně se objevuje několik konkrétních vzorů:

• Vlastní rozevírací seznam (combobox), který JAWS ohlásí dokonale, může ve VoiceOveru zcela umlknout, protože VoiceOver odmítá odvodit chybějící stav role nebo aria-expanded.
• Živá oblast, kterou NVDA zdvořile ohlásí jednou, může být v jiné čtečce ohlášena opakovaně, nebo vůbec, podle toho, jak se vzájemně ovlivňují aria-live a načasování vložení do DOM.
• Ovládací prvek s nadbytečným nebo konfliktním názvem (viditelný popisek plus aria-label plus title) může být jednou čtečkou ohlášen smysluplně a jinou jako matoucí řetězec duplikátů.
• Pořadí čtení, které v jedné kombinaci prohlížeč/čtečka odpovídá vizuálnímu pořadí, se může v jiné rozejít, když CSS přeskupí obsah, ale DOM nikoli.

Každá čtečka je také vázána na jiný prohlížeč, takže ve skutečnosti testujete kombinace čtečka-plus-prohlížeč, nikoli čtečky samotné. Jediný způsob, jak zjistit, že je váš produkt soudržný pro všechny, je testovat skutečné kombinace, které vaše publikum používá. Tento princip je tentýž, který obecně stojí za manuálními audity přístupnosti: nástroje zužují hledání, lidé potvrzují zážitek.

Co testovat

Testování je mnohem účinnější, když je strukturované. Toto jsou rozměry, na kterých záleží, zhruba v pořadí priority, a každý se mapuje na konkrétní kritéria úspěchu WCAG 2.2.

Ohlášení: název, role, hodnota

U každého interaktivního prvku ověřte, že čtečka ohlašuje přesný název (co to je), správnou roli (tlačítko, odkaz, zaškrtávací pole, karta) a tam, kde je to relevantní, hodnotu nebo stav. To je jádro WCAG 4.1.2 (Název, role, hodnota). Naslouchejte zejména: tichým ovládacím prvkům, prvkům ohlašovaným pouze jako „klikatelné“ nebo „skupina“, ikonovým tlačítkům bez přístupného názvu a názvům, které se čtou jako surové cesty k souborům nebo názvy tříd.

Role a stavy

Stavy se musí aktualizovat podle toho, jak uživatel interaguje. Rozbalovací prvek, který se rozbalí, by se měl překlopit z „sbaleno“ na „rozbaleno“; zaškrtávací pole by se mělo přesunout z „nezaškrtnuto“ na „zaškrtnuto“; tlačítko řazení by mělo ohlásit svůj aktuální směr. Statický kód, který nikdy neaktualizuje aria-expanded, aria-checked, aria-selected ani aria-pressed, je jednou z nejčastějších vad a odhalí se až tehdy, když widget ovládáte s běžící čtečkou.

Pořadí zaměření a správa zaměření

Projděte celé rozhraní tabulátorem. Zaměření se musí pohybovat v logickém, předvídatelném pořadí (WCAG 2.4.3), musí být vždy viditelné a nikdy nesmí být uvězněno, kromě záměrného uvěznění uvnitř modálního okna. Obtížné případy jsou dynamické: když se otevře dialog, zaměření by se mělo přesunout do něj; když se zavře, zaměření by se mělo vrátit na prvek, který jej otevřel. Vynechání tohoto je nejčastějším důvodem, proč je modální tok nepoužitelný.

Pořadí čtení a navigace

Kromě zaměření se uživatelé čteček obrazovky pohybují podle struktury. Ověřte, že nadpisy tvoří logickou osnovu (WCAG 1.3.1), že orientační body (header, nav, main, footer) umožňují uživatelům přeskakovat, a že seznamy a tabulky jsou označeny tak, aby v nich čtečka mohla navigovat a počítat je. Zkontrolujte, že posloupnost čtení odpovídá vizuálnímu záměru a že nic důležitého není ohlášeno ve špatném pořadí.

Živé oblasti a dynamické aktualizace

Asynchronní změny — validační chyby, „nalezeny 3 výsledky“, „ukládání…“, oznámení typu toast — musí uživatele zastihnout, aniž by ho zahltily. aria-live="polite" pro nenaléhavé aktualizace, aria-live="assertive" pouze pro skutečně naléhavé a role="status" nebo role="alert" pro běžné případy. Otestujte, že oblast existuje v DOM před změnou obsahu, že je aktualizace ohlášena přesně jednou a že nepřeruší uživatele uprostřed věty. To podporuje WCAG 4.1.3 (Stavové zprávy).

Vlastní widgety ARIA

Cokoli, co jste vytvořili sami — nabídky, karty, rozevírací seznamy, výběry data, kolotoče, datové mřížky, stromová zobrazení — vyžaduje nejvíce pozornosti. Otestujte je proti ARIA Authoring Practices na očekávanou klávesovou interakci a ohlášení a poté potvrďte, že se skutečné čtečky takto opravdu chovají. APG popisuje ideál; čtečky jej implementují nedokonale, a proto je třeba fungující vzor přesto ověřit v každé čtečce.

Konkrétní příklad: nepřístupný versus přístupný přepínač

Uvažujme přepínač nastavení. Vizuálně stylizovaná, ale sémanticky prázdná verze:

<div class="toggle" onclick="setNotifications()">
  <span class="dot"></span> Notifications
</div>

Pro čtečku obrazovky je to v nejlepším případě kus statického textu. Není zde žádná role, takže to není ohlášeno jako ovládací prvek; žádný stav, takže uživatel nepozná, zda jsou oznámení zapnutá nebo vypnutá; a není to v pořadí tabulátoru, takže uživatel klávesnice nebo čtečky obrazovky to nemůže vůbec dosáhnout ani ovládat. Při testování NVDA přečte „Notifications“ a pokračuje dál; VoiceOver to může zcela přeskočit.

Přístupný ekvivalent používá nativní prvek a vystavuje stav:

<button type="button" aria-pressed="false" id="notif">
  Notifications
</button>

const btn = document.getElementById('notif');
btn.addEventListener('click', () => {
  const on = btn.getAttribute('aria-pressed') === 'true';
  btn.setAttribute('aria-pressed', String(!on));
});

Nyní každá čtečka ohlásí „Notifications, přepínací tlačítko, nestisknuto“, je dosažitelné tabulátorem, ovladatelné klávesou Enter nebo mezerníkem a stav se při aktivaci slyšitelně překlopí. Poučení se zobecňuje: dávejte přednost nativní sémantice a když musíte použít ARIA, otestujte, že každá čtečka roli a stav skutečně respektuje. Vzory jako tato vada chybějícího stavu patří mezi běžné problémy s přístupností, kterým je třeba se vyhnout.

Doporučené kombinace čteček a prohlížečů

Testujte kombinace, které skuteční uživatelé používají, nikoli libovolné dvojice. Praktická matice, která pokrývá velkou většinu uživatelů čteček obrazovky:

• NVDA + Firefox (Windows) — nejčistší výchozí bod pro zachycení problémů v kódu
• NVDA + Chrome (Windows) — nejčastější kombinace bezplatné čtečky v praxi
• JAWS + Chrome (Windows) — dominantní v podnikovém a vládním prostředí
• VoiceOver + Safari (macOS) — jediná plně podporovaná desktopová kombinace VoiceOveru
• VoiceOver + Safari (iOS) — mobilní založený na gestech, samostatný cíl od desktopu
• TalkBack + Chrome (Android) — standardní kombinace pro Android

Na kombinacích záleží, protože čtečky jsou vyladěny pro konkrétní prohlížeče; VoiceOver s Chromem nebo JAWS s Firefoxem produkuje chování, které neodráží, jak vaše publikum stránku skutečně zažívá. Tam, kde vaše analytika ukazuje konkrétní publikum — řekněme produkt veřejného sektoru s vysokým využitím JAWS nebo spotřebitelskou aplikaci, která se kloní k mobilu — zvažte matici odpovídajícím způsobem. Naše služba vyhodnocení čtečky obrazovky ladí tuto matici podle analytiky každého klienta, místo aby testovala pevný seznam.

Běžná úskalí

I pečlivé týmy zakopávají o stejné věci. Dejte si pozor na tyto:

• Testování s otevřenýma očima. Pokud vidíte obrazovku, podvědomě kompenzujete to, co vám čtečka neříká. Vypněte monitor, nebo se alespoň odvraťte, a navigujte pouze podle zvuku.
• Testování jen jedné čtečky. Pokryto výše — je to jediný největší zdroj falešné jistoty.
• Vynechávání režimu formulářů/zaměření. V NVDA a JAWS vlastní widgety často vyžadují, aby byl uživatel ve správném režimu. Pokud testujete pouze v režimu prohlížení, uniknou vám interakce, které se rozbijí v režimu zaměření.
• Nadužívání aria-label. Přidávání ARIA popisků všude může přepsat viditelný text, rozsynchronizovat přístupný název s tím, co je zobrazeno, a zmást uživatele hlasového ovládání. Dávejte přednost nativnímu označování; po ARIA sáhněte jen tehdy, když HTML nedokáže vztah vyjádřit.
• Předpoklad, že APG zaručuje úspěch. ARIA Authoring Practices popisují zamýšlené chování, nikoli to, co dělá každá čtečka. Vždy ověřujte proti skutečným čtečkám.
• Důvěra ve widgety typu overlay. Widgety typu overlay a „AI přístupnost“, které tvrdí, že opravují přístup čtečky obrazovky za běhu, nepřinášejí spolehlivý zážitek a často navigaci zhoršují právě těm lidem, kterým tvrdí, že pomáhají. Pro přístupný kód potvrzený skutečným testováním neexistuje náhrada. Auditujte skutečný DOM a ohlášení, nikoli marketing overlaye.
• Pojímání mobilu jako dodatečné myšlenky. iOS VoiceOver a Android TalkBack odhalují vlastní problémy s gesty, zaměřením a živými oblastmi, které desktopové testování nikdy neodhalí.

Proč testování lidmi se zdravotním postižením přidává hodnotu

Spuštění čtečky vám samotnému odhalí spoustu věcí — ale mezi technickým projitím a skutečnou použitelností je významný rozdíl, a právě v tomto rozdílu má prožitá zkušenost největší význam. Každodenní uživatel čtečky obrazovky naviguje reflexivně: pohybuje se po nadpisech, prochází rotorem, pozná, kdy je ohlášení rozvláčné nebo nadbytečné, a okamžitě cítí, když ho tok nutí na neefektivní cestu, i kdyby byl každý jednotlivý prvek „v souladu“.

Vidoucí vývojář testující poprvé má tendenci ověřovat přítomnost — „tlačítko je ohlášeno“ — zatímco expertní uživatel hodnotí zážitek — „tlačítko je ohlášeno, ale popisek je nejednoznačný, potvrzení se nevysloví a dostat se sem stálo dvanáct přejetí navíc“. Tyto zjištění o použitelnosti se v kontrolním seznamu souladu objevují zřídka, a přesto právě ona rozhodují o tom, zda někdo úkol skutečně dokáže dokončit. Proto QualiBooth kombinuje automatizovaný software pro skenování přístupnosti a naši sadu nástrojů pro přístupnost s audity lidmi se zdravotním postižením: nástroje najdou to zjevné, experti najdou to, co zážitek skutečně narušuje. U produktů, které se často mění, udržují opakované audity přístupnosti toto pokrytí, aby se mezi vydáními neodchylovalo.

Kam testování čteček obrazovky zapadá ve vašem programu

Testování čteček obrazovky je jednou disciplínou v rámci širší praxe. Přirozeně se pojí s testováním pouze klávesnicí a s adaptivními webovými nástroji, na které vaši uživatelé spoléhají, a produkuje druh důkazů, který podporuje právní povinnosti podle EAA, ADA a Section 508. Zjištění také přímo napájejí dokumentaci: náš tým převádí výsledky čtečka po čtečce do zpráv VPAT a do prioritizovaných nápravných plánů, které dodáváme prostřednictvím konzultací v oblasti přístupnosti. Pokud budujete dlouhodobý program namísto jednorázové kontroly, je to právě tato integrace, co brání tomu, aby přístupnost regredovala.

Závěr

Čtečky obrazovky nejsou zaměnitelné a čistá automatizovaná zpráva není použitelný produkt. NVDA, JAWS, VoiceOver a TalkBack interpretují váš kód každý jinak, pojí se s různými prohlížeči a odhalují různé vady — takže testování napříč skutečnými kombinacemi, které vaše publikum používá, je jediný způsob, jak si být jistí. Strukturujte své testování kolem ohlášení, rolí a stavů, zaměření, pořadí čtení, živých oblastí a vlastních widgetů; dávejte přednost nativní sémantice před záplatami ARIA; ignorujte overlaye; a kdekoli je to možné, nechte lidi, kteří tyto nástroje používají každý den, aby vám řekli, co skutečně funguje.

Když chcete tuto jistotu ověřenou specialisty, vyhodnocení čtečky obrazovky od QualiBooth testuje napříč všemi hlavními čtečkami a vrací zjištění s přesnými opravami kódu. Můžete také začít bezplatným skenováním nebo požádat o demo a zjistit, kde vaše rozhraní dnes stojí.

Časté dotazy

Kolik čteček obrazovky opravdu potřebuji testovat?

Minimálně testujte NVDA, JAWS a VoiceOver na desktopu, plus VoiceOver na iOS a TalkBack na Androidu, pokud dodáváte mobilní zážitek. Testování méně z nich zanechává slepá místa, protože čtečky se rozcházejí v tom, jak zacházejí s ARIA a dynamickým obsahem.

Mohou automatizované nástroje nahradit testování čteček obrazovky?

Ne. Automatizované nástroje spolehlivě zachytí jen část problémů — chybějící alternativní text, některé problémy s kontrastem, určité strukturální chyby — ale nedokáží posoudit, zda je ohlášení srozumitelné, zda se zaměření pohybuje smysluplně, nebo zda je úkol skutečně dokončitelný pouze sluchem. To vyžaduje skutečnou čtečku a v ideálním případě skutečného uživatele.

Odstraňují widgety typu overlay nebo „AI přístupnost“ potřebu testování?

Ne. Overlaye neprodukují spolehlivý zážitek se čtečkou obrazovky a často zavádějí nové problémy. Trvalou opravou je přístupný kód potvrzený skutečným testováním čtečkou, což je to, co poskytuje naše služba vyhodnocení čtečky obrazovky.

Která kritéria WCAG testování čteček obrazovky pokrývá?

Přímo podporuje 1.3.1 (Informace a vztahy), 2.4.3 (Pořadí zaměření), 4.1.2 (Název, role, hodnota) a 4.1.3 (Stavové zprávy), mimo jiné. Každé zjištění ze strukturovaného vyhodnocení lze namapovat na příslušné kritérium úspěchu WCAG 2.2.