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.
Máme menší rozepři s grafikem. On tvrdí, že text v tlačítku ve stavu disabled se řídí stejným pravidlem jako neaktivní prvky (dle W3C), a proto nemusí být dostatečně kontrastní. Já tvrdím, že i navzdory normám by bylo fajn, aby kontrastní byl. Kdo nás rozsoudí? @radlicek? Díky!
Možná si říkáte, co je to za divnou otázku v nadpisu dnešního příspěvku. Požadavky na dostatečný kontrast jsou přece jasně definovány a není moc o čem diskutovat. Nebo ano?
Na text nebo text v obrázku, který je součástí neaktivního prvku uživatelského rozhraní, se nevztahují žádné požadavky, týkající se kontrastu, píše se v Kritériu úspěšnosti 1.4.3 Minimální kontrast metodiky WCAG 2.1.
Odpověď na tuto otázku ale není tak jednoduchá, jak by se mohlo na první pohled zdát. Požadavek autorů doporučení WCAG 2.1 je věc jedna, realita věc druhá.
Neaktivní prvky sice formálně požadavku na minimální kontrast vyhovět nemusí, na druhou stranu by uživatel určitě měl mít alespoň ponětí o tom, že se v rozhraní takové prvky nachází. A pokud má problémy se zrakem, nízký kontrast může získání takové informace poměrně snadno zkomplikovat.
Jak to tedy udělat?
Není asi žádným překvapením, že – podobně jako i v jiných případech – navrhuji k řešení přistoupit pragmaticky a vyjít z dobré praxe. Změřil jsem kontrast neaktivních prvků v rozhraní některých typických aplikaci v MS Windows, a dostal jsem se na hodnotu 3:1.
Toto doporučení jsem si ověřil i jednoduchým průzkumem mezi několika slabozrakými uživateli a závěr byl jednoznačný: text neaktivního prvku by měl být čitelný (což myslím hodnota 3:1 splňuje, současně by ale mělo být zřejmé, že se jedná o neaktivní prvek (což se dá pěkně udělat právě tím, že je méně kontrastní v porovnání s texty aktivních prvků).
Schopnost otestovat si, zda web, který vytvářím, neobsahuje žádné zásadní prohřešky proti pravidlům přístupnosti, by měla patřit mezi základní dovednosti každého webdesignéra. S tím, jak si takový jednoduchý audit přístupnosti webu udělat, seznamuje diváky v následujícím videu Rob Dodson. A protože mnou doporučovaný postup vypadá až na drobnosti prakticky stejně, pojďme si ukázat, jak takový jednoduchý audit provést a na co se zaměřit.
How I do an accessibility audit — A11ycasts #11
Jednoduchý audit přístupnosti pokrývá následující stěžejní oblasti
Přístupnost a ovladatelnost prvků webové stránky z klávesnice
První věc, kterou je vhodné zkontrolovat, je přístupnost a ovladatelnost prvků z klávesnice. Klávesnice je nejdostupnější nástroj pro testování přístupnosti webu, protože i přes čím dál větší zastoupení mobilních zařízení se stále jedná o primární vstupní zařízení a každý uživatel ji má po ruce.
Jak na to? Přístupnost z klávesnice velmi jednoduše otestujeme tak, že na klávesnici začneme mačkat tabulátor. Pokud jsme se tímto způsobem schopni dostat na každý prvek a máme možnost jej z klávesnice obsloužit, pak je vše v nejlepším pořádku.
Nezapomeneme také ověřit, zda
prvek, který při ovládání z klávesnice získá focus, je dostatečně zvýrazněn a uživatel je tak vizuálně informován o tom, na jakém prvku se právě nachází.
na stránce není žádný obsah mimo viditelnou oblast obrazovky, který může nedopatřením získat focus,
Vyzkoušení jednoduché navigace po webu pomocí screen readeru
Znalost alespoň základní obsluhy některého ze screen readerů by dnes už měla také patřit mezi dovedosti tvůrců webů. Od webového vývojáře se samozřejmě neočekává, že bude znát všechny jejich funkce a bude schopen plnohodnotně nasimulovat práci nevidomého uživatele. Cílem je provést základní otestování, zda na uživatele screen readeru nečeká na webové stránce nějaká past, znemožňující mu práci s ní – tedy zda grafické prvky mají alternativní textové popisky, prvky, které slouží k interakci s uživatelem (tlačítka, rozbalovací seznamy…), je možné obsloužit, či zda dynamicky zobrazený obsah získá focus.
Více informací o tom, jaké kombinace screen readerů a prohlížečů (a jakým způsobem) používat, najdete v článcích
Strukturování webové stránky – nadpisy, oblasti stránky
Správné strukturování webové stránky korektně vyznačenými nadpisy a oblastmi stránek pomáhá uživatelům screen readerů v porozumění tomu, jak je webové stránka rozvržena. Umožňuje jim také efektivní práci s webem a nabízí možnost rychle se přesunout právě na tu část stránky, kterou potřebují. Dobře vytvořenou strukturu stránky si můžeme představit jako obsah knihy – podobně, jako z obsahu získáme představu o názvech kapitol a díky vazbě název kapitoly–číslo stránky se můžeme rychle v knize přesunout tam, kam potřebujeme, stejnou službu udělá uživateli screen readeru nadpisová osnova a oblasti stránky.
Otestovat strukturu je možné jak pomocí screen readeru, tak pomocí některého z mnoha rozšíření pro webové prohlížeče (nabízí se například Web Developer).
Bližší informace k testování pomocí screen readerů viz
Představu o tom, jak taková nadpisová osnova vypadá třeba zde na Poslepu.cz, si můžete udělat z následujícího screenshotu (uživatelé screen readerů si ji mohou vyvolat pomocí odpovídající funce svého screen readeru 🙂
Barvy a dostatečný kontrast
U jednotlivých prvků na stránce musí být zajištěn dostatečný barevný kontrast mezi popředím a pozadím tak, aby prezentované informace byly dobře čitelné. Nástrojů pro otestování dostatečného kontrastu existuje celá řada. Ve videu je doporučováno aXe extension od Deque Systems. Jedná se o jednoduché rozšíření, pomocí nějž je možné provést automatický audit stránky a nechat se upozornit na možné problémy. Jednou z testovaných oblastí je i dostatečný kontrast použitých barev.
Dalším rozšířením, které k testování používám, je Accessibility Developer Tools. Funguje podobně jako aXe extension, kromě upozornění na nedostatečný kontrast ale nabízí i doporučení, jaké barvy použít, aby byly vzájemně dostatečně kontrastní.
Pokud Vám testování kontrastu na úrovni kódu přijde příliš komplikované, doporučuji vyzkoušet Colour Contrast Analyser, který nabízí uživatelsky přívětivější rozhraní.
Otázky, na které je dobré během testování najít odpovědi
Pokud procházím stránku z klávesnice (pomocí klávesy Tab), procházím ji ve smysluplném pořadí a dostanu se na na všechny ovládací prvky na stránce?
Je prvek, který získá focus, dostatečně zvýrazněn?
Nejsou na stránce nějaké prvky mimo viditelnou oblast, na které bych se neměl při průchodu stránky z klávesnice dostat, ale přesto se na ně dostanu?
Mohu projít stránku pomocí odečítače obrazovky, aniž bych někde uvízl (tj. dostal se z klávesnice na prvek, z něhož bych nemohl odejít)?
Mají všechny grafické prvky, které nesou významovou informaci, definován smysluplný alternativní textový popisek?
Jsou custom controls (prvky stránky, vytvořené na míru) přístupné a ovladatelné i pomocí odečítače obrazovky?
Je uživatel upozorněn v případě, že se na stránce objeví nový obsah?
Má stránka definovánu smysluplnou nadpisovou osnovu?
Je stránka vhodně strukturována pomocí oblastí stránky?
Je barva textu dostatečně kontrastní oproti barvě pozadí?
Má text ve výchozím nastavení dostatečnou velikost a je dobře čitelný?
Jsou odkazy v textu dostatečně (ideálně ne pouze barvou) odlišeny od okolního textu?
Testování přístupnosti jako součást vývoje webu
Na závěr videa pak zazní doporučení, se kterým nelze než souhlasit – zahrnout průběžné testování přístupnosti jako nedílnou součást vývoje webu a tím předcházet vzniku bariér.
Závěr
Tento přehled zcela jistě není vyčerpávající a nepokrývá všechny oblasti přístupnosti. Jeho hlavní výhoda a přínos spočívá v tom, že pomocí něj lze odhalit největší překážky v přístupnosti. Po jejich odstranění se tak může z webu, který bude pro uživatele se specifickými potřebami velmi obtížně přístupný, stát web, který bude vyhovovat alespoň základním požadavkům na přístupnost.
