Op pad na toeganklikheid

Vrydag is die einde van die werksdag. Slegte nuus kom altyd aan die einde van die werksdag op Vrydag.

Jy is op die punt om die kantoor te verlaat, 'n nuwe brief oor 'n ander herorganisasie het sopas in die pos aangekom.

Dankie xxxx, yyy van vandag af sal jy zzzz rapporteer
...
En Hugh se span sal verseker dat ons produkte toeganklik is vir mense met gestremdhede.

Ag nee! Hoekom het ek dit verdien? Wil hulle hê ek moet weggaan? Stel jouself gereed vir ondankbare harde werk en probeer om ander mense se foute reg te stel. Dit is beslis 'n mislukking...

Dit was die beskikbaarheid 'n paar jaar gelede. Sommige arme siele het die taak gekry om die UI te "skoonmaak" om dit toeganklik te maak vir mense met gestremdhede.

Wat dit eintlik beteken het, was redelik vaag - vermoedelik as jy 'n fokusaanwyser en 'n oortjie deur velde kon sien, 'n paar alt-teks en 'n paar veldbeskrywings het, sal dit beskou word dat jou aansoek toeganklik is ...

Maar skielik het die "goggas" teen die spoed van 'n stortvloed begin vermeerder.

Verskeie skermlesers (Eng. Skermlesers) en blaaiers het heeltemal anders opgetree.

Gebruikers het gekla dat die toepassing onbruikbaar is.

Sodra 'n fout op een plek reggestel is, het 'n ander op 'n ander verskyn.

En om eenvoudig gebruikerskoppelvlakfoute te verander en reg te stel, het Herculean-pogings vereis.

Ek was daar. Ek het oorleef, maar ons het nie "suksesvol" nie - tegnies het ons baie skoongemaak, baie veldbeskrywings, rolle bygevoeg en 'n mate van voldoening bereik, maar niemand was gelukkig nie. Gebruikers het steeds gekla dat hulle nie die toepassing kon navigeer nie. Die bestuurder het steeds gekla oor die konstante stroom foute. Ingenieurs het gekla dat die probleem verkeerd gestel is, met geen duidelik gedefinieerde "korrekte" oplossing wat in alle gevalle sou werk nie.

Daar was 'n paar besliste oogopenende oomblikke langs my reis om toeganklikheid te verstaan.
Miskien was die eerste die besef dat dit moeilik was om toeganklikheidsfunksionaliteit bo-op 'n voltooide produk te voeg. En dit is selfs moeiliker om bestuurders te oortuig dat dit ongelooflik moeilik is! Nee, dit is nie net "voeg 'n paar merkers by" nie en die UI sal goed werk. Nee, dit kan nie binne drie weke afgehandel word nie; selfs drie maande sal nie genoeg wees nie.
My volgende oomblik van waarheid het gekom toe ek eerstehands gesien het hoe blinde gebruikers eintlik ons ​​toepassing gebruik. Dit is SO anders as om na foutboodskappe te kyk.

Ek sal weer en weer hierna terugkom, maar byna al ons "aannames" oor hoe mense ons toepassing gebruik het, was verkeerd.

Navigeer 'n komplekse gebruikerskoppelvlak met behulp van toetsaanslagen Tab/Shift+Tab – dit suig! Ons het iets beters nodig. Sleutelbordkortpaaie, kopskrifte.

Om fokus te verloor wanneer die UI verander is nie 'n groot probleem nie, is dit? Kom ons dink weer – dit is ongelooflik verwarrend.

Ek het voortgegaan, 'n rukkie aan verskillende projekte gewerk, en toe begin ons 'n nuwe projek, met 'n komplekse gebruikerskoppelvlak en 'n duidelike installasie, om uiteindelik toeganklikheid hierdie keer reg te kry.

So, ons het 'n stap terug geneem en gekyk hoe ons dit anders kan implementeer en slaag, en die proses minder vervelig kan maak!

Ons het redelik vinnig tot 'n paar gevolgtrekkings gekom:

