Color Contrast Analyzer: rozšíření na testování kontrastu pro Google Chrome

Pro testování dostatečného kontrastu barev lze v současné době použít celou řadu nástrojů. Ten, který bychom Vám rádi dnes představili, funguje jako rozšíření pro Google Chrome, jmenuje se Color Contrast Analyzer a vyvinuli jej v IT Accessibility Office na NC State University.

Nástroj funguje na principu analýzy snímku obrazovky, určuje pixel po pixelu, kde se mění kontrast a ověřuje shodu s danou úrovní standardu WCAG 2.0. Což mimo jiné přináší tu výhodu, že je možné pomocí něj jednoduše testovat texty v obrázcích a texty, které mají jako pozadí barevný přechod nebo obrázek. K otestování je možné si vybrat

• určitou část stránky (zde jsem narazil na problém, že je možné výběr udělat pouze nad přehybem stránky),
• viditelnou část stránky,
• celou webovou stránku.

Výsledkem analýzy je zobrazení náhledu stránky se zvýrazněním prvků, které splňují danou úroveň shody se standardem WCAG 2.0.

Jak nástroj používat

Po stažení rozšíření se na panelu Chrome objeví jeho ikona (Chrome doporučuji restartovat, aby byly k dispozici všechny funkce tohoto rozšíření). Po načtení stránky, kterou chceme zkontrolovat, si aktivací ikonky otevřeme menu s možnostmi volby rozsahu testované oblasti. Pokud zvolíme „Celou stránku“, spustíme test s přednastavenými hodnotami. Zvolíme-li „Vymezit oblast stránky“ (Capture Page Region), zobrazí se na stránce výběrové okno, které můžete přesouvat, měnit mu velikost a vybrat si tak jen tu oblast, kterou chceme testovat. Test spustíme potvrzením tlačítka O.K. Tato možnost je výhodná, chceme-li zkontrolovat jen určitou část stránky, protože výrazně zkrátí čas testu.

V Nastavení (Options) můžeme zvolit vyhodnocení shody s doporučením WCAG 2.0 pro úrovně AA nebo AAA.

Po skončení testu se zobrazí stránka překrytá šedou maskou, z níž vystupují pouze ty prvky, u kterých jsou hranice mezi barvami natolik odlišné, aby splňovaly zvolené požadavky na dostatečný kontrast. Jestliže je nějaký vizuální prvek na stránce, který není zobrazen na výstupní masce, pak tento prvek stránky není dostatečně kontrastní vzhledem k parametrům, podle kterých kontrast testujeme.

Metodika WCAG 2.0 používá pro měření dostatečného vzájemného kontrastu barev algoritmus světelnosti, u kterého kromě použitých barev hraje roli i velikost písma. Nástroj s ní ale nepočítá a její změření je tak na nás. Jak na to je možné se dočíst například v článku Jak změřit velikost písma na webové stránce.

Další možnosti

Kromě webových stránek lze tímto způsobem analyzovat téměř jakýkoliv soubor, který umí Chrome otevřít: jedná se například o formáty JPEG, PNG a PDF. U PDF souborů je analýza omezena pouze na viditelnou část dokumentu.

Doporučení WCAG 2.0 pro dostatečný kontrastní poměr se týkají pouze k textu. Nástroj ale umí odhalovat i případné chyby u netextových položek, jakými jsou například okraje formulářových prvků či ohraničení položek v menu, protože i u těchto objektů - přestože jejich dostatečný kontrast WCAG 2.0 nijak neřeší - je jejich zvýraznění užitečné.

Videoukázka práce s rozšířením Colour Contrast Analyzer

Článek připravili Radek Pavlíček a Martin Klein.

Související odkazy

• Color Contrast Analyzer for Chrome na webu NC State University
• Color Contrast Analyzer for Chrome: Text in Images, Gradients, PDFs and More
• Color Contrast Analyzer na Google Chrome Store

Jaké bylo první setkání Accessibility Google User Group

