Archiv rubriky: Přístupnost webu

Cesta k přístupnému webu: odevzdáním výsledků auditu přístupnosti práce nekončí, ale začíná

Změna legislativy a nový Zákon o přístupnosti s sebou přinesl i zvýšenou poptávku po auditech (testech) přístupnosti webů a aplikací. Což je na jednou stranu samozřejmě dobře, na druhou je třeba říci, že audit sám o sobě z hlediska přístupnosti web či aplikaci nikam neposune, pokud se s jeho výsledky dále nepracuje (ideálně ve spolupráci s autorem auditu).

Pokud to s přístupností svého webu (či aplikace) myslíte opravdu vážně, je potřeba audit přístupnosti doplnit i dalšími navazujícími kroky.

Optimální postup

Auditů přístupnosti většího či menšího rozsahu už jsem vypracoval stovky a postupně dospěl k následujícímu postupu, který mám z hlediska výsledku a praktického přínosu pro uživatele za optimální.

1. Audit přístupnosti

Výsledky auditu slouží jako podkladový materiál k dalším krokům, které jsou pro dosažení cíle (tj. přístupnějšího webu) naprosto nezbytné. Může se samozřejmě stát, že výsledky budou uspokojivé a další kroky nebudou třeba, ale přiznejme si na rovinu, že takový stav je spíše výjimkou, než pravidlem.

2. Navazující konzultace

Ty mohou být jak osobní, tak na dálku. Dnešní technologie už naštěstí umožňují eliminovat cestování (a pošetřit čas na obou stranách), takže konzultaci je možné snadno provést přes některý z online komunikačních nástrojů, aniž by to mělo vliv na její kvalitu a názornost.

Proč jsou tyto konzultace důležité? S výsledky auditů často pracují lidé, kteří se s tématikou přístupnosti setkávají poprvé. Velmi se mi proto osvědčilo se zadavatelem auditu výsledky projít, okomentovat je, zodopovědět případné dotazy a přesvědčit se, zda je všechno pochopeno tak, jak by pochopeno být mělo.

3. Workshop(y) o přístupnosti

Přístupnost se na straně zadavatele zpravidla netýká jen jednoho člověka, ale má na ni vliv celá řada lidí různých profesí: namátkou UX designer, grafik, kodér či redaktor. Proto je vhodné se s týmem na straně zadavatele auditu (ideálně osobně) sejít, s tématikou přístupnosti jej seznámit a při té příležitosti s ním výsledky auditu projít.

Workshop také může sloužit jako platforma pro stanovení nejbližších dalších kroků a domluvě na tom, co, kdy a jak se bude upravovat. Ne vždy je možné (z mnoha důvodů – zvolená technologie, časové či finanční možnosti) implementovat okamžitě všechny požadované změny. Ideální je proto domluvit se na prioritách a opravách největších bariér co nejdříve (nepopsané obrázky ve fotogalerii jsou sice problém, ale nepřístupnost položek menu z klávesnice či absence nadpisové osnovy jsou pro uživatele překážky mnohem závažnější).

4. Zmírnění či odstranění nalezených bariér

Na základě stanovení priorit proběhne zmírnění (či odstranění) bariér, které provede zadavatel auditu. Tato činnost může trvat dny, týdny i měsíce v závislosti na jejich složitosti, volných vývojových kapacitách, rozpočtu, či dalších okolnostech – pokud je například třeba některé komponenty nově naprogramovat a otestovat jejich funkčnost, či je přístupnost součástí vývojového cyklu a opravy se tak do produkční verze dostanou až s další verzí webu či aplikace.

5. Kontrola

Po provedení úprav je vhodné zkontrolovat, zda jsou úpravy dostačující, jejich výsledkem je odstranění (či zmírnění) nalezené bariéry a v důsledku toho přístupnější web či aplikace.

Body 2 až 5 pak lze po první úspěšné iteraci samozřejmě libovolně opakovat a kombinovat 🙂

Zpřístupnění webu je proces, ne jednorázová aktivita

Už na začátku spolupráce je vhodné upozornit zájemce o zpřístupnění webu či aplikace na to, že zpřístupnění webu či aplikace je proces, který mnohdy trvá i několik měsíců. A pokud se má jednat o změnu dlouhodobou a trvalou, je potřeba proškolit i zaměstance a začlenit tak přístupnost do “DNA” týmu, který web či aplikaci vyvíjí a průběžně aktualizuje.

A není to pak celé (mnohonásobně) dražší?

Může, ale nutně nemusí. Výslednou cenu ovlivňuje celá řada faktorů a řada věcí se dá díky možnostem dnešních technologií udělat jednodušeji (a v důsledku toho levněji). Například výsledky auditu je možné nabídnout prostřednictvím sdíleného dokumentu, který může následně posloužit jako podklad ke konzultacím (či konzultace mohou probíhat přímo v něm) a jako osnova workshopu. A finance, ušetřené za mnohdy desítky hodin věnovaných zpracování detailní formální zprávy, mohou být investovány třeba do workshopu a zvýšení kompetencí členů pracovního týmu v oblasti přístupnosti.

Příklady dobré praxe

Nejlepším důkazem toho, že výše nastíněný postup funguje, jsou jeho praktické výsledky. Za všechny zmíním alespoň dlouhodobou spolupráci na zpřístupňování webu s výsledky voleb, webu a online bankovnictví jedné velké banky či přístupnější online supermarket Rohlík.cz 🙂

Audit přístupnosti: co vše by měla obsahovat závěrečná zpráva

