Přejít k navigační liště

Zdroják » Webdesign » Testování přístupnosti webu: doporučené kombinace screen readeru a prohlížeče

Testování přístupnosti webu: doporučené kombinace screen readeru a prohlížeče

Články Webdesign

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:

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í 40minutovou 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.

Roman Kabelka, lektor workshopu Úvod do tvorby webu v redakčním systému WordPress

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ů

Komentáře

Odebírat
Upozornit na
guest
0 Komentářů
Nejstarší
Nejnovější Nejvíce hlasů

Proč vám model napíše Python, i když jste si řekli o Rust

AI
Komentáře: 0
Výkonnostní propast mezi Pythonem a ostatními jazyky se za poslední rok a půl skoro zavřela. Dnešní modely zvládají Rust i Go srovnatelně dobře. Když jim ale volbu necháte, sáhnou stejně po Pythonu. A u knihoven je to ještě výraznější: mezi funkčně srovnatelnými balíčky je až 84procentní rozdíl v kvalitě generovaného kódu. Proč to tak je a co s tím.

WP2Shell: Kritická hrozba pro samotné jádro WordPressu. Útočníci mohou získat kontrolu nad webem

Zranitelnost ve WordPressu není žádná novinka. Kdo provozuje weby postavené na této platformě, ví, že bezpečnostní záplaty chodí prakticky pořád. O to větší pozornost by měla vzbudit chyba, u které nic z toho neplatí. A přesně takový je případ zranitelnosti, která dostala přezdívku wp2shell. potřeb. Zranitelný kontaktní formulář, děravý e-shopový plugin, opomenutá kontrola oprávnění v nějaké obskurní rozšiřující knihovně – to je denní chleba každého, kdo sleduje bezpečnostní feedy. Zpráva „nová chyba ve WordPress pluginu“ má tak nízkou informační hodnotu, že ji většina lidí přejde bez mrknutí oka.

Mýtus jedné aplikace: proč PWA nenahradí vývoj pro každou platformu

PWA mohou webu přidat ikonu na ploše, fungování bez připojení, notifikace a některé systémové funkce. Nejsou ale cestou k jednomu klientu pro všechny platformy. Vyplatí se tam, kde se lidé k webu vracejí a ocení okamžitý vstup z odkazu. Jakmile aplikace musí spolehlivě běžet na pozadí nebo fungovat stejně na každém zařízení, bývá vhodnější nativní řešení.