Smerom k dostupnosti

Smerom k dostupnosti

Piatok je koniec pracovného dňa. Zlé správy prichádzajú vždy na konci pracovného dňa v piatok.

Chystáte sa odísť z kancelárie, práve vám prišiel poštou nový list o ďalšej reorganizácii.

Ďakujem xxxx, yyy od dnes budete hlásiť zzzz
...
A Hughov tím zabezpečí, aby naše produkty boli prístupné ľuďom so zdravotným postihnutím.

Ale nie! Prečo som si to zaslúžil? Chcú, aby som odišiel? Nastavte sa na nevďačnú tvrdú prácu a snahu napraviť chyby iných ľudí. Toto je určite neúspech...

Toto bola dostupnosť pred niekoľkými rokmi. Niektoré úbohé duše dostali za úlohu „vyčistiť“ používateľské rozhranie, aby sa pokúsili sprístupniť ho ľuďom so zdravotným postihnutím.

Čo to v skutočnosti znamenalo, bolo dosť vágne - pravdepodobne keby ste videli indikátor zaostrenia a prešli cez polia, mali nejaký alternatívny text a pár popisov polí, považovalo by sa to za prístupnú vašu aplikáciu ...

Zrazu sa však „chrobáky“ začali množiť rýchlosťou lavíny.

Rôzne čítačky obrazovky (Eng. Čítačky obrazovky) a prehliadače sa správali úplne inak.

Používatelia sa sťažovali, že aplikácia je nepoužiteľná.

Len čo sa na jednom mieste opravila chyba, na inom sa objavila ďalšia.

A jednoduchá zmena a oprava chýb používateľského rozhrania si vyžadovala herkulovské úsilie.

Bol som tam. Prežil som, ale „nedarilo sa“ – technicky sme veľa vyčistili, pridali veľa popisov polí, rolí a dosiahli určitú úroveň súladu, no nikto nebol spokojný. Používatelia sa stále sťažovali, že sa nevedia v aplikácii orientovať. Manažér sa stále sťažoval na neustály prúd chýb. Inžinieri sa sťažovali, že problém bol položený nesprávne, bez jasne definovaného „správneho“ riešenia, ktoré by fungovalo vo všetkých prípadoch.

Na mojej ceste k pochopeniu dostupnosti bolo niekoľko rozhodne oči otvárajúcich momentov.
Možno prvým bolo zistenie, že pridanie funkcionality prístupnosti k hotovému produktu je náročné. A ešte ťažšie je presvedčiť manažérov, že je to neuveriteľne ťažké! Nie, nie je to len „pridať pár značiek“ a používateľské rozhranie bude fungovať dobre. Nie, toto sa nedá stihnúť za tri týždne, ani tri mesiace nebudú stačiť.
Môj ďalší moment pravdy nastal, keď som z prvej ruky videl, ako nevidomí používatelia skutočne používajú našu aplikáciu. To je TAK odlišné od pozerania sa na chybové hlásenia.

Budem sa k tomu znova a znova vracať, ale takmer všetky naše „predpoklady“ o tom, ako ľudia používajú našu aplikáciu, boli nesprávne.

Navigácia v komplexnom používateľskom rozhraní pomocou stlačenia klávesov Tab/Shift+Tab – toto je na hovno! Potrebujeme niečo lepšie. Klávesové skratky, hlavičky.

Strata pozornosti pri zmene používateľského rozhrania nie je veľký problém, však? Zamyslime sa znova - je to neuveriteľne mätúce.

Pokračoval som, chvíľu som pracoval na rôznych projektoch a potom sme začali nový projekt so zložitým používateľským rozhraním a prehľadnou inštaláciou, aby sme tentoraz konečne dosiahli správnu dostupnosť.

Takže sme urobili krok späť a pozreli sme sa na to, ako by sme to mohli implementovať inak a uspieť a urobiť tento proces menej nudným!