Audit (analýza, či test) přístupnosti je jedním z nástrojů, který pomáhá zlepšit přístupnost vašeho webu či aplikace. Může posloužit jako zdroj zpětné vazby k aktuálnímu stavu přístupnosti a poskytnout rady a tipy, co vylepšit, aby testovaný web či aplikace neobsahoval žádné vážné překážky v přístupnosti, které by uživatelům mohly znesnadňovat (či dokonce znemožňovat) web či aplikaci používat.

Co vše by měla závěrečná zpráva z auditu přístupnosti obsahovat, aby byla pro toho, kdo ji bude číst a dále s ní pracovat, skutečně přínosná?

Obecné informace a formální náležitosti

Název webu či aplikace a rozsah auditu

Informace o tom, co bylo předmětem auditu, je samozřejmě zcela zásadní. S ohledem na rozsah většiny dnešních webů zpravidla není možné (a ani účelné) otestovat každou publikovanou stránku. Běžný postup je takový, že se vybere reprezentativní vzorek stránek, postavených na různých šablonách (těch zpravidla nebývá více než deset) a ty se zanalyzují z pohledu přístupnosti.

U mobilních aplikací je kromě rozsahu testu vhodné uvést, jaké verze aplikace a pro jaký mobilní operační systém byla testována. Často se stává, že aplikaci pro různé platformy vyvíjejí různé týmy, takže se může snadno přihodit, že zatímco aplikace pro iOS je bez větších obtíží přístupná, aplikace pro Android obsahuje vážné bariéry v přístupnosti, a naopak.

Pokud je heuristická analýza přístupnosti doplněna uživatelským testem typických scénářů (nákup zboží na e-shopu, nastavení trvalé platby v internetovém bankovnictví, atp.) – což u aplikací (ať už webových, nebo mobilních) je prakticky povinnost – i tuto skutečnost je třeba v závěrečné zprávě z auditu uvést (včetně výčtu konkrétních scénářů, které byly testovány).

Zhotovitel a realizační tým

Neméně důležité je také uvést, kdo za auditem stojí. Ideálně včetně jmen členů realizačního týmu, jejich kompetencí takový audit provést, a kontaktních údajů, na které se mohou čtenáři zprávy s výsledky auditu obrátit v případě, kdy jim ve zprávě něco nebude jasné.

Časové údaje

Audit by měl obsahovat i informaci o tom, kdy analýza přístupnosti proběhla a k jakému datu jsou výsledky auditu přístupnosti relevantní.

Jakým způsobem a s jakými nástroji byl audit proveden

Možností, jak audit provést, se nabízí celá řada. Jeho součástí tak musí být informace o tom,

byl audit proveden.

Pokud bylo jeho součástí i uživatelské testování vybraných scénářů (například objednávky zboží na e-shopu, vyhledání konkrétní informace, atp.), pak je i toto vhodné uvést (včetně výčtu konkrétních scénářů, které byly testovány, a informací o uživatelích, kteří testování provedli).

Vlastní obsah zprávy s výsledky auditu

Manažerské shrnutí výsledků

Stručné shrnutí (přibližně na 1 až 2 A4) nabídne zadavateli snadno dostupnou a srozumitelnou informaci o výsledku analýzy přístupnosti, umožní mu udělat si představu o aktuálním stavu přístupnosti auditovaného webu a bariérách, které se na něm nacházejí.

Výsledky analýzy přístupnosti a doporučení k nápravě

Jedná se o stěžejní část dokumentu s výsledky auditu přístupnosti. Jejím obsahem je detailní popis

  • oblastí, které byly testovány,
  • popis aktuálního stavu,
  • míry závažnosti jednotlivých bariér (chybějící alternativní popisek u fotky ve fotogalerii bude s největší pravděpodobností menší překážkou než chybějící popisek u tlačítka ve formuláři),
  • návrhů na odstranění potencionálních bariér včetně odkazů na ukázky možných řešení.

Nelze předpokládat, že každý čtenář je odborníkem na problematiku, která je v závěrečné zprávě prezentována. Při psaní této (z hlediska věcného přínosu stěžejní) části zprávy je třeba mít na paměti to, že pro řadu těch, kdo ji budou číst, se bude pravděpodobně jednat o první detailnější seznámení s tématikou přístupnosti. Proto je nutné nabídnout popis výsledků auditu maximálně věcný, názorný a srozumitelný i pro tuto skupinu čtenářů.

Doplňující informace

Ne vždy je psaný text tou nejlepší cestou, jak konkrétní problém příjemci auditu srozumitelně popsat. Proto je občas užitečné danou situaci zprostředkovat například prostřednictvím audio či video záznamu (ten se díky dnešním technologickým možnostem dá pořídit i mobilním telefonem). K větší názornosti mohou také pomoci screenshoty stránek s popisovanými situacemi či přehledová tabulka s vyznačením výskytu jednotlivých bariér na testovaných stránkách.

Odkazy na další zdroje

Důležité je také všechny popisované oblasti řádně ozdrojovat a čtenářům nabídnout odkazy na relevantní zdroje k přístupnosti jak obecného, tak konkrétního charakteru.

Poděkování, kontaktní informace

Závěrem nezbývá než poděkovat za zájem o tématiku přístupnosti a nabídnout kontakt na někoho, s kým může zadavatel komunikovat v případě, kdy má k výsledkům auditu nějaké otázky.


Další informace k tématu najdete na stránce Evaluating Web Accessibility Overview.

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

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

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ů


Původní verze článku vyšla 24. listopadu 2016.