🥇Na cestě k dostupnosti

Pátek – konec pracovního dne. Špatné zprávy vždy přicházejí v pátek na konci pracovního dne.

Chystáte se opustit kancelář, "ding" nové e-mailové oznámení o další reorganizaci právě přišlo do vaší schránky.

Děkuji xxxx, yyy od dneška budete podávat zprávy zzzz
…
A tým Hugh zajistí dostupnost našich produktů pro lidi se zdravotním postižením.

Ach ne! Co jsem si zasloužil? Chtějí, abych odešel? Příprava na vděčnou těžkou práci a pokusit se opravit chyby jiných lidí. To určitě skončí neúspěchem…

Taková byla dostupnost před několika lety. Někteří chudáci dostávali práci na "úklidu" uživatelského rozhraní, aby se pokusili učinit jej dostupným pro lidi se zdravotním postižením.

To, co to ve skutečnosti znamenalo, bylo dost vágní – pravděpodobně, pokud jste mohli vidět ukazatel fokus, pohybovat se po polích pomocí tabulátoru, mít nějaký alternativní text a pár popisů k polím, by to bylo považováno za to, že je vaše aplikace dostupná…

Ale najednou "chyby" začaly vznikat rychlostí laviny.

Různá čtecí zařízení (angl. Screen Readers) a prohlížeče se chovaly naprosto odlišně.

Uživatelé si stěžovali, že aplikace není použitelná.

Jakmile byla chyba opravena na jednom místě, objevila se jiná na jiném.

A pouhé měnění a opravování chyb uživatelského rozhraní vyžadovalo titánské úsilí.

Byl jsem tam. Přežil jsem, ale "neuspěli jsme" – technicky jsme spoustu vyčistili, přidali jsme spoustu popisů k polím, rolím a dosáhli jsme určité úrovně shody s požadavky, ale nikdo nebyl šťastný. Uživatelé si stále stěžovali, že se v aplikaci nemohou orientovat. Manažer si stále stěžoval na neustálý příliv chyb. Inženýři si stěžovali na špatné zadání úkolů, bez jasně definovaného "správného" řešení, které by fungovalo ve všech případech.

Na mé cestě k pochopení dostupnosti potkalo několik jasně odhalujících momentů.
Pochopení, že přidávat funkce dostupnosti na hotový produkt je složité, bylo pravděpodobně první. A ještě složitější je přesvědčit manažery, že je to neuvěřitelně obtížné! Ne, nejde jen o to "přidat pár značek" a uživatelské rozhraní bude fungovat skvěle. Ne, to nelze dokončit za tři týdny, ani tři měsíce nestačí.
Můj další okamžik pravdy nastal, když jsem na vlastní oči viděl, jak slepí uživatelé skutečně používají naši aplikaci. To se TOTÁLNĚ liší od prohlížení chybových hlášení.

K tomu se budu vracet znovu a znovu, ale téměř všechny naše "předpoklady" o tom, jak lidé používali naši aplikaci, byly chybnými.

Navigace složitým uživatelským rozhraním pomocí kláves Tab/Shift+Tab – to je hrozné! Potřebujeme něco lepšího. Klávesové zkratky, hlavičky.

Ztráta fokusu při změně uživatelského rozhraní není přece takový problém? Promysleme to ještě jednou – je to šíleně matoucí.

Pokračoval jsem a nějakou dobu pracoval na různých projektech, a pak jsme zahájili nový projekt se složitým uživatelským rozhraním a jasným cílem konečně zajistit správnou dostupnost.

Tak jsme se vrátili o krok zpět a podívali se, jak to můžeme realizovat jinak a uspět, a aby sám proces práce nebyl nudný!

Poměrně rychle jsme dospěli k několika závěrům:

Nechtěli jsme, aby lidé vyvíjející uživatelské rozhraní laborovali se značkami aria/role a přirozeně s HTML strukturou komponent. Potřebovali jsme jim poskytnout správné komponenty, ve kterých byla dostupnost implementována přímo z krabice.
Dostupnost == Uživatelská přívětivost – tj. není to jen technický úkol. Museli jsme změnit celý proces návrhu a ujistit se, že se dostupnost zohledňuje a diskutuje ještě před zahájením návrhu uživatelského rozhraní. Je třeba od začátku promýšlet, jak uživatelé mohou objevit jakoukoliv funkčnost, jak se budou pohybovat a jak bude fungovat "pravé kliknutí myší" z klávesnice. Dostupnost by měla být nedílnou součástí návrhového procesu – pro některé uživatele je to mnohem víc než jen vzhled aplikace.
Od samého začátku jsme chtěli získat názory od nevidomých a dalších uživatelů se zdravotním postižením na jednoduchost používání aplikace.
Potřebovali jsme opravdu dobré způsoby, jak chytat regresi přístupnosti.

No, z inženýrského hlediska, první část zněla docela zábavně – navrhování architektury a implementace knihovny komponent. A skutečně to tak bylo.

Když se krok zpět, zvažujeme příklady ARIA a přemýšlíme o tom jako o designovém problému, a ne o problému „přizpůsobení“, zavedli jsme některé abstrakce. Komponent má ‚Strukturu‘ (sestává z HTML elementů) a ‚Chování‘ (jak interaguje s uživateli). Například v níže uvedených úryvcích máme jednoduchý neuspořádaný seznam. Při přidávání „chování“ k seznamu se přidávají příslušné role, aby fungoval jako seznam. Stejně tak to děláme pro menu.

