Směrem k dostupnosti

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

Chystáte se odejít z kanceláře, poštou právě dorazil nový dopis o další reorganizaci.

Děkuji xxxx, yyy ode dneška budete hlásit zzzz
...
A Hughův tým zajistí, aby naše produkty byly přístupné lidem s postižením.

Ach ne! Proč jsem si to zasloužil? Chtějí, abych odešel? Nastavte se na nevděčnou dřinu a snahu napravovat cizí chyby. Tohle je rozhodně neúspěch...

To byla dostupnost před několika lety. Některé ubohé duše dostaly za úkol „vyčistit“ UI, aby se pokusily zpřístupnit je lidem s postižením.

Co to ve skutečnosti znamenalo, bylo dost vágní - pravděpodobně pokud byste viděli indikátor zaměření a procházeli políčky, měli nějaký alternativní text a pár popisů polí, mělo by se za to, že vaše aplikace je přístupná ...

Ale najednou se „štěnice“ začaly množit rychlostí laviny.

Různé čtečky obrazovky (Eng. Čtečky obrazovky) a prohlížeče se chovaly úplně jinak.

Uživatelé si stěžovali, že aplikace je nepoužitelná.

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

A jednoduchá změna a oprava chyb uživatelského rozhraní vyžadovala herkulovské úsilí.

Byl jsem tam. Přežil jsem, ale „neuspěli jsme“ – technicky jsme toho hodně vyčistili, přidali spoustu popisů polí, rolí a dosáhli určité úrovně souladu, ale nikdo nebyl šťastný. Uživatelé si stále stěžovali, že se v aplikaci neumí orientovat. Manažer si stále stěžoval na neustálý příval chyb. Inženýři si stěžovali, že problém byl položen nesprávně, bez jasně definovaného „správného“ řešení, které by fungovalo ve všech případech.

Na mé cestě k pochopení přístupnosti bylo několik rozhodně okouzlujících okamžiků.
Snad prvním bylo zjištění, že přidání funkcí pro usnadnění přístupu k hotovému produktu je obtížné. A ještě těžší je přesvědčit manažery, že je to neuvěřitelně těžké! Ne, není to jen „přidat pár značek“ a uživatelské rozhraní bude fungovat dobře. Ne, to nelze stihnout za tři týdny, ani tři měsíce nebudou stačit.
Můj další okamžik pravdy nastal, když jsem z první ruky viděl, jak naši aplikaci skutečně používají nevidomí uživatelé. To je TAK odlišné od prohlížení chybových zpráv.

Budu se k tomu znovu a znovu vracet, ale téměř všechny naše „domněnky“ o tom, jak lidé naši aplikaci používali, byly mylné.

Navigace ve složitém uživatelském rozhraní pomocí kláves Tab/Shift+Tab – to je na hovno! Potřebujeme něco lepšího. Klávesové zkratky, záhlaví.

Ztráta soustředění při změně uživatelského rozhraní není velký problém, že? Zamysleme se znovu – je to neuvěřitelně matoucí.

Pokračoval jsem, chvíli pracoval na různých projektech a pak jsme začali nový projekt se složitým uživatelským rozhraním a jasnou instalací, abychom tentokrát konečně dosáhli správné dostupnosti.

Takže jsme udělali krok zpět a podívali jsme se na to, jak bychom to mohli implementovat jinak a uspět a učinit proces méně nudným!

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

1. Nechtěli jsme, aby si lidé vyvíjející uživatelské rozhraní zahrávali s popisky/rolemi árií a samozřejmě s HTML strukturou komponent. Potřebovali jsme jim poskytnout ty správné komponenty, které zajistí přístupnost hned po vybalení.
2. Dostupnost == Snadné použití – tzn. Nejde jen o technickou výzvu. Potřebovali jsme změnit celý proces návrhu a zajistit, aby přístupnost byla zohledněna a prodiskutována před zahájením návrhu uživatelského rozhraní. Musíte se včas zamyslet nad tím, jak uživatelé objeví jakoukoli funkci, jak se budou pohybovat a jak bude fungovat kliknutí pravým tlačítkem na klávesnici. Přístupnost by měla být nedílnou součástí procesu návrhu – pro některé uživatele je mnohem víc než jen vzhled aplikace.
3. Od samého začátku jsme chtěli získat zpětnou vazbu od nevidomých a dalších handicapovaných uživatelů o jednoduchosti používání aplikace.
4. Potřebovali jsme opravdu dobré způsoby, jak zachytit regrese přístupnosti.

No, z inženýrského hlediska zněl první díl docela zábavně – vývoj architektury a implementace knihovny komponent. A skutečně tomu tak bylo.

Udělám krok zpět, dívám se Příklady ARIA a tím, že jsme to považovali spíše za problém designu než problém „zapadnutí“, zavedli jsme některé abstrakce. Komponenta má 'Strukturu' (skládá se z prvků HTML) a 'Chování' (jak interaguje s uživatelem). Například ve úryvcích níže máme jednoduchý neuspořádaný seznam. Přidáním "chování" jsou do seznamu přidány odpovídající role, aby se choval jako seznam. Totéž děláme pro menu.

Ve skutečnosti se zde nepřidávají pouze role, ale také obslužné rutiny událostí pro navigaci pomocí klávesnice.