1. Ons wou nie hê mense wat die gebruikerskoppelvlak ontwikkel, moet mors met aria-etikette/rolle en natuurlik die HTML-struktuur van die komponente nie. Ons moes hulle van die regte komponente voorsien wat toeganklikheid reg uit die boks gebou het.
2. Toeganklikheid == Gebruiksgemak – d.w.s. Dit is nie net 'n tegniese uitdaging nie. Ons moes die hele ontwerpproses verander en verseker dat toeganklikheid in ag geneem en bespreek is voordat UI-ontwerp begin het. Jy moet vroegtydig dink hoe gebruikers enige funksionaliteit sal ontdek, hoe hulle sal navigeer en hoe regskliek vanaf die sleutelbord sal werk. Toeganklikheid behoort 'n integrale deel van die ontwerpproses te wees – vir sommige gebruikers is dit veel meer as net die voorkoms van die toepassing.
3. Van die begin af wou ons terugvoer van blinde en ander gestremde gebruikers kry oor die gebruiksgemak van die toepassing.
4. Ons het baie goeie maniere nodig gehad om toeganklikheidregressies op te vang.

Wel, uit 'n ingenieursoogpunt, het die eerste deel nogal pret geklink - die ontwikkeling van 'n argitektuur en die implementering van 'n biblioteek van komponente. En dit was inderdaad so.

Neem 'n tree terug, kyk ARIA voorbeelde en deur hieraan te dink as 'n ontwerpprobleem eerder as 'n "inpas"-probleem, het ons 'n paar abstraksies bekendgestel. 'n Komponent het 'n 'Struktuur' (bestaan ​​uit HTML-elemente) en 'n 'Gedrag' (hoe dit met die gebruiker in wisselwerking tree). Byvoorbeeld, in die brokkies hieronder het ons 'n eenvoudige ongeordende lys. Deur "gedrag" by te voeg, word die ooreenstemmende rolle by die lys gevoeg om dit soos 'n lys te laat optree. Ons doen dieselfde vir die spyskaart.

Trouens, nie net rolle word hier bygevoeg nie, maar ook gebeurtenishanteerders vir sleutelbordnavigasie.

Dit lyk netjieser. As ons 'n skoon skeiding tussen hulle kon kry, sou dit nie saak maak hoe die struktuur geskep is nie, ons kan Behaviors daarop toepas en die toeganklikheid reg kry.

Jy kan dit in aksie sien by https://stardust-ui.github.io/react/ - UX-biblioteek reageer, wat van die begin af ontwerp en geïmplementeer is met toeganklikheid in gedagte.

Die tweede deel - die verandering van die benadering en prosesse rondom ontwerp het my aanvanklik bang gemaak: nederige ingenieurs wat organisasieverandering probeer deurdruk, eindig nie altyd goed nie, maar dit blyk een van die interessantste areas te wees waar ons beduidende bydraes tot die proses gemaak het. . In 'n neutedop was ons proses soos volg: nuwe funksionaliteit sou deur een span ontwikkel word, dan sou ons leierskapspan die voorstel hersien/herhaal, en dan, sodra dit goedgekeur is, sou die ontwerp tipies aan die ingenieurspan oorhandig word. In hierdie geval het die ingenieurspan effektief die toeganklikheidsfunksie “besit” omdat dit hul verantwoordelikheid was om enige probleme wat daarmee verband hou reg te stel.

Aan die begin was dit nogal 'n moeilike taak om te verduidelik dat toeganklikheid en bruikbaarheid onlosmaaklik aan mekaar gekoppel is en dat dit op die ontwerpstadium gedoen moes word, anders sou dit tot groot veranderinge en herdefinisies van sommige rolle lei. Met die ondersteuning van bestuur en sleutelspelers het ons egter die idee geneem en dit in werking gestel sodat ontwerpe vir toeganklikheid en bruikbaarheid getoets is voordat dit aan die bestuur voorgelê is.

En hierdie terugvoer was uiters waardevol vir almal - dit was fantasties as 'n oefening in kennisdeling/kommunikasie oor hoe gebruikers met webtoepassings omgaan, ons het talle UI-probleemareas geïdentifiseer voordat hulle gebou is, die ontwikkelingspanne het nou baie beter spesifikasies van nie slegs visuele, maar ook gedragsaspekte van ontwerp. Regte besprekings is prettige, energieke, passievolle besprekings oor tegniese aspekte en interaksies.