Sešli jsme se v sobotu 11. února 2012 v Café Falk v Brně a jednalo se o příjemné, neformální a informacemi nabité setkání.

Setkání Accessibility GUG jsme po představovacím kolečku začali hangoutem s Mikem Westem z Googlu. Ten stručně představil aktivity Googlu v oblasti přístupnosti (v loňském roce na všech Google Developer Days zazněla přednáška o přístupnosti), Google Chrome a ChromeVoxu a zodpověděl naše dotazy k těmto produktům. V závěru Mike nás požádal o reportování všech bugů, na které z hlediska přístupnosti narazíme (což určitě kvůli zlepšení přístupnosti budeme rádi dělat ;-) Rozloučili jsme se s Mikem a pokračovali v naplánovaném programu.

Já jsem seznámil účastníky s aktivitami Googlu v oblasti přístupnosti a jeho služeb - prakticky se jednalo o stručnou rekapitulaci mé přednášky z loňského Google Developer Day v Praze. Vzhledem k tomu, že všichni zúčastnění jsou aktivními uživateli služeb Googlu, nebylo moc co řešit ;-)

Matěj Plch pak popovídal o vylepšeních Androidu 4.0 z hlediska přístupnosti. Nepříjemným zjištěním, na které Matěj narazil během jeho používání, je absence stabilního českého hlasového výstupu. Doposud běžně používaný Svox s českým hlasem Iveta totiž poměrně často padá, takže práce s tímto v mnoha ohledech vylepšeným systémem je pro uživatele, kteří potřebují český hlasový výstup, je dost komplikovaná. Bližší informace k tomuto tématu jsou k dispozici v Matějově článku Android 4.0: Nejpodstatnější změny a první dojmy.

Roman Kabelka začal obecnějším povídáním o přístupnosti mobilních webových aplikací. Za velmi důležitou Roman považuje rozlišitelnost ovládacích prvků. Spíše než grafické rozhraní vytvořené jako jeden celek a snímání pozice, na níž se uživatel dotkne displeje, je lepší, když je každý prvek vytvořen samostatně. Neméně důležité jsou také smysluplné popisky - ideálně i doplněné o informaci, jak s prvkem pracovat. Více se tomuto tématu věnoval Pavel Ondra v článku Uživatel radí, jak dělat přístupné aplikace pro nevidomé. Článek je trošku staršího data, ale většina informací z něj je stále platná.

Dalším Romanovým tématem byla přístupnost Google+. To na první pohled problémy s přístupností nemá. Pokud se ale na Google+ podíváme detailněji, zjistíme, že některé věci nejsou úplně ideální. Například přidání uživatele do kruhu nešlo před časem udělat standardní cestou. Dnes už je to opraveno, ale i přesto je při práci s Google+ poměrně často třeba použít některé pokročilejší funkce asistivní technologie (například simulaci kliknutí myši na konkrétní místo) či pokročilejší znalosti práce s webovými aplikacemi (dovtípit se, že daný prvek je možné touto cestou aktivovat).

Tomáš Valůšek pak přidal své postřehy uživatele se zbytky zraku. Tomáš je velmi aktivním a pokročilým uživatelem výpočetní techniky. Za základní problém, který mu ztěžuje práci s PC, považuje nedostatečnou velikost textu. Tomášovi nevyhovují standardní zvětšovací programy, které uživateli vzhledem k charakteru zpřístupnění informací berou kontext zobrazované informace. Tomáš kontext potřebuje a je zvyklý pracovat tak, že standardně pracuje s ne tak zvětšenými informacemi a zvětšuje si pouze to, co si chce přečíst. Proto je škoda, že pro Android zatím není k dispozici žádný zvětšovací program, který by zvětšení informací z displeje umožnil. Další problém, se kterým se Tomáš často potýká, je nabídka zvětšování písma přímo konkrétní aplikací - pokud mu aplikace dovolí zvětšit písmo, tak zpravidla nedostatečně.

I další účastníci - Pavel a František - se často zapojovali do diskuse se svými praktickými postřehy a připomínkami.

