🥇K dostupnosti | ProHoster

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

Chystáte sa opustiť kanceláriu, keď zazvoní nový e-mail ohľadom ďalšej reorganizácie, ktorý práve prišiel do schránky.

Ďakujem xxxx, yyy od dnešného dňa budete reportovať zzzz.
…
A tím Hugh zabezpečí dostupnosť našich produktov pre ľudí so zdravotným postihnutím.

Oh, nie! Za čo som si to zaslúžil? Chcú, aby som odišiel? Pripraviť sa na nevděčnú a ťažkú prácu a snažiť sa napraviť chyby iných. To bude určite zlyhanie...

Taká bola dostupnosť pred niekoľkými rokmi. Niektorí chudáci dostali prácu na "čistení" používateľského rozhrania, aby ho spravili dostupným pre ľudí so zdravotným postihnutím.

To, čo to v skutočnosti znamenalo, bolo dosť nejasné – pravdepodobne, ak ste mohli vidieť indikátor fokusu a presúvať sa medzi políčkami pomocou klávesu Tab, mať nejaký alternatívny text a pár popisov polí, považovalo by sa to za to, že vaša aplikácia je dostupná...

Ale náhle sa "chyby" začali množiť rýchlosťou lavíny.

Rôzne obrazové čítačky (ang. Screen Readers) a prehliadače sa správali úplne inak.

Používatelia si sťažovali, že aplikácia nie je použitelná.

Akonáhle bola chyba opravená na jednom mieste, objavila sa iná na inom.

A jednoducho meniť a opravovať chyby používateľského rozhrania si vyžadovalo obrovské úsilie.

Bol som tam. Prežil som, ale my sme "neuspechli" – technicky sme veľa vyčistili, pridali sme množstvo popisov polí, rolí a dosiahli sme nejakú úroveň súladu s požiadavkami, ale nikto nebol šťastný. Používatelia si aj tak sťažovali, že sa nemôžu orientovať v aplikácii. Manažér si aj tak sťažoval na neustály prílev chýb. Inžinieri si sťažovali na nesprávne definovanie úlohy, bez jasne definovaného "správneho" riešenia, ktoré by fungovalo vo všetkých prípadoch.

Na mojej ceste k porozumeniu dostupnosti boli niektoré jasne odhalujúce momenty.
As it turned out, the first step was realizing that adding accessibility functionality to an existing product is difficult. Even more challenging is convincing managers that it’s incredibly complex! It's not just about 'adding a few tags' and the user interface will work perfectly. No, finishing it in three weeks is impossible; even three months may not be enough.
My next moment of truth came when I witnessed blind users actually using our application. It's SO different from just looking at error messages.

I will return to this again and again, but almost all our 'assumptions' about how people used our application were wrong.

Navigating a complex user interface using keys Tab/Shift+Tab – is terrible! We need something better. Keyboard shortcuts, headings.

Is losing focus when changing the UI really a big problem? Let's reconsider – it’s incredibly confusing.

I continued, working on various projects for a while, and then we started a new project with a complex user interface and a clear intention to finally achieve proper accessibility this time.

So, we took a step back and looked at how we could approach this differently and succeed, and make the workflow enjoyable!

We quickly came to some conclusions:

We didn’t want interface developers fiddling with aria labels/roles and, of course, the HTML structure of components. We needed to provide them with the right components where accessibility is built-in from the start.
Accessibility == Usability – meaning it’s not just a technical task. We needed to change the entire design process and ensure accessibility is considered and discussed before the user interface design begins. We must think ahead about how users can discover any functionality, how they will navigate, and how the 'right-click' function will work with the keyboard. Accessibility has to be an integral part of the design process – for some users, it is far more than just the look of the application.
Od samého začiatku sme chceli získať spätnú väzbu od nevidiacich a iných používateľov so zdravotným postihnutím o jednoduchosti používania aplikácie.
Potrebovali sme skutočne dobré spôsoby, ako odhaliť regresiu prístupnosti.

Z inžinierskeho hľadiska to znelo dosť zábavne – navrhnúť architektúru a implementovať knižnicu komponentov. A naozaj to tak bolo.

Keď sa na to pozrieme z perspektívy príkladov ARIA a premýšľame o tom ako o dizajnovom probléme, a nie o probléme „prispôsobenia“, zaviedli sme niektoré abstrahácie. Komponent má 'Štruktúru' (zatiaľ čo sa skladá z HTML prvkov) a 'Správanie' (ako interaguje s používateľom). Napríklad vo vyžrebovaných úryvkoch nižšie máme jednoduchý neusporiadaný zoznam. Pri pridávaní „správania“ do zoznamu sa pridajú príslušné role, aby fungoval ako zoznam. Podobne to robíme pre menu.

V skutočnosti sa tu pridávajú nielen role, ale aj obslužné programy pre navigáciu pomocou klávesnice.

Toto už vyzerá prehľadnejšie. Keby sme mohli získať čisté oddelenie medzi nimi, nebolo by dôležité, ako bola štruktúra vytvorená, mohli by sme na ňu aplikovať správania a získať správnu prístupnosť.

V praxi to možno vidieť na adrese https://stardust-ui.github.io/react/ – UX knižnica React, ktorá je navrhnutá a implementovaná s ohľadom na prístupnosť od samého začiatku.

