Robustnost je čtvrtým – a současně posledním – principem doporučení WCAG 2.0. Jeho cíle ovšem nejsou z pohledu přístupnosti rozhodně až ty poslední. Čtvrtý princip je zaměřen na zajištění kompatibility se současnými i budoucími přístupovými prostředky včetně asistivních technologií na straně klienta tak, aby tyto přístupové prostředky mohly spolehlivě interpretovat obsah svým uživatelům.

Způsoby, jak toho docílit, jsou dva:

• při tvorbě obsahu nepoužívat techniky, které mohou činit asistivním technologiím problémy, či se kterými si neporadí. Negativním příkladem může být situace, kdy autor nadpisy vyznačí jen vizuálně a ne pomocí značek k tomu určených, či dochází ke křížení značek.
• správnou cestou je naopak zvolit takové postupy, při kterých je obsah uživateli předkládán standardním způsobem a asistivní technologie jej dokáží rozpoznat (text je opravdu text, nadpis je vyznačen i v kódu jako nadpis, značky jsou správně zanořeny, atp.).

Explicitní zmínění kompatibility s asistivními technologiemi osobně vnímám jako velmi důležité, protože je to věc, na kterou se při posuzování přístupnosti bohužel často zapomíná. Asistivní technologie jsou programy jako jakékoliv jiné, a mají tedy své limity, chyby, občas rozdílné způsoby zpřístupnění obsahu, atp. Proto je velmi vhodné přístupnost testovat i pomocí asistivních technologií. Jen tak je možné tyto nedostatky odhalit. V praxi totiž může nastat situace, kdy web vyhovuje formálním a technickým nárokům na přístupnost a vše se zdá být v pořádku, ale při použití asistivní technologie už tomu tak není.

K testování přístupnosti za pomoci asistivních technologií lze využít například screenreadery NVDA nebo JAWS.

Čtvrtý princip obsahuje jen jedno pravidlo, které se zabývá právě kompatibilitou.

Pravidlo 4.1 Kompatibilita

Snažte se o maximální kompatibilitu se současnými i budoucími přístupovými zařízeními včetně asistivních technologií.

4.1.1 Syntaktická analýza (Úroveň A)

Prvky, které jsou součástí obsahu, mají při použití značkovacího jazyka definovány značky pro začátek a konec, nedochází ke křížení značek, prvky neobsahují zdvojené atributy, všechny identifikátory jsou jedinečné, s výjimkou, kdy tyto vlastnosti povoluje jejich specifikace.

Cílem tohoto kritéria úspěšnosti je zajistit, aby přístupové prostředky na straně uživatele mohly korektně interpretovat a parsovat obsah. Syntaktická správnost vůči zvolené specifikaci značkovacího jazyka je proto klíčová pro správnou funkcionalitu některých výstupních zařízení. Asistivní technologie nemusejí být k chybám v syntaxi značkovacího jazyka tak tolerantní jako běžné internetové prohlížeče a vyžadují pokud možno bezchybný kód. Proto musí mít prvky značkovacího jazyka (X)HTML vždy uvedenu počáteční i koncovou značku, vyjma situace, kdy to použitá specifikace nevyžaduje. Značky také musí být správně zanořeny a nesmí docházet k jejich křížení.

Je pravdou, že situace v dnešní době už není tak „drastická“ jako před několika lety, kdy i drobná chyba v kódu často způsobila pád asistivní technologie. I přesto je ale vhodné dbát na validitu a psát kód tak, aby vyhovoval zvolené specifikaci. Velmi se tím zvyšuje šance, že si s webovou stránkou asistivní technologie bez problémů poradí. Mezi nejčastější chyby v souvislosti s tímto kritériem úspěšnosti patří:

• nesprávné (ve smyslu neodpovídající specifikaci) použití počátečních a koncových značek nebo atributů,
• zduplikování hodnot atributu ID,
• chybějící vazby mezi jednotlivými prvky (například u formulářů či tabulek).

4.1.2 Název, funkce, hodnota (Úroveň A)

U všech prvků uživatelského rozhraní zahrnující, avšak neomezující se pouze na prvky formátu a vzhledu, odkazy a prvky generované skriptem, lze název a funkce programově určit. Stavy, hodnoty nebo vlastnosti, které může nastavovat uživatel, mohou být programově nastaveny a oznámení o změnách u těchto položek je dostupné přístupovým prostředkům na straně uživatele včetně asistivních technologií.

