Testujete (či se chystáte testovat) přístupnost webových stránek s odečítači obrazovky a zajímá Vás, s jakými konkrétními kombinacemi odečítačů obrazovky a webových prohlížečů dává smysl takové testy dělat? Na základě svých zkušeností, potvrzených nedávnou diskusí na Twitteru, a také na základě výsledků 2016 GOV.UK assistive technology survey, doporučuji pro jednotlivé operační systémy používat následující kombinace.
MS Windows
Na Windows (stále nejpoužívanější platforma) jsou mezi nevidomými uživateli aktuálně nejpoužívanější následující dvě kombinace:
- NVDA s Mozilla Firefox
- JAWS s prohlížeči Google Chrome nebo Mozilla Firefox, které nahradily dlouhodobě používaný Internet Explorer.
Pokud zatím nejste s prací se screen readerem zcela obeznámeni (či si ji chcete připomenout), doporučuji k prostudování dva návody
- Testování přístupnosti webových stránek se screenreaderem JAWS
- Testování přístupnosti webových stránek se screenreaderem NVDA
Je také dobré vědět, že:
- i přes 100 % získaných na www.html5accessibility.com, MS Edge bohužel zatím neposkytuje dostatečnou podporu jak pro JAWS, tak NVDA, a ani není rozšířen mezi uživateli, takže testovat s ním moc nedává smysl.
- JAWS i NVDA nejsou standardní součástí systému, je potřeba je nejprve nainstalovat. U NVDA je případně možné použít i portable verzi.
- JAWS nabízí 40 minutovou demoverzi, kterou ale dle licenčních podmínek nelze používat ke (komerčnímu) testování. NVDA je open source odečítač, který žádné takové omezení nemá.
- JAWS spustíte poklepáním na jeho zástupce na Ploše, ukončíte jej pomocí klávesové kombinace Insert + F4.
- NVDA spustíte poklepáním na jeho zástupce na Ploše, ukončíte jej pomocí pomocí klávesové kombinace CapsLock + Q.
OS X a iOS
Na zařízeních od Applu, které běží na operačních systémech OS X či iOS, je nejlepší testovat s kombinací VoiceOver a Safari. VoiceOver je nedílnou součástí systému a stačí jej spustit
- na OS X pomocí Command+F5 (stejnou klávesovou kombinací jej pak lze i ukončit).
- Na iOS buď přes Nastavení – Obecné – Zpřístupnění, vhodnější je ale nadefinovat si spuštění/ukončení VoiceOveru na trojí stisknutí tlačítka Plochy (více informací viz VoiceOver na iOS (příručka).
Stručný návod v angličtině, jak testovat přístupnost webu s VoiceOverem, je pak k dispozici v článku Using VoiceOver to Evaluate Web Accessibility.
Android
Na zařízeních s Androidem je k testování možné použít screen reader TalkBack s prohlížečem Google Chrome (nebo nejnovějším Firefoxem). TalkBack je – stejně jako VoiceOver – nabízen jako součást operačního systému, takže jej opět stačí jen spustit přes Nastavení – Přístupnost. Bližší informace k různým možnostem spouštění viz Zapnutí aplikace TalkBack, vypnutí TalkBacku se dělá přes Nastavení > Usnadnění > TalkBack.
Při testování na iOS nebo Androidu se vám může hodit Přehled gest pro ovládání mobilních zařízení s odečítači VoiceOver a TalkBack.
Co je třeba umět
Pokud jste dočetli až sem, nejspíš to s testováním přístupnosti pomocí screen readeru myslíte opravdu vážně. Což je z obecného úhlu pohledu dobře, protože seznámení se s potřebami a způsobem práce jedné z cílových skupin určitě není na škodu. Ale pozor, není to tak snadné, jak se může na první pohled zdát. Rozhodně neplatí to, že si vezmete do ruky mobil, spustíte odečítač a začnete testovat – tak jednoduché to bohužel není, viz můj starší článek Má smysl testovat svépomocí přístupnost webu pomocí screen readeru?).
Jestliže chcete, aby takové testování za něco stálo a obdrželi jste na základě něj relevantní výsledky, je třeba se dobře seznámit s tím, jak screen readery fungují, porozumět principům, na kterých pracují, a naučit se je obsluhovat. Pomoci vám v tom mohou například tutoriály, odkazované na konci tohoto článku. Bez těchto znalostí nedává moc smysl testovat přístupnost webu tímto způsobem, protože můžete
- za problém v přístupnosti mylně považovat chyby, které ale budou způsobeny vaší neznalosti obsluhy screen readeru,
- to, že „screen reader něco čte“, vyhodnotit jako potvrzení toho, že kontrolovaný prvek je přístupný (přestože tomu tak v reálu vůbec být nemusí).
Než se tedy do testování přístupnosti pustíte, zkuste si nejprve projít výše odkazované tutoriály a pokud na to máte prostor, tak není ani věci získat širší znalosti o přístupnosti například prostřednictvím některého z MOOCů o přístupnosti, které jsou aktuálně či v dohledné době nabízeny.
Pokud byste měli k testování přístupnosti se screen readery nějaký dotaz, zkuste na něj buď najít odpověď na Testing with Screen Readers – Questions and Answers, nebo jej napište sem do komentářů.
Přehled doporučených kombinací čtečky obrazovky a prohlížeče
- MS Windows: JAWS + Google Chrome nebo Mozilla Firefox; NVDA + Mozilla Firefox
- OS X a iOS: VoiceOver + Safari
- Android: TalkBack + Google Chrome (eventuálně Mozilla Firefox)
Přehled doporučených studijních materiálů
- Testování přístupnosti webových stránek se screenreaderem JAWS
- Testování přístupnosti webových stránek se screenreaderem NVDA
- Using VoiceOver to Evaluate Web Accessibility
- Přehled gest pro ovládání mobilních zařízení s odečítači VoiceOver a TalkBack
- Má smysl testovat svépomocí přístupnost webu pomocí screen readeru?
- Testing with Screen Readers – Questions and Answers
- Dvakrát MOOC o digitální přístupnosti pro začátečníky, prosím
Původní verze článku vyšla 24. listopadu 2016.
Ještě bych přece jen zmínil také vhodnost rozšířit takové testování na komunikaci s těmi, a zpětnou vazbu od těch, kteří tyto asistivní technologie dlouhodobě a každodenně využívají v reálu, neboť právě oni budou případné výstupy, v podobě optimalizovaného projektu, prakticky používat.
Bude vývojář, nebo UX tester rozumět významu, jaký má pro nevidomého uživatele AT strukturování stránky, správně popsané formulářové prvky, které obrázky má význam opatřit doplňujícím „alt“ textem? Co pro něj znamená logicky provedená navigace v rámci webu? Zprostředkování informací typu, kam vede odkaz, jaké je povahy. A že nestačí ovládat funkční prvky pomocí myši… atd…atd.
Nechci komunitu návrhářů, vývojářů či UX testerů podceňovat, v tom, co dělají se určitě orientují na špičkové úrovni, ale když si spustí některý odečítač, a budou s ním procházet obsah, nebude to pro ně jen taková trochu ozvláštněná kuriozita? Něco jiného je si něco jen tak pro zábavu vyzkoušet, a něco jiného je být vázán na právě jen takový přístup k obsahu, který je AT zprostředkováván.
I u nás je možnost spojit se s týmem zkušených testerů a společně dospět k výsledku, který bude přinášet reálný benefit.
Martine, díky za doplnění.
Já potřebu a význam uživatelského či heuristického testování nijak nerozporuju, při vývoji webu určitě má své nezastupitelné místo. Tento článek je ale primárně určen pro frontendisty, kteří si chtějí v průběhu vývoje svépomocí otestovat nějaké vytvořené řešení. A zde se domnívám, že nechat si každý takový dílčí krok testovat „na zakázku“ není zpravidla možné jak z časových, tak ekonomických důvodů.
Aby nedocházelo k tomu, co popisujete – „když si spustí některý odečítač, a budou s ním procházet obsah, nebude to pro ně jen taková trochu ozvláštněná kuriozita“, obsahuje článek odkazy na řadu vzdělavacích materiálů + vysvětlení možných úskalí v části Co je třeba umět.
Znám několik vývojářů či webdeveloperských studíí, kteří už se s tématikou přístupnosti seznámili na slušné úrovni, začlenili ji do svého vývojového cyklu a řeší se mnou jen ty věci, se kterými už si svépomocí neporadí. Pro ně (či pro ty, kteří se chtějí podobnou cestou integrace přístupnosti vydat) má takovýto článek smysl. A pokud by situace ukázala, že bylo vhodné udělat i uživatelské testování, určitě se mu nikdo bránit nebude.