Pomerne rýchlo sme dospeli k niektorým záverom:

  1. Nechceli sme, aby sa ľudia, ktorí vyvíjajú používateľské rozhranie, zaoberali menovkami árií/rolami a, samozrejme, HTML štruktúrou komponentov. Museli sme im poskytnúť tie správne komponenty, ktoré zaistia dostupnosť hneď po vybalení.
  2. Prístupnosť == Jednoduchosť použitia – t.j. Nejde len o technickú výzvu. Potrebovali sme zmeniť celý proces návrhu a zabezpečiť, aby sa pred začatím návrhu používateľského rozhrania zohľadnila a prediskutovala dostupnosť. Musíte sa včas zamyslieť nad tým, ako používatelia objavia akúkoľvek funkciu, ako sa budú pohybovať a ako bude fungovať klikanie pravým tlačidlom myši z klávesnice. Prístupnosť by mala byť neoddeliteľnou súčasťou procesu návrhu – pre niektorých používateľov je oveľa viac ako len vzhľad aplikácie.
  3. Od samého začiatku sme chceli získať spätnú väzbu od nevidiacich a iných hendikepovaných používateľov o jednoduchosti používania aplikácie.
  4. Potrebovali sme naozaj dobré spôsoby, ako zachytiť regresy dostupnosti.

No z inžinierskeho hľadiska prvá časť znela celkom zábavne – vývoj architektúry a implementácia knižnice komponentov. A skutočne to tak bolo.

O krok späť, pohľad Príklady ARIA a tým, že sme o tom uvažovali skôr ako o dizajnovom probléme než o probléme „zapadnutia“, zaviedli sme niekoľko abstrakcií. Komponent má „štruktúru“ (pozostáva z prvkov HTML) a „správanie“ (ako interaguje s používateľom). Napríklad v úryvkoch nižšie máme jednoduchý neusporiadaný zoznam. Pridaním "správania" sa do zoznamu pridajú zodpovedajúce roly, aby fungoval ako zoznam. To isté robíme pre menu.

Smerom k dostupnosti

V skutočnosti tu nie sú pridané len roly, ale aj obslužné programy udalostí pre navigáciu pomocou klávesnice.

Toto vyzerá úhľadnejšie. Ak by sme medzi nimi dokázali dosiahnuť čisté oddelenie, nezáležalo by na tom, ako bola štruktúra vytvorená, mohli by sme na ňu aplikovať správanie a dosiahnuť správnu dostupnosť.

Môžete to vidieť v akcii na https://stardust-ui.github.io/react/ – knižnica UX Reagovať, ktorý je od začiatku navrhnutý a implementovaný s ohľadom na dostupnosť.

Druhá časť – zmena prístupu a procesov okolo dizajnu ma spočiatku vydesila: skromní inžinieri, ktorí sa snažia presadiť organizačné zmeny, nie vždy končia dobre, ale ukázalo sa, že je to jedna z najzaujímavejších oblastí, kde sme významne prispeli k procesu . Stručne povedané, náš proces bol nasledovný: novú funkcionalitu by vyvinul jeden tím, potom náš vedúci tím skontroloval / iteroval návrh a po schválení by sa návrh zvyčajne odovzdal technickému tímu. V tomto prípade inžiniersky tím v skutočnosti „vlastnil“ funkciu dostupnosti, pretože bola jeho zodpovednosťou opraviť všetky problémy s tým spojené.

Na začiatku bolo dosť ťažké vysvetliť, že dostupnosť a použiteľnosť sú neoddeliteľne spojené a že to treba urobiť už v štádiu návrhu, inak by to viedlo k veľkým zmenám a predefinovaniu niektorých rolí. S podporou manažmentu a kľúčových hráčov sme však túto myšlienku prevzali a uviedli do pohybu, takže návrhy boli testované na dostupnosť a použiteľnosť predtým, ako boli prezentované manažmentu.