Druhá časť – zmena prístupu a procesov okolo dizajnu ma pôvodne znepokojovala: skromní inžinieri, ktorí sa snažia presadiť organizačné zmeny, to nikdy nekončí dobre, ale ukázalo sa, že to bola jedna z najzaujímavejších oblastí, kde sme prispeli k procesu. V skratke sme mali nasledujúci proces: nový funkčný prvok vyvíjala jedna tím, po čom sa naň naša skupina vedúcich pozrela/analyzovala/iterovala návrh a potom, po schválení, sa zvyčajne návrh odovzdal tímu inžinierov. V tomto prípade tím inžinierov v skutočnosti „vlastnil“ funkčnosť prístupnosti, pretože museli odstrániť všetky s ňou spojené problémy.

Na začiatku to bola dosť náročná úloha – vysvetliť, že dostupnosť a použiteľnosť sú neoddeliteľne späté a že to je potrebné zabezpečiť už v štádiu návrhu, inak to vedie k veľkým zmenám a redefinovaniu niektorých rolí. Napriek tomu, s podporou vedenia a kľúčových hráčov, sme túto myšlienku preniesli a začali ju realizovať, aby dizajny prechádzali kontrolou dostupnosti a použiteľnosti predtým, ako sú predstavené vedeniu.

A tieto spätné väzby boli mimoriadne cenné pre všetkých – bolo to fantastické cvičenie na výmenu poznatkov/poskytovanie informácií o tom, ako používatelia komunikujú s webovými aplikáciami, identifikovali sme množstvo problémových oblastí používateľského rozhrania ešte predtým, ako boli vytvorené, vývojové tímy teraz majú omnoho lepšie špecifikácie nielen vizuálnych, ale aj behaviorálnych aspektov dizajnu. Skutočné diskusie sú zábavné, energické, vášnivé diskusie o technických aspektoch a interakciách.

Mohli by sme túto prácu vykonať ešte lepšie, keby na týchto (alebo nasledujúcich) stretnutiach boli s nami aj nevydí či užívatelia so zdravotným postihnutím – to bolo ťažké zorganizovať, ale momentálne naozaj spolupracujeme s miestnymi organizáciami nevidiacich, ako aj so spoločnosťami, ktoré poskytujú externé testovanie na overenie priebehu vykonávania v raných fázach vývoja – či už na úrovni komponentu alebo na úrovni priebehu vykonávania.

Teraz majú inžinieri pomerne podrobné špecifikácie, dostupné komponenty, ktoré môžu použiť na implementáciu, a spôsob, ako overovať priebeh vykonávania. Čiastočne nás skúsenosti naučili tomu, čo neustále prehliadame – ako môžeme zastaviť regresiu. Podobne môžu ľudia využívať integračné alebo end-to-end testy na kontrolu funkčnosti, ktoré potrebujeme na odhaľovanie zmien v interakciách a priebehoch vykonávania – ako vizuálnych, tak aj behaviorálnych.

Definícia vizuálnej regresie je dosť špecifická, je ťažké pridať k tomuto procesu niečo viac, okrem možno kontroly, či je zameranie viditeľné pri navigácii pomocou klávesnice. Zaujímavejšie sú dve relatívne nové technológie na prácu s prístupnosťou.

Accessibility Insights je súbor nástrojov, ktoré môžu byť vykonávané ako v prehliadači, tak aj v rámci cyklu zostavovania/testovania na odhaľovanie problémov.
Overenie správnosti práce programov na čítanie z obrazovky bola obzvlášť zložitá úloha. S prístupom k Accessibility DOM, sme konečne získali možnosť vytvárať snímky aplikácie z pohľadu prístupnosti, veľmi podobné tým, aké robíme pre vizuálne testy, a overujeme ich na regresiu.

Takže v druhej časti príbehu – sme prešli od úpravy HTML k práci na vyššej úrovni abstrakcie, zmenili sme proces návrhu a zaviedli dôkladné testovanie. Nové procesy, nové technológie a nové úrovne abstrakcie úplne zmenili predstavy o prístupnosti a o tom, čo to znamená pracovať v tejto oblasti.
Ale toto je len začiatok.

Nasledujúce "pochopenie" spočíva v tom, že nevidiaci používatelia posúvajú pokročilé technológie – práve oni profitujú najviac nielen z predchádzajúcich zmien, ale aj z toho, že nové prístupy a nápady sa stávajú možnými pomocou ML/AI. Napríklad technológia Immersive Reader umožňuje používateľom jednoduchšie a jasnejšie chápať text. Môže byť čítaný nahlas, štruktúra viet sa gramaticky rozdeľuje a dokonca sa graficky zobrazujú významy slov. Toto sa absolútne nezmestí do starého chápanie „urobiť to prístupným“ – je to funkcia použiteľnosti, ktorá pomôže všetkým.

S ML/AI sa objavujú úplne nové spôsoby interakcie a práce, a sme radi, že sme súčasťou nasledujúcich krokov tejto pokrokovej cesty. Inovácie sú podmienené zmenou myslenia – ľudstvo existuje tisíce rokov, stroje stovky rokov, webové stránky niekoľko desaťročí a smartfóny ešte menej, technológia sa musí prispôsobovať ľuďom, nie naopak.

P.S. Článok bol preložený s malými odchýlkami od originálu. Ako spoluautor tohto článku som tieto odchýlky schválil s Hugh.

Len registrovaní používatelia sa môžu zúčastniť prieskumu. Prihláste sa, prosím.