Ve skutečnosti se zde přidávají nejen role, ale také obslužné programy pro navigaci pomocí klávesnice.

Vypadá to už lépe. Kdybychom mohli dosáhnout čistého oddělení mezi nimi, bylo by jedno, jak byla struktura vytvořena, mohli bychom na ni aplikovat chování a dosáhnout správné přístupnosti.

V akci to lze vidět na adrese https://stardust-ui.github.io/react/ – UX knihovna React, která je navrhována a realizována s ohledem na přístupnost od samého začátku.

Druhá část – změna přístupu a procesů kolem designu mě zpočátku děsila: skromní inženýři, kteří se snaží prosadit organizační změny, to většinou nekončí dobře, ale ukázalo se, že to byla jedna z nejzajímavějších oblastí, kde jsme významně přispěli k procesu. Ve zjednodušené podobě jsme měli následující proces: nová funkčnost byla vyvíjena jedním týmem, následně naše skupina vedoucích analyzovala/iterovala tento návrh a poté, po schválení, byl design obvykle předán týmu inženýrů. V tomto případě tým inženýrů ve skutečnosti „vlastnil“ funkčnost přístupnosti, protože musel odstranit všechny s tím spojené problémy.

Na začátku to byla docela náročná práce – vysvětlit, že přístupnost a použitelnost jsou neoddělitelně spojeny a že je třeba to udělat již ve fázi návrhu, jinak by to vedlo k velkým změnám a redefinici některých rolí. Nicméně, s podporou vedení a klíčových hráčů jsme tuto myšlenku prosadili a uvedli do praxe, aby designy procházely kontrolou přístupnosti a použitelnosti, než budou předloženy vedení.

Tyto zpětné vazby byly nesmírně cenné pro všechny – bylo fantastické, jak to bylo cvičení v oblasti sdílení znalostí/o tom, jak uživatelé interagují s webovými aplikacemi, identifikovali jsme řadu problémových oblastí uživatelského rozhraní ještě před tím, než byly postaveny, týmy vývojářů nyní mají mnohem lepší specifikace nejen pro vizuální, ale i pro behaviorální aspekty designu. Oprávněné diskuse – to jsou zábavné, energické, vášnivé debaty o technických aspektech a interakcích.

Mohli bychom tuto práci zlepšit ještě víc, pokud bychom na těchto (nebo následných) schůzkách měli slepé uživatele a uživatele se zdravotním postižením – bylo to obtížné zorganizovat, ale nyní opravdu spolupracujeme jak s místními organizacemi pro slepé, tak s firmami, které poskytují externí testování pro ověření pracovních toků v raných fázích vývoje – jak na úrovni komponent, tak na úrovni pracovního toku.

Nyní mají inženýři k dispozici poměrně podrobné specifikace, dostupné komponenty, které mohou použít pro implementaci, a způsob, jak ověřit pracovní toky. Částečně nás zkušenost naučila, co jsme neustále přehlíželi – jak můžeme zastavit regresi. Podobně mohou lidé používat integrační nebo koncové testy k ověření funkcionality, kterou potřebujeme k odhalení změn v interakcích a pracovních tocích – jak vizuálních, tak behaviorálních.

Definice vizuální regrese je poměrně konkrétní úkol, přičemž k tomuto procesu lze přidat jen velmi málo, kromě možná kontroly, zda je viditelný fokus při navigaci pomocí klávesnice. Daleko zajímavější jsou dvě relativně nové technologie zaměřené na zpřístupnění.

Accessibility Insights je soubor nástrojů, které mohou fungovat jak v prohlížeči, tak v rámci cyklu sestavení/testování za účelem identifikace problémů.
Ověření správné funkce programů pro čtení obrazovky bylo obzvláště složitým úkolem. S přístupem k Accessibility DOM, jsme konečně získali schopnost pořizovat snímky aplikace z pohledu zpřístupnění, velmi podobně jako to děláme pro vizuální testy, a kontrolovat je na regresi.

Takže ve druhé části příběhu – přešli jsme od úpravy HTML k práci na vyšší úrovni abstrakce, změnili jsme proces vývoje designu a zavedli jsme důkladné testování. Nové procesy, nové technologie a nové úrovně abstrakce zcela změnily naše chápání zpřístupnění a toho, co to znamená pracovat v této oblasti.
Ale to je teprve začátek.

Další „pochopení“ spočívá v tom, že slepí uživatelé posouvají technologické hranice – právě oni mají největší prospěch nejen z dříve uvedených změn, ale i z nových přístupů a nápadů, které se stávají možnými díky ML/AI. Například technologie Immersive Reader umožňuje uživatelům lépe a jasněji představit text. Lze jej přečíst nahlas, struktura vět je gramaticky rozdělena a významy slov jsou dokonce zobrazeny graficky. To se naprosto nevejde do starého chápání „udělat to přístupným“ – je to funkce uživatelské přívětivosti, která pomůže všem.

S ML/AI se objevují zcela nové způsoby interakce a práce a jsme rádi, že jsme součástí následujících fází této pokrokové cesty. Inovace jsou způsobeny změnou myšlení – lidstvo existuje tisíce let, stroje stovky let, webové stránky několik desítek let a smartphony dokonce ještě méně, technologie by se měla přizpůsobit lidem, a ne naopak.

P.S. Článek byl přeložen s drobnými odchylkami od originálu. Jako spoluautor tohoto článku jsem tyto odchylky konzultoval s Hughem.

Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.