Probrali jsme i obecnější pohled na přístupnost. Proč Google a Apple přistupují k řešení přístupnosti každý po svém, v čem jsou výhody a nevýhody jednotlivých přístupů, či co bychom mohli jako nová skupina GUG.cz pro zlepšení přístupnosti služeb Googlu udělat. Kolegové si také navzájem vyměnili zkušenosti z používání služeb Googlu.

Tři hodiny nám příjemně uběhly a po páté hodině jsme setkání ukončili s tím, že se určitě nevidíme naposled. A k jakému řešení jsme přišli jako v současnosti nejrozumnějšímu? Služby od Googlu a hardware od Applu ;-)

Fotogalerie

Google Chrome: malé srovnání přístupnosti s odečítači JAWS 12.0 a NVDA

Odečítač obrazovky JAWS 12.0 i open source odečítač NVDA již částečně podporují webový prohlížeč od Googlu. Protože mě zajímalo, na jaké úrovni tato podpora je, rozhodl jsem se udělat malé srovnání, jak na tom odečítače obrazovky skutečně jsou z hlediska přístupnosti. Abych měl jistotu, že budou implementovány i poslední změny související s přístupností, zvolil jsem aktuální vývojovou verzi webového prohlížeče - Google Chrome Canary. Rovněž u odečítačů obrazovky jsem použil aktuální verze - JAWS 12.0.1168 a vývojovou verzi NVDA. Mé srovnání spočívalo v tom, že jsem s prohlížečem navštívil několik často navštěvovaných webových stránek - www.seznam.cz, www.idnes.cz, atp. a srovnával jsem, jak se budou odečítače obrazovky chovat.

JAWS 12.0.1168

po načtení webové stránky www.seznam.cz JAWS načetl webovou stránku do virtuálního kurzoru. Bez problémů fungovaly navigační klávesy, automatický formulářový režim i generování seznamů odkazů, nadpisů, formulářových prvků, označení a kopírování do schránky, i označení celé tabulky. Možnosti virtuálního kurzoru jsou shodné s aplikací Mozilla Firefox - není tedy možné ovlivnit jaký obsah se do schránky bude kopírovat - tj. plný vzhled tak jak je na obrazovce nebo jen z virtuálního kurzoru. Občas se stávalo, že JAWS ztrácel fokus. Práce s formulářovými prvky, hlavně rozbalovacími seznamy, nebyla úplně uspokojivá - JAWS na stránce www.seznam.cz nevyčítal při pohybu v rozbalovacím seznamu jeho položky (seznam.cz, e-mail.cz, post.cz, atp). Aktuální položku rozbalovacího seznamu lze zjistit pouze tak, že přesuneme fokus o následující či předchozí prvek a poté se vrátíme zpět do rozbalovacího seznamu, nicméně je to nouzové řešení. Na stránkách www.idnes.cz rovněž nebylo možné vyčíst položky rozbalovacího seznamu, jinak zde byla práce uspokojivá. S ostatními formulářovými prvky jako je např. editační pole nebo tlačítko JAWS nemá problém. Některé webové stránky se mi s JAWS nepodařilo do virtuálního kurzoru vůbec načíst, šlo například o přihlašovací stránku do redakčního systému WordPress 3.1.3, nicméně spíš to přičítám k nestabilitě testovací verze Google Chrome Canary. JAWS používá stejná nastavení a stejné skripty jako pro prohlížeč Mozilla Firefox. I když Google Chrome se snaží implementovat v podstatě stejné technologie přístupnosti jako prohlížeč od Mozilly, myslím, že své vlastní skripty by si jistě zasloužil. Více o přístupnosti Google Chrome.

Aktuální vývojová verze NVDA

Open source NVDA rovněž bez větších problémů načetl stránku do tzv. virtuálního prohlížeče. Interakce s formulářovými prvky je velmi podobná jako u odečítače JAWS, tj. prakticky jediné problémy, které jsem zaznamenal, byly s rozbalovacími seznamy, kdy NVDA neohlašoval pohyb po položkách seznamu. Generování různých seznamů odkazů, nadpisů popř. formulářových prvků, rychlé klávesy, automatický formulářový režim - vše fungovalo bez problémů. Oproti JAWS mi subjektivně přišlo, že je NVDA stabilnější.

