Main content

VYUŽITÍ NOVÝCH TECHNOLOGIÍ: Jak testovat přístupnost webu. 1. část

RADEK PAVLÍČEK radek.pavlicek@gmail.com

Tematika přístupnosti jistě není pracovníkům knihoven cizí. Už roky se s ní mohou potkávat na celé řadě akcí (namátkou například na konferenci Elektronické služby knihoven ve Zlíně), přístupnost je jedním z kritérií soutěže Biblioweb či tu máme metodickou příručku pro práci knihoven s uživateli s postižením o Standardu Handicap Friendly. Z nejnovějších počinů v této oblasti bych rád zmínil příručku pro knihovny s názvem Přístupné webové stránky, kterou její autorka Eva Cerniňáková představuje v tomto čísle Čtenáře na stranách 60–63.

Jak už napovídá název článku, který právě čtete, podíváme se dnes společně na to, proč, čím a jak přístupnost testovat. Možná se ptáte, k čemu vám tato dovednost bude dobrá a zda není lepší takové testování svěřit odborníkům. Přístupnost se v tomto nijak neliší od jiných oborů lidské činnosti. Jako běžně nejezdíme s autem do autorizovaného servisu kvůli dohuštění pneumatik či dolití kapaliny do ostřikovačů (to jsou činnosti, které obvykle zvládáme svépomocí), je možné i u přístupnosti řadu věcí otestovat svépomocí a odborníky přizvat pouze v případě, kdy už na danou věc naše dovednosti nestačí.

Jak můžeme k testování webu přistoupit?

Hlavní důvody, proč budeme chtít otestovat svůj web na bezbariérovost, mohou být dva:

praktický: potřebujeme zjistit, zda náš web neklade uživatelům nějaké překážky;

legislativní: potřebujeme zjistit, zda (a v jaké míře) náš web vyhovuje aktuálním legislativním požadavkům (jen pro pořádek připomeňme, že 9. 4. 2019 vstoupil v platnost zákon o přístupnosti, který se týká i knihoven).

Cesty, kterými se můžeme vydat, jsou dvě: testovat můžeme svépomocí nebo můžeme testování zadat jako zakázku třetí straně (podle potřeby je můžeme kombinovat). Pojďme si nyní blíže rozebrat, co jednotlivé způsoby testování obnášejí.

Testování svépomocí

Zpravidla má tyto rysy – je:

levnější: vkládáme do něho „jen“ svůj čas, nemusíme platit služby agentury a veškerou režii okolo;

rychlejší: autor zná svůj web a jeho potenciální slabá místa nejlépe; ví, na co se zaměřit a kde by mohly být bariéry;

časově dostupnější: vzhledem k aktuálně platné legislativě narostla poptávka po analýzách přístupnosti; je tedy dost pravděpodobné, že si na analýzu přístupnosti, provedenou třetí stranou, budeme muset nějakou chvíli počkat;

— vyžaduje odpovídající know-how (kompetence) v oblasti přístupnosti k tomu, co chceme svépomocí testovat.

Pokud chceme mít větší jistotu, že uživatelé na našem webu na bariéry nenarážejí, je testování svépomocí vhodné doplnit testováním uživateli s handicapem. V neposlední řadě jistě platí, že u složitějších věcí může být/je potřebná konzultace s odborníkem (budeme-li se držet našeho příměru s provozováním automobilu, výměnu brzdových destiček už nebudeme řešit svépomocí, ale svěříme ji servisu).

Testování třetí stranou

Testy (analýzy) přístupnosti dnes nabízí celá řada subjektů: najdeme mezi nimi agentury, neziskové organizace, živnostníky, vzdělávací instituce atp.

Co mohu od testování třetí stranou očekávat?

Garantované know-how: samozřejmě v případě, když si vyberu správného partnera; vodítkem pro jeho výběr může být například získaná certifikace (v oblasti přístupnosti je nejrozšířenější a celosvětově uznávanou certifikace od Mezinárodní asociace specialistů na přístupnost; u webu budeme nejspíš poptávat držitele certifikátu Certified Professional in Web Accessibility), reference, prokazatelné výsledky či publikační a prezentační činnost.

Zpravidla je (násobně) dražší: v porovnání s testováním svépomocí stojí tato služba výrazně více (cena analýzy webu se pohybuje od 10 000 do 30 000 korun podle toho, u jakého subjektu si službu objednáme).

Aktuálně horší dostupnost: jak už jsem zmiňoval, v současné době je po tomto typu služeb poměrně velká poptávka a zároveň je málo poskytovatelů, kteří tuto službu jsou schopni nabídnout v odpovídající kvalitě, tedy těch, kteří nedělají „audit pro audit“, ale snaží se být zadavateli partnerem a společně docílit zlepšení přístupnosti webu.

Nedá se udělat na klíč: pokud chceme, aby výsledkem spolupráce byl nejen soupis konkrétních kroků, které povedou ke zlepšení přístupnosti, ale hlavně jejich následné zapracování, musíme se na testování spolupodílet, přinejmenším definicí scénářů, podle kterých se bude web testovat, poukázáním na potenciální slabá místa a součinností při stanovování priorit a hledání kompromisů.

Automatické validátory