Cílem tohoto kritéria úspěšnosti je zajistit, aby přístupové prostředky včetně asistivních technologií byly schopny získat a udržovat aktuální informace o stavu jednotlivých prvků uživatelského rozhraní.

Pokud jsou použity standardní ovládací prvky (například odkazy či tlačítka ve formulářích) v souladu se specifikací, je tento proces jednoduchý a asistivní technologie jsou schopny tyto informace bez problémů získat a předat dál uživateli.

Pokud ale autor vytvoří vlastní prvky uživatelského rozhraní tak, že mají jinou roli/funkci, než se u nich očekává, je třeba zajistit, aby tyto prvky poskytly důležité informace o svém stavu přístupovým prostředkům na straně klienta včetně asistivních technologií. Neméně důležité je také zajistit, aby takto vytvořené prvky uživatelského rozhraní bylo možné pomocí asistivních technologií ovládat.

Obzvlášť důležitým stavem prvku uživatelského rozhraní je informace, zda prvek má či nemá focus. Informace o tomto stavu musí být možné programově určit a upozornění při změně tohoto stavu musí být předáno asistivní technologii. Dalšími příklady stavů prvků uživatelského rozhraní může být například stav zaškrtávacího políčka (zatrženo/neza­trženo), přepínače (vybráno/nevybráno) nebo uzlu stromového seznamu (sbaleno/rozba­leno).

Jak tedy vyhovět požadavkům tohoto kritéria úspěšnosti? Ideální je použít standardní ovládací prvky, u kterých už se v případě, že je použijete v souladu se specifikací a s ohledem na jejich určení, nemusíte o nic dalšího starat. Asistivní technologie umí s těmito prvky pracovat a zpřístupnit je uživatelům. Jen si připomeňme, že se jedná o odkazy, formulářové prvky a rámce (frame a iframe).

Mezi nejčastější chyby v souvislosti s tímto kritériem úspěšnosti pak patří:

• použití skriptování k vytvoření ovládacího prvku pomocí elementů div a span,
• vytvoření takových ovládacích prvků, které není uživatel schopen pomocí asistivních technologií plnohodnotně obsluhovat,
• špatná (= nepřístupně vytvořená) vazba mezi ovládacím prvkem a jeho popiskem (například pouze vizuálním umístěním popisku vedle prvku),
• nedostatečná či žádná aktualizace textové alternativy při změně netextového obsahu,
• chybějící atribut alt u obrázku, pokud je obrázek jediným obsahem odkazu.

Pokud standardní prvky použít nemůžete, je situace o něco složitější,ale naštěstí už dnes existuje řešení. S tímto kritériem úspěšnosti úzce souvisí přístupnost dynamických webových aplikací a doporučení WAI-ARIA, která se právě přístupností RIA zabývá.

A to je závěr celého seriálu o WCAG 2.0.

Nezbývá mi než poděkovat kolegům – Romanu Kabelkovi za spolupráci při tvorbě videoukázek, Michalu Jelínkovi, Honzovi Šnyrychovi a Jirkovi Fenzovi za konzultace, názory a pohledy uživatelů, kteří s webem za pomoci asistivních technologií pracují. 

Prošli jsme si postupně jednotlivá pravidla metodiky a seznámili se s požadavky, které na autory kladou. Mnoho věcí z přístupnosti se v našem seriálu ale i přesto neobjevilo – soustředili jsme se jen na to nejdůležitější. WCAG 2.0 včetně souvisejících dokumentů má několik set stran, a jejich zredukování do jedenáctidílného seriálu není možné (pokud ano, tak věřím, že už by to autoři metodiky WCAG 2.0 udělali a nepsali metodiku tak obsáhlou).

Pokud vás tématika přístupnosti zaujala a chtěli byste průběžně sledovat, co je v této oblasti nového, rád bych vám na úplný závěr doporučil několik zdrojů o přístupnosti, které jsou pravidelně aktualizovány a kde se dozvíte další informace, zajímavosti a tipy. Z těch česky psaných je to blog POSLEPU, seznam těch nejzajímavějších zahraničních pak najdete v článku Accessibility Blog Roundup II na WebAIM.org.