Ons kan dit selfs beter doen as ons blinde en gestremde gebruikers by hierdie (of daaropvolgende) vergaderings gehad het - dit was moeilik om te organiseer, maar ons werk nou saam met beide plaaslike blinde organisasies en maatskappye, wat eksterne toetse verskaf om die uitvoeringsvloei vroeg in ontwikkeling - beide op die komponent- en uitvoeringsvloeivlakke.

Ingenieurs het nou redelik gedetailleerde spesifikasies, beskikbare komponente wat hulle kan gebruik om te implementeer, en 'n manier om die uitvoeringsvloei te valideer. Deel van wat ervaring ons geleer het, is wat ons die hele tyd gemis het – hoe ons die regressie kan stop. Net so kan mense integrasie of end-tot-end-toetse gebruik om funksionaliteit te toets, wat ons nodig het om veranderinge in interaksies en uitvoeringsvloei op te spoor—beide visueel en gedrag.

Om visuele regressie te bepaal is 'n redelik gedefinieerde taak, daar is baie min wat by die proses gevoeg kan word behalwe om miskien te kyk of fokus sigbaar is wanneer met die sleutelbord navigeer. Meer interessant is twee relatief nuwe tegnologieë om met toeganklikheid te werk.

1. Toeganklikheids insigte is 'n stel gereedskap wat beide in die blaaier en as deel van die bou-/toetssiklus uitgevoer kan word om probleme te identifiseer.
2. Om te verifieer dat skermlesers reg werk, was 'n besonder uitdagende taak. Met die bekendstelling van toegang tot Toeganklikheid DOM, is ons uiteindelik in staat om toeganklikheidfoto's van die toepassing te neem, baie soos ons vir visuele toetse doen, en hulle toets vir regressie.

Dus, in die tweede deel van die storie - ons het beweeg van die redigering van HTML-kode om op 'n hoër vlak van abstraksie te werk, die ontwerpontwikkelingsproses verander en deeglike toetsing ingestel. Nuwe prosesse, nuwe tegnologieë en nuwe vlakke van abstraksie het die landskap van toeganklikheid heeltemal verander en wat dit beteken om in hierdie ruimte te werk.
Maar dit is net die begin.

Die volgende "begrip" is dat blinde gebruikers die nuutste tegnologie dryf - dit is hulle wat nie net die meeste baat by die veranderinge wat ons vroeër beskryf het nie, maar ook dat nuwe benaderings en idees deur ML/AI moontlik gemaak word. Byvoorbeeld, Immersive Reader-tegnologie stel gebruikers in staat om teks makliker en duideliker aan te bied. Dit kan hardop gelees word, sinstruktuur word grammatikaal afgebreek, en selfs woordbetekenisse word grafies vertoon. Dit pas glad nie in by die ou “maak dit toeganklik”-mentaliteit nie – dit is 'n bruikbaarheidsfunksie wat almal sal help.

ML/AI maak heeltemal nuwe maniere van interaksie en werk moontlik, en ons is opgewonde om deel te wees van die volgende fases van hierdie voorpunt-reis. Innovasie word aangedryf deur ’n verandering in denke – die mensdom bestaan ​​al vir millennia, masjiene vir honderde jare, webwerwe vir etlike dekades, en slimfone nog minder, tegnologie moet aanpas by mense, en nie andersom nie.

NS Die artikel is vertaal met geringe afwykings van die oorspronklike. As mede-outeur van hierdie artikel het ek met Hugh ooreengekom oor hierdie afwykings.

Slegs geregistreerde gebruikers kan aan die opname deelneem. Meld aan, asseblief.

Gee jy aandag aan die toeganklikheid van jou toepassings?

• Ja

• Geen

• Dit is die eerste keer dat ek van toepassingtoeganklikheid hoor.

17 gebruikers het gestem. 5 gebruikers het buite stemming gebly.

Bron: will.com