Přístupnost dynamických webových aplikací – úvod

Asistivní technologie, nové verze prohlížečů a pracovní skupina WAI u W3C pomalu boří další bariéru na webu. I dynamické webové aplikace už v poměrně blízké budoucnosti mohou být bez problémů přístupné např. pro uživatele screenreaderů. Pojďme se podívat, jaké jsou hlavní překážky RIA aplikací a jak může handicapovaným uživatelům pomoci nová specifikace WAI-ARIA a její použití na webu.

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

Nástup a rozvoj RIA s sebou přinesl mimo jiné i nové problémy a výzvy v oblasti přístupnosti. Zatímco zpřístupnit čisté HTML dnes zpravidla není při dodržování pravidel přístupnosti problém, u RIA je to trošku složitější.„Web 1.0“ byl postaven na konceptu statického obsahu, který se měnil stránku od stránky. Původní pravidla přístupnosti (například WCAG 1.0) byla napsána tak, aby odpovídala tomuto způsobu zobrazování obsahu.

Web 2.0 zahrnuje tvorbu mnohem komplikovanějších uživatelských rozhraní, která získávají informace dynamicky z různých informačních zdrojů, V reálu to tedy znamená, že stávající asistivní technologie si s dynamickými webovými aplikacemi zpravidla neporadí tak, aby je mohli bez obtíží používat i uživatelé screenreaderů.

Jaké jsou hlavní překážky dynamických webových aplikací?

  1. Problematické jsou situace, kdy při události (ať už nastane automaticky nebo jako výsledek interakce uživatele) není znovunačtena celá stránka, ale novým obsahem je nahrazena jen její část. Odečítač obrazovky je sice schopen změny identifikovat, ovšem neexistuje obecný postup, jak uživatele o těchto změnách informovat (odečítač neumí změněnou oblast implicitně pojmenovat), nehledě na to, že provedená změna může být nedůležitá a informace o ní může uživatele spíše obtěžovat, než mu být k užitku (příkladem takové nedůležité změny může být obnova reklamního banneru). V současnosti u nás běžně používané odečítače umí identifikovat a pojmenovat na základě titulku jen změny v rámech (iframe).
  2. Ovladatelnost z klávesnice. Protože webová aplikace si žádá sofistikovanější ovládání, nevystačí si jen s klasickými odkazy a potřebuje i jiné elementy k zobrazení těchto ovládacích prvků. Ty ale často při své aktivaci vyvolávají události voláním skriptu. Odkazy tedy nevyvolávají odskok na cílové místo v pravém slova smyslu, což uživatele neseznámené s prací v takové aplikaci může značně zmást. Častější je ovšem využití jiných elementů, jakými je například značka <div>, která je z hlediska skriptování nejtvárnější a která také mimo jiné postrádá jakoukoliv sémantickou informaci o svém obsahu. Události jsou potom asociovány s elementem pomocí atributu onclick, v horším případě onmouseover (událost přejetí myší nemá ekvivalent v ovládání z klávesnice). Fakt, že na element je navěšena událost při kliknutí (onclick), je schopen odečítač odhalit a nabídnout možnost simulace kliknutí na toto místo. Protože však takovému elementu není dán fokus v pravém slova smyslu, jde o  metodu, jež nemusí fungovat stoprocentně. Z nemožnosti udělit elementu fokus vyplývá, že ovládací prvek tvořený elementem <div> či jiným, určeným pouze pro prezentaci, není zahrnut do tab order (klávesou tabulátor jsou ve všech prohlížečích dosažitelné pouze odkazy a formulářové prvky).
  3. Webová aplikace dělí své rozhraní na několik obsahově specifických sekcí (navigační část, hlavní obsah, vyhledávání atp.), pro něž neexistuje jednotný způsob vyznačení v kódu. Dnes je již obvyklé používat systém navigačních odkazů na počátku stránky a uvozování jednotlivých sekcí pomocnými (skrytými) nadpisy, nicméně webová aplikace je často vyvíjena ve frameworcích a sestavována z widgetů, které nemají sémantickou stránku přizpůsobenu obsahu, což opět vychází z nasazení skriptování (masivní generování obsahu skripty).