A táto spätná väzba bola pre každého mimoriadne cenná – bolo to fantastické ako cvičenie zdieľania znalostí/komunikácie o tom, ako používatelia interagujú s webovými aplikáciami, identifikovali sme množstvo problémových oblastí používateľského rozhrania ešte pred ich vytvorením, vývojové tímy v súčasnosti majú oveľa lepšie špecifikácie nielen vizuálne, ale aj behaviorálne aspekty dizajnu. Skutočné diskusie sú zábavné, energické, vášnivé diskusie o technických aspektoch a interakciách.

Mohli by sme to urobiť ešte lepšie, ak by sme na týchto (alebo následných) stretnutiach mali nevidomých a zdravotne postihnutých používateľov – bolo ťažké to zorganizovať, ale teraz spolupracujeme s miestnymi nevidiacimi organizáciami a spoločnosťami, ktoré poskytujú externé testovanie na overenie priebehu vykonávania na začiatku vývoj – na úrovni toku komponentov aj vykonávania.

Inžinieri majú teraz pomerne podrobné špecifikácie, dostupné komponenty, ktoré môžu použiť na implementáciu, a spôsob, ako overiť tok vykonávania. Časť toho, čo nás skúsenosť naučila, je to, čo nám celý čas chýbalo – ako môžeme zastaviť regresiu. Podobne môžu ľudia použiť integráciu alebo end-to-end testy na testovanie funkčnosti, ktorú potrebujeme na zistenie zmien v interakciách a tokoch vykonávania – vizuálnych aj behaviorálnych.

Určenie vizuálnej regresie je pomerne definovaná úloha, do procesu možno pridať len veľmi málo okrem kontroly, či je pri navigácii pomocou klávesnice viditeľné zaostrenie. Zaujímavejšie sú dve relatívne nové technológie pre prácu s prístupnosťou.

  1. Prehľad o prístupnosti je sada nástrojov, ktoré možno spustiť v prehliadači aj ako súčasť cyklu zostavovania/testovania na identifikáciu problémov.
  2. Overenie, že čítačky obrazovky fungujú správne, bola mimoriadne náročná úloha. So zavedením prístupu k Prístupnosť DOM, konečne môžeme urobiť snímky dostupnosti aplikácie, podobne ako to robíme pri vizuálnych testoch, a otestovať ich na regresiu.

V druhej časti príbehu sme teda prešli od úpravy HTML kódu k práci na vyššej úrovni abstrakcie, zmenili sme proces vývoja dizajnu a zaviedli dôkladné testovanie. Nové procesy, nové technológie a nové úrovne abstrakcie úplne zmenili krajinu dostupnosti a to, čo znamená pracovať v tomto priestore.
Ale toto je len začiatok.

Ďalším „pochopením“ je, že nevidomí používatelia riadia špičkovú technológiu – sú to tí, ktorí najviac profitujú nielen zo zmien, ktoré sme opísali vyššie, ale aj z toho, že nové prístupy a nápady umožňuje ML/AI. Napríklad technológia Immersive Reader umožňuje používateľom jednoduchšie a jasnejšie prezentovať text. Dá sa čítať nahlas, štruktúra viet je gramaticky rozdelená a dokonca aj významy slov sú zobrazené graficky. Toto vôbec nezapadá do starej mentality „make it available“ – je to funkcia použiteľnosti, ktorá pomôže každému.

ML/AI umožňuje úplne nové spôsoby interakcie a práce a sme nadšení, že môžeme byť súčasťou ďalších fáz tejto špičkovej cesty. Inovácie sú poháňané zmenou myslenia – ľudstvo existuje tisícročia, stroje stovky rokov, webové stránky niekoľko desaťročí a smartfóny ešte menej, technológie sa musia prispôsobiť ľuďom a nie naopak.

PS Článok je preložený s menšími odchýlkami od originálu. Ako spoluautor tohto článku som sa na týchto odbočkách zhodol s Hughom.

Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prihlásiť saProsím.

Dbáte na prístupnosť svojich aplikácií?

  • Да

  • Nie

  • Toto je prvýkrát, čo počujem o dostupnosti aplikácií.

Hlasovalo 17 užívateľov. 5 užívateľov sa zdržalo hlasovania.

Zdroj: hab.com

Pridať komentár