Archiv štítku: kontrast

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.

Musí být text neaktivního prvku rozhraní dostatečně kontrastní?

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

Asi nejlépe jsou možné úhly pohledu shrnuty v článku Do disabled buttons still need to be contrast compliant for accessibility?, ze širšího úhlu pohledu se pak tématice neaktvních prvků v rozhraní věnuje Hampus Sethfors v článku Disabled buttons suck.

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ů).

Další čtení k tématu

Jak na jednoduchý audit přístupnosti – otestujte si bezbariérovost svého webu

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,
  • na stránce jsou k dispozici přeskakovací (skip to) odkazy.

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

Adam na workshopu JAWS a braille

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.

Další informace lze najít v článcích Jak definovat strukturu v HTML a proč jsem začal mít rád HTML5 tagy a Jak přístupně strukturovat webovou stránku pomocí nadpisů – praktický návod.

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 🙂

Poslepu.cz: ukázka nadpisové osnovy

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.