Možná už jste narazili na některý z online nástrojů, který nabízí na jedno potvrzení tlačítka otestování webu na přístupnost. Naprosto logicky se zeptáte, zda by nebylo možné použít některý z těchto nástrojů, a usnadnit si tak práci (a ušetřit nějaké finance). Možné to samozřejmě je, nicméně musíme mít na paměti, že automatické validátory jsou dobrý sluha, ale zlý pán, a jako k takovým k nim přistupovat.

V čem jsou jejich úskalí?

Žádný takový nástroj neumí o webu říci, zda je (či není) přístupný. Nenechme se tedy ukolébat výstupy, které poskytuje například Lighthouse. Obvykle totiž za nimi následuje sekce nazvaná jako „Další oblasti k manuální kontrole“, kterou nemůžeme ignorovat, ale naopak je potřeba se jí věnovat a body v ní manuálně zkontrolovat.

Tyto nástroje neumí zkontrolovat vše, co je třeba zkontrolovat. Uvádí se, že z kritérií úspěšnosti doporučení Web Content Accessibility Guidelines (která jsou celosvětově uznávaným standardem v této oblasti a odkazuje na ně i česká legislativa) lze plně automaticky zkontrolovat pouze 25 % kritérií úrovně A a 17 % úrovně AA. Všechna ostatní vyžadují manuální kontrolu nebo plně manuální otestování.

Automatické validátory také neumějí stanovit závažnost daného nálezu v kontextu webu. Nástroj nás tedy například upozorní na málo kontrastní barevnou kombinaci nezávisle na tom, jestli se jedná o text hlavního obsahu stránky, nebo drobnou a nedůležitou poznámku v patičce. Na nás pak je, abychom tyto výsledky správně interpretovali a jednotlivým nálezům přiřadili odpovídající váhu.

Automatické validátory lze tedy s úspěchem použít k usnadnění práce a odhalení těch problematických oblastí, které tímto způsobem lze odhalit (a v další části našeho cyklu si to i ukážeme). Ale spolehnout se pouze na jejich výstupy by nebylo z výše nastíněných důvodů moudré.

Klíčová znalost potřeb a způsobu práce uživatelů s webem

Naprosto stěžejní dovedností k tomu, abychom mohli weby svépomocí testovat, je mít dobré povědomí o tom, jak s webem pracují uživatelé s handicapem (ať už dočasným, či trvalým). Tedy jaké potřeby mají čtyři stěžejní skupiny uživatelů, kvůli kterým přístupnost vznikla: uživatelé s tělesným, zrakovým či sluchovým postižením a uživatelé s kognitivními poruchami.

Bez těchto znalostí nebudeme schopni jednak identifikovat potenciální bariéry, jednak navrhovat smysluplná opatření vedoucí ke zmírnění či odstranění bariér. Je třeba vědět, jak tyto skupiny uživatelů pracují s webem, jaké asistivní technologie – a jak – používají, jak si případně nastavují prostředí operačního systému či prohlížeče. A současně si uvědomit, že pravděpodobně není různorodějších skupin z hlediska potřeb než ty, které jsme vyjmenovali, a že se dokonce občas může stát, že jejich požadavky i půjdou proti sobě (například uživatelům s kognitivními poruchami mohou orientaci usnadnit vhodně zvolené piktogramy, se kterými ale nemohou vizuálně pracovat uživatelé nevidomí). Naštěstí web je prostor, kde lze tyto (občas protichůdné) potřeby snadno uspokojit (například tím, že těm piktogramům definuji relevantní alternativní textové popisky).

Bližší informace o potřebách jednotlivých skupin uživatelů lze v případě zájmu najít ve zmiňované příručce Přístupné webové stránky v kapitole Uživatelé a přístupnost.

Co vše má vliv na přístupnost?

Na závěr se s vámi podělím o jednu informaci, o které se obecně moc neví, ale která je z hlediska přístupnosti velmi důležitá. Míru přístupnosti, resp. její vnímání konkrétním uživatelem, totiž neurčuje jenom přístupnost webového rozhraní, ale je výsledkem nejméně čtyř faktorů:

— stavu přístupnosti webového rozhraní;

— použité asistivní technologie či nastavení prostředí na straně uživatele;

— použitého webového prohlížeče uživatelem;

— kompetencí (míry digitální gramotnosti) uživatele v práci s webem a s asistivní technologií.

To, že nám uživatel hlásí problém s přístupností webového rozhraní, ještě vůbec nemusí znamenat, že bariéra je v rozhraní samotném. Pokud na web uživatel přistupuje například s pět let starou verzí asistivní technologie (například odečítače obrazovky) a k tomu má zastaralý/nepodporovaný webový prohlížeč, je docela pravděpodobné, že tato kombinace mu nemusí poskytnout takový uživatelský prožitek, jaký očekává. Pokud bychom se opět přidrželi analogie s vlastnictvím automobilu, pak to, že jsem se na cestu vydal třicet let starým Favoritem a že požitek z jízdy není takový, jako kdybych jel Superbem, je nasnadě. Za to za běžných okolností nemůže kvalita vozovky, po které jedu, ale právě zvolený dopravní prostředek.

Příště si naši testovací dílnu vybavíme potřebnými nástroji a ukážeme si, jak je používat k testování stěžejních oblastí z hlediska přístupnosti, které lze bez větších obtíží otestovat svépomocí.