RIA jsou proto problematické hlavně pro uživatele, kteří nejsou schopni některou z výše uvedených překážek obejít (jedná se například o uživatele screenreaderů či uživatele, kteří ovládají web pouze z klávesnice).

Gmail

Existuje řešení?

Naštěstí ano. Pokud mají být výše uvedené problémy řešeny systematicky, je nutné mít nový přístupnostní framework, který zajistí přístup k informacím na Web 2.0 webech. Takový framework už dnes existuje a schyluje se k vydání jeho finální verze. Jmenuje se WAI-ARIA a jedná se o specifikaci W3C, která si klade za cíl zpřístupnit dynamicky tvořený obsah.

ARIA poskytuje:

  • přístupné interaktivní ovládací prvky (stromové seznamy, drag & drop, posuvníky atp.);
  • možnost přiřadit jednotlivým částem stránky sémantickou informaci (tzn. autor může definovat, která část stránky je navigace, vyhledávání, hlavní obsah atp.);
  • oblasti, které mohou být dynamicky obnovovány (ve WAI-ARIA jsou nazývány jako „živé oblasti“ – live regions);
  • lepší podporu pro přístupnost z klávesnice.

Na straně klienta je pak třeba, aby tyto funkcionality dokázaly využívat prohlížeče a asistivní technologie. Z prohlížečů podporují ARIA Firefox od verze 1.5, Opera od verze 9.5, Internet Explorer verze 8 a WebKit. Z asistivních technologií pak JAWS 7 a vyšší (nejlepší podpora je ve verzi 10), Windows-Eyes 5.5 a vyšší, NVDA, ZoomText 9 a vyšší a FireVox. Podpora ARIA není ještě všudypřítomná a komplexní, ale s každou novou verzí asistivní technologie se výrazně zlepšuje (u nižších verzí asistivních technologií se jednalo spíše o dílčí podporu některých situací – například vylepšené zjišťování dynamických změn stránky u JAWS 7 bez návaznosti na ARIA, protože v té době ještě tato specifikace neexistovala).

RIA schéma

Schéma pochází ze specifikace WAI-ARIA 1.0

Jak WAI-ARIA funguje v praxi?

Závěrem tohoto článku si ukažme, že zavedení ARIA do praxe není nikterak složité. Pokud chceme RIA zpřístupnit, je třeba stránku v XHTML rozšířit o jmenný prostor atributů ARIA, které popisují struktury důležité pro přístupnost dynamických webových aplikací. V případě HTML můžeme používat ARIA atributy s prefixem „aria-“, tato možnost je ovšem validní až od HTML5:

<html lang="en" xml:lang="en"
      xmlns="http://www.w3.org/1999/xhtml"
      xmlns:aaa="http://www.w3.org/2005/07/aaa">
  ...
</html> 

Pokud například chceme vytvořit sledovanou oblast (tzv. live region), postupujeme následovně.

XHTML:

<div id="live-news" aaa:live="notify" title="novinky">
  ...
</div> 

HTML:

<div id="live-news" aria-live="notify" title="novinky">
  ...
</div> 

Daná oblast je od této chvíle sledována a pokud je její obsah změněn, bude uživatel o této změně informován.

To, jak ARIA již pomáhá v praxi, si můžete vyzkoušet za pomoci FireVoxu (open source hlasová čtečka pro Firefox) například u formuláře pro přihlášení do služby WebVisum či AJAXové výsledkové tabuli. Podporu ARIA už mají i některé aplikace Googlu, například GMail či Google Reader.

Příště si projdeme další praktické příklady a vyzkoušíme, jak si s ARIA poradí nejnovější verze screenreaderu JAWS 10, u které už by měla být podpora ARIA na solidní úrovni.

Vytváříte RIA aplikace?

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é.)

Komentáře: 11

Přehled komentářů

io clanok
Martin Hassman Re: clanok
Venca Validní dokument
Martin Hassman Re: Validní dokument
Jirka Kosek Re: Validní dokument
Venca Re: Validní dokument
Jirka Kosek Re: Validní dokument
Jirka Kosek Re: Validní dokument
Venca Re: Validní dokument
petr_p Re: Validní dokument
Jirka Kosek Re: Validní dokument
Zdroj: https://www.zdrojak.cz/?p=3003