Archiv rubriky: Příručka

A11y Color Palette: nástroj pro měření kontrastu barev

Máte k dispozici paletu barev a potřebujete z ní vybrat takové kombinace, které jsou vzájemně dostatečně kontrastní? Šikovným nástrojem, který může tuto činnost usnadnit, během chvilky porovnat vzájemný kontrast zadaných barev a vyhodnotit jejich soulad s požadavky metodiky WCAG 2.1 na dostatečný barevný kontrast, je A11y Color Palette.

Požadavky na minimální kontrast

  • AA běžný / velký text: 4,5:1 / 3:1 – minimální kontrastní poměr pro běžné písmo do velikosti 18 bodů nebo tučné písmo do velikosti 14 bodů je 4,5:1. Pro běžné písmo nad 18 bodů nebo tučné písmo nad 14 bodů je minimální kontrastní poměr 3:1.
  • AA netextové objekty: 3:1 – pro prvky uživatelského rozhraní a grafické objekty je minimální kontrastní poměr 3:1
  • AAA běžný / velký text: 7:1 / 4,5:1 – minimální kontrastní poměr pro běžné písmo do velikosti 18 bodů nebo tučné písmo do velikosti 14 bodů je 7:1. Pro běžné písmo nad 18 bodů nebo tučné písmo nad 14 bodů je minimální kontrastní poměr 4,5:1.

Hodnoty AA a AAA vyjadřují míru důležitosti (hodnota AA v kontextu metodiky WCAG 2.1 odpovídá střední úrovni, hodnota AAA úrovni nejnižší).

Jak nástroj funguje?

Jeho použití je velmi jednoduché. Nástroj (nebo chcete-li jednoduchou webovou aplikaci) najdete na adrese a11yrocks.com/colorPalette/. Do editačního pole Colors (comma separated HEX) zadáte hexadecimální kód barev, jejichž vzájemný kontrast chcete porovnat (nástroj k nim automaticky přidá černou a bílou), potvrdíte tlačítko Create Palette a to je vše.

A11y Color Palette jako výsledek vrátí paletu dvojic barevných kombinací, které jsou seřazeny podle míry vzájemného kontrastu (čím jsou barvy vzájemně kontrastnější, tím jsou v tabulce výše). Kromě vizuální reprezentace obsahuje každá dvojice i informace textové:

  • 21:1 – hodnota kontrastního poměru
  • level of compliance – míra shody
    • AA normal / large – vyhovuje požadavku úrovně AA na minimální kontrast pro běžný text a velký text.
    • AA non-text – vyhovuje požadavku na minimální barevný kontrast pro prvky rozhraní a grafické objekty.
    • AAA normal / large – vyhovuje požadavku úrovně AAA na minimální kontrast pro běžný text a velký text.

Z takto nabídnutých výsledků je pak již poměrně snadné vybrat barevné kombinace, které jsou pro požadovaný účel (normální text, velký text, prvky rozhraní) dostatečně kontrastní.

Pokud bychom některou z barevných kombinací rádi použili, ale její vzájemný kontrast není dostatečný, můžeme k nalezení podobné, ale vyhovující kombinace, použít například tanaguru contrast finder.

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.