Závěrem

Odečítače obrazovky JAWS 12.0.1168 i aktuální vývojová verze NVDA mají vcelku slušnou podporu pro webový prohlížeč od Google. Problémy se objevují hlavně při interakci s rozbalovacími seznamy, kdy odečítače neoznamují aktuální položku seznamu. JAWS občas ztrácel fokus a bylo potřeba obnovit obrazovku. Na druhé straně je Google Chrome opravdu rychlý prohlížeč - načítání stránek je opravdu bleskové, rozhodně doporučuji minimálně vyzkoušet. Osobně si myslím, že s příchodem nových verzí se podpora přístupnosti bude jen zlepšovat.

Autorem článku je Martin Baláž.

Související odkazy

• Google Chrome: klávesové zkratky a ovládání myší
• Google zlepšuje přístupnost svých produktů

Google zlepšuje přístupnost svých produktů

Před časem jsem si na Google I/O Extended Brno posteskl, že Google je z hlediska přístupnosti svých služeb pro nevidomé uživatele mezi velkou trojkou (Microsoft, Apple, Google) až na třetím místě. Telepatie funguje ;-), ledy se hnuly a dva produkty Google mohou dnes začít používat už i nevidomí uživatelé.

Google Navigace

Nevidomí uživatelé Androidu byli doposud - oproti uživatelům Symbianu, kteří mohou použít LoadStone či Ovi maps - o možnost používání navigace ochuzeni. Byla zde sice možnost použít BRUT Google Maps, vzhledem k licenčním podmínkám se ale jednalo o variantu v "šedé zóně". Na začátku června Google zpřístupnil svou navigaci i pro Českou republiku. Navigační aplikace disponuje poměrně strohým vzhledem, což však výrazně ulehčuje práci odečítačům obrazovky. Pro správnou funkčnost a možnost používání navigace i poslepu je třeba udělat následující tři věci:

• nainstalovat si aktuální verzi aplikace Mapy,
• nainstalovat hlasovou syntézu Svox (český hlas Iveta). Navigace sice obsahuje nahrané hlasové povely, ty se však omezují jen na velmi stručný výklad trasy. V kombinaci s hlasem od společnosti Svox je aplikace mnohem hovornější a pokyny jsou detailnější.
• v telefonu aktivovat volbu "používat satelity GPS".

Navigace aspoň podle prvních zkušeností nevidomých uživatelů funguje velmi dobře a lze ji poslepu bez problémů používat. Více informací najdete na blogu Matěje Plcha, který se přístupností Androidu dlouhodobě zabývá.

Google Chrome

Mezi screen-readery doposud podporované prohlížeče (Internet Explorer a Firefox) se přidal i Google Chrome. Aktuální verze některých screen-readerů ( z těch u nás používaných se jedná o JAWS, NVDA a VoiceOver) již mají základní podporu pro tento webový prohlížeč. Problémy se zatím objevují hlavně při interakci s formulářovými prvky, ale věřme, že s novými verzemi Chrome či screen-readerů se tyto problémy vyřeší. Když se ohlédneme do historie, tak začátky zpřístupnění Firefoxu byly velmi podobné, a dnes už je jeho přístupnost na takové úrovni, že jej řada nevidomých uživatelů používá jako svůj primární prohlížeč.

Kolega Martin Baláž připravil malé srovnání přístupnosti Google Chrome s JAWS a NVDA, které si budete moci na tomto blogu přečíst v nejbližších dnech.

Související dotazy

• Hlasová navigace od Googlu oficiálně v ČR!
• Google navigace: Nechte se vést svým Androidem
• Využití moderních technologií při navigaci nevidomých
• Loadstone: open source navigační program přímo pro nevidomé
• The Chromium Projects: Accessibility