Tohle vypadá úhledněji. Pokud bychom mezi nimi dokázali dosáhnout čistého oddělení, nezáleželo by na tom, jak byla struktura vytvořena, mohli bychom na ni použít chování a získat správnou přístupnost.

Můžete to vidět v akci na https://stardust-ui.github.io/react/ – UX knihovna REACT, který je od začátku navržen a implementován s ohledem na dostupnost.

Druhá část – změna přístupu a procesů kolem designu mě zpočátku vyděsila: pokorní inženýři, kteří se snaží prosadit organizační změny, nekončí vždy dobře, ale ukázalo se, že je to jedna z nejzajímavějších oblastí, kde jsme k procesu významně přispěli . Stručně řečeno, náš proces byl následující: novou funkcionalitu by vyvinul jeden tým, poté náš vedoucí tým zkontroloval/iteroval návrh a poté, jakmile byl schválen, byl návrh obvykle předán technickému týmu. V tomto případě inženýrský tým fakticky „vlastnil“ funkci usnadnění, protože byla jeho odpovědností opravit jakékoli problémy s tím spojené.

Na začátku bylo docela těžké vysvětlit, že dostupnost a použitelnost jsou neoddělitelně spjaty a že to musí být provedeno ve fázi návrhu, jinak by to vedlo k velkým změnám a redefinicím některých rolí. S podporou managementu a klíčových hráčů jsme však nápad vzali a uvedli do pohybu, takže návrhy byly testovány na dostupnost a použitelnost, než byly předloženy vedení.

A tato zpětná vazba byla pro všechny nesmírně cenná – bylo to fantastické jako cvičení ve sdílení znalostí/komunikaci 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 jejich vytvořením, vývojové týmy v současnosti mají mnohem lepší specifikace nejen vizuální, ale i behaviorální aspekty designu. Skutečné diskuse jsou zábavné, energické, vášnivé diskuse o technických aspektech a interakcích.

Mohli bychom to udělat ještě lépe, kdybychom měli na těchto (nebo následujících) schůzkách nevidomé a postižené uživatele – bylo obtížné to zorganizovat, ale nyní spolupracujeme jak s místními organizacemi pro nevidomé, tak se společnostmi, které poskytují externí testování k ověření průběhu realizace na začátku vývoj – jak na úrovni komponent, tak na úrovni realizace.

Inženýři nyní mají poměrně podrobné specifikace, dostupné komponenty, které mohou použít k implementaci, a způsob, jak ověřit průběh provádění. Část toho, co nás zkušenost naučila, je to, co nám celou dobu chybělo – jak můžeme zastavit regresi. Podobně mohou lidé používat integraci nebo end-to-end testy k testování funkčnosti, kterou potřebujeme k detekci změn v interakcích a tocích provádění – jak vizuálních, tak behaviorálních.

Určení vizuální regrese je poměrně definovaný úkol, k procesu lze přidat jen velmi málo kromě kontroly, zda je při navigaci pomocí klávesnice vidět fokus. Zajímavější jsou dvě relativně nové technologie pro práci s přístupností.

1. Přehled o přístupnosti je sada nástrojů, které lze spustit jak v prohlížeči, tak jako součást cyklu sestavení/testování k identifikaci problémů.
2. Ověření, že čtečky obrazovky fungují správně, bylo obzvláště náročným úkolem. Se zavedením přístupu k Přístupnost DOM, konečně můžeme pořizovat snímky přístupnosti aplikace, podobně jako to děláme u vizuálních testů, a kontrolovat jejich regresi.

V druhé části příběhu jsme tedy přešli od úprav HTML kódu k práci na vyšší úrovni abstrakce, změnili jsme proces vývoje návrhu a zavedli důkladné testování. Nové procesy, nové technologie a nové úrovně abstrakce zcela změnily krajinu dostupnosti a to, co znamená pracovat v tomto prostoru.
Ale to je jen začátek.

Dalším „pochopením“ je, že nevidomí uživatelé řídí špičkovou technologii – jsou to oni, kdo nejvíce těží nejen ze změn, které jsme popsali dříve, ale také z toho, že nové přístupy a nápady jsou umožněny ML/AI. Například technologie Immersive Reader umožňuje uživatelům prezentovat text snadněji a jasněji. Dá se číst nahlas, struktura vět je gramaticky rozčleněna a dokonce i významy slov jsou graficky zobrazeny. To vůbec nezapadá do staré mentality „udělej to přístupné“ – je to funkce použitelnosti, která pomůže všem.

ML/AI umožňuje zcela nové způsoby interakce a práce a jsme nadšeni, že můžeme být součástí dalších fází této špičkové cesty. Inovace jsou poháněny změnou myšlení – lidstvo existuje po tisíciletí, stroje stovky let, webové stránky několik desetiletí a chytré telefony ještě méně, technologie se musí přizpůsobovat lidem, a ne naopak.

PS Článek byl přeložen s drobnými odchylkami od originálu. Jako spoluautor tohoto článku jsem se na těchto odbočkách s Hughem shodl.

Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. Přihlásit se, prosím.

Dbáte na přístupnost svých aplikací?

• Ano

• Ne

• To je poprvé, co slyším o přístupnosti aplikací.

Hlasovalo 17 uživatelů. 5 uživatelů se zdrželo hlasování.

Zdroj: www.habr.com