Přístupnost RIA – dynamické změny obsahu

Dnešní díl seriálu o přístupnosti RIA bude věnován problematice dynamických změn obsahu stránek, které mohou představovat pro screenreadery značný oříšek. Seznámíme se s tím, jak při jejich zpřístupnění pomáhá WAI-ARIA, a vyzkoušíme si, jak si s nimi nakonec v reálu poradí screenreader JAWS ve verzi 10.

Seriál: Přístupnost dynamických webových aplikací (4 díly)

  1. Přístupnost dynamických webových aplikací – úvod 6.5.2009
  2. Přístupnost RIA – strukturování dokumentu a přístupnost z klávesnice 10.6.2009
  3. Přístupnost RIA – dynamické změny obsahu 10.7.2009
  4. Přístupnost RIA – přístupnost widgetů 21.9.2009

Dynamické změny obsahu mohou z hlediska přístupnosti působit velké problémy. Uživateli screenreaderu, který nemá vizuální kontrolu nad tím, co se děje v různých částech stránky, mohou kvůli dynamickým změnám obsahu unikat důležité informace. Typickou situací, kdy se tak dnes děje, je například chybějící informace o průběhu uploadu souboru na www.edisk.cz či informace o další osobě, která edituje stejný dokument v Google Docs.

Přístupnost RIA

Screenreadery už sice dnes nabízí funkci, umožňující změnit způsob sledování a vyčítání změn na obrazovce, ale ten nelze vždy s úspěchem pro sledování dynamických změn obsahu použít. Při standardní práci jsou uživateli čteny pouze vysvícené položky – tento způsob oznamování změn zaručuje, že při ovládání PC z klávesnice je uživateli vždy přečtena právě ta položka, která má focus. Pokud si uživatel změní způsob sledování a vyčítání položek na vše, jsou mu ohlašovány všechny změny, ke kterým dochází ve viditelné části obrazovky. Tímto způsobem si tedy může nechat vyčítat dynamické změny obsahu i přesto, že autor stránky na ně neupozorňuje, ale má to jeden háček. Kvůli tomu, že je sledována celá viditelná část obrazovky, občas uslyší i to, co nechce – například změnu minut/hodin u systémového času. Případně – pokud je na stránce dynamicky měněných oblastí víc – jsou uživateli změny z různých oblastí hlášeny tak, jak se na obrazovce objevují, což může mít za následek, že uživatel nepozná, k čemu který údaj patří, a nebude schopen se v hlášeních zorientovat.

Nastavení JAWS

Problém je tedy vhodné řešit na straně tvůrce stránky a i zde může pomoci WAI-ARIA.

Živé oblasti (Live Regions)

Specifikace WAI-ARIA nabízí tvůrci stránky možnost definovat oblasti, jejichž obsah se dynamicky mění, jako tzv. živé oblasti. Živá oblast umožňuje dynamické změny obsahu, které umí screenreader zachytit a informovat o nich uživatele. Vytvoření živé oblasti je jednoduché – konkrétnímu prvku stačí přiřadit atribut aria-live s hodnotou off, polite nebo assertive. Hodnota specifikuje, co by měl screenreader udělat v případě, kdy dojde k aktualizaci obsahu prvku.

Projděme si nyní jednotlivé hodnoty podrobněji a podívejme se, jak si s takto definovanými oblastmi poradí screenreader JAWS ve verzi 10. Pro testování opět použijeme příklady z webu CodeTalks.

aria-live=„off“

Hodnota off je hodnota výchozí a říká screenreaderu, aby změnu obsahu prvku neohlašoval. Informaci o obsahu prvku se uživatel dozví až tehdy, kdy se na něj přesune, a uživateli je přečtena pouze aktuální hodnota prvku. Na první pohled (či poslech) tedy ani nemusí poznat, že se jedná o oblast stránky, jejíž obsah se mění.

Hodnotu off je vhodné použít u prvků, jejichž změna obsahu není důležitá a uživatele by spíše rušila, než mu byla k užitku. Stejně tak je vhodné ji použít i v případě, kdy ke změnám dochází velmi rychle (například GPS souřadnice jedoucího automobilu) a jejich neustálé ohlašování by opět bylo spíše kontraproduktivní.

Pokud se podíváme na stránku s příkladem použití živé oblasti s hodnotou off, tak se na ní JAWS 10 chová tak, jak se od něj očekává. Aktuální obsah prvku přečte pouze v případě, kdy se na něj uživatel přemístí a během dalšího procházení/čtení stránky již není změna obsahu prvku ohlašována.

aria-live=„polite“

U prvků, jejichž aria-live hodnota je nastavena na polite, by mělo dojít k upozornění na změnu obsahu prvku pouze ve chvíli, kdy uživatel právě nedělá nic jiného. Polite má vyšší prioritu než off, ale nižší než assertive. Hodnota polite se pro změny obsahu bude pravděpodobně používat nejčastěji, obzvlášť v situacích, jakými je změna statusu, chat, u nových titulků zpráv, atp.

Na stránce s příkladem použití živé oblasti s hodnotou polite se JAWS opět chová tak, jak by měl – aktuální obsah prvku přečte pouze v případě, kdy se na něj uživatel přemístí a během procházení/čtení stránky již není změna obsahu prvku ohlašována. K dalšímu ohlášení obsahu prvku dojde až ve chvíli, kdy uživatel se stránkou nijak nepracuje – tzn. například skončí plynulé čtení celého obsahu stránky či při procházení stránky skončí čtení aktuálního prvku.

aria-live=„assertive“

Změny, ke kterým dochází u prvků s hodnotou assertive, jsou natolik důležité, že by měly být uživateli oznámeny co nejdříve, není ale bezpodmínečně nutné uživateli okamžitě přerušit stávající práci. Tato hodnota musí být použita u důležitých změn obsahu, jakými jsou například chybové hlášky ve formulářích, u nichž jsou během vyplňování průběžně kontrolovány zadávané hodnoty.

U testovacího příkladu živé oblasti s hodnotou assertive se JAWS chová identicky, jako na stránce s hodnotou polite. Dynamické změny obsahu nijak neruší plynulé čtení, ačkoliv v popisu očekávaného chování je zmíněna možnost ohlášení aktuální hodnoty například před zahájením čtení nové věty. Což by – vzhledem k důležitosti takto vyznačených změn – bylo chování vhodnější.

Ukázali jsme si, jak WAI-ARIA může velmi snadno pomoci vyřešit informování o dynamických změnách obsahu. Tímto exkurzi mezi živé oblasti ukončíme, příště se podíváme na to, jak WAI-ARIA pomáhá při zpřístupnění widgetů.

Radek vystudoval informatiku na Fakultě informatiky Masarykovy univerzity v Brně. Od roku 1998 se věnuje speciální informatice pro lidi s těžkým postižením zraku.

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Zatím nebyl přidán žádný komentář, buďte první!

Přidat komentář
Zdroj: https://www.zdrojak.cz/?p=3047