🥇Teejuht juurdepääsetavuse suunas

Reede – tööpäeva lõpp. Halvad uudised jõuavad alati reedel tööpäeva lõpus.

Te olete lahkumas kontorist, kui «ding» on tulnud uus e-kiri järgmise ümberkorraldamise kohta.

Aitäh xxxx, yyy alates tänasest päevast vastutate te zzzz ees.
…
Ja Hugh'i meeskond tagab, et meie tooted oleksid kergesti ligipääsetavad inimestele, kellel on puudeid.

Oh ei! Mille eest ma selle väärisin? Nad tahavad, et ma lahkuks? Pean valmistuma tänamatule, ränkele tööle ja proovima teiste inimeste vigu parandada. See on kindlasti läbikukkumine ...

Selline oli ligipääsetavus mõned aastad tagasi. Mõned kannatajad said töö, et «puhastada» kasutajaliidest, et proovida seda puuetega inimestele ligipääsetavaks teha.

Tegelikult tähendas see üsna ebamugavalt – tõenäoliselt, kui te nägite fookusindikaatorit ja liikusite väljade vahel tabulaatoriga, oleks teil mingi alternatiivne tekst ja paar väljaku kirjeldust, loeti see, et teie rakendus on ligipääsetav …

Kuid äkki hakkasid «vead» paljunema nagu laviin.

Erinevad ekraanilugemisvahendid (ingl. Screen Readers) ja brauserid käitusid täiesti erinevalt.

Kasutajad kurtsid, et rakendus ei ole kasutamiseks sobilik.

Kui viga parandati ühes kohas, ilmus teine kusagil mujal.

Ja lihtsalt kasutajaliidese vigade muutmine ja parandamine nõudis erakordset pingutust.

Ma olin seal. Ma ellu jäin, kuid me ei 'õnnestunud' – tehniliselt puhastasime palju, lisasime palju kirjeldusi väljadele, rolle ja saavutatud mingisugune nõuetele vastavuse tase, kuid keegi ei olnud rahul. Kasutajad kaebasid ikka, et nad ei suuda rakenduses navigeerida. Juht kaebas pideva veavoo üle. Insenerid kaebasid vale probleemihindamise üle, ilma selgelt määratletud 'õige' lahenduseta, mis töötaks kõigis olukordades.

Minu teel ligipääsetavuse mõistmise poole tuli ette mõningaid ilmselgelt avameelseid hetki.
Võib-olla oli esimene mõistmine, et ligipääsetavuse funktsionaalsuse lisamine valmis tootele on keeruline. Ja veelgi keerulisem on veenda juhte, et see on äärmiselt keeruline! Ei, see ei seisne lihtsalt "paaris sildi lisamises" ja kasutajaliides töötab suurepäraselt. Ei, seda ei ole võimalik kolme nädalaga lõpetada, isegi kolm kuud on liiga vähe.
Minu järgmine tõdemus tuli siis, kui ma nägin otse, kuidas nägijad kasutavad meie rakendust. See on nii erinev veateadete vaatamisest.

Ma tulen tagasi sellele korduvalt, kuid peaaegu kõik meie „eeldused“ selle kohta, kuidas inimesed on kasutanud meie rakendust, olid valed.

Ahnus keerulises kasutajaliideses navigeerimine klahvide abil Tab/Shift+Tab – see on talumatu! Vajame midagi paremat. Klaviatuurikombinatsioonid, pealkirjad.

UI muutmisel fookuse kaotamine ei ole suur probleem? Mõtleme uuesti – see on äärmiselt segadust tekitav.

Jätkasin, töötasin mõnda aega erinevate projektide kallal, kuni alustasime uut projekti, millel oli keeruline kasutajaliides ja selge suund, et seekord saavutada õige ligipääsetavus.

Nii et me astusime samm tagasi ja vaatasime, kuidas saame selle teistsuguseks teha ja edu saavutada, ning et tööprotsess oleks ebamugav!

Suhteliselt kiiresti jõudsime mõningate järeldusteni:

Me ei tahtnud, et kasutajaliidese arendajad tegeleksid aria märgiste/rollide ja loomulikult komponentide HTML-struktuuriga. Me pidime tagama, et neil oleksid õiged komponendid, kus ligipääsetavus oleks välja töötatud otse kastist.
Kasutatavus = Juhtimissüsteem - see ei ole ainult tehniline ülesanne. Me pidime seadma ümber kogu projekteerimisprotsessi ja tagama, et juurdepääsetavus arvesse võetakse ja arutatakse enne kasutajaliidese projekteerimist. Tuleb algusest peale mõelda, kuidas kasutajad saavad leida mingit funktsionaalsust, kuidas nad liikuda saavad ja kuidas „hiire paremklikk” klaviatuuri abil töötab. Juurdepääsetavus peab olema osa projekteerimisprotsessist - mõne kasutaja jaoks on see midagi palju enamat kui lihtsalt rakenduse välimus.
Juba varakult soovisime saada tagasisidet pimedate ja teiste erivajadustega kasutajate arvamustest rakenduse kasutusmugavuse kohta.
Tõeliselt head meetodid juurdepääsetavuse regressioonide jälgimiseks olid vajalikud.

Noh, inseneri seisukohalt, kõlas esimene osa üsna põnevalt - arhitektuuri arendamine ja komponente raamatukogu rakendamine. Ja tõepoolest, nii see oligi.

Astudes sammu tagasi, vaadates ARIA näiteid Ja mõtleme sellele kui disaini probleemile, mitte 'kohandamise' probleemile, oleme sisse viinud mõned abstraktsed mõisted. Komponent omab 'Struktuuri' (koosneb HTML-elementidest) ja 'Käitumist' (kuidas see kasutajaga suhtleb). Näiteks alltoodud fragmentides on meil lihtne määramata nimekiri. Kui lisame nimekirjale 'käitumise', lisatakse vastavad rollid, et see toimiks nimekirjana. Sama teeme ka menüüga.

Tegelikult lisatakse siia mitte ainult rolle, vaid ka sündmuste töötlejad navigeerimiseks klaviatuuri abil.

See juba näeb korralikum välja. Kui suudaksime saavutada puhta eristamise nende vahel, ei oleks oluline, kuidas struktuur loodi, võiksime sellele rakendada käitumisi (Behaviours) ja saavutada õige ligipääsetavuse.

Seda saab praktikas näha aadressil https://stardust-ui.github.io/react/ – UX raamatukogus React, mis on kavandatud ja ellu viidud ligipääsetavuse arvestamisega alates algusest.

Teise osa – lähenemise ja protsesside muutmine disaini ümber ehmatas mind alguses: tagasihoidlikud insenerid, kes püüdsid viia ellu organisatsioonilisi muutusi, ei lõppenud alati hästi, kuid see osutus üheks kõige huvitavamaks valdkonnaks, kus me tegime märkimisväärse panuse protsessi. Lühidalt öeldes oli meil järgmine protsess: uus funktsionaalsus töötati välja ühe meeskonna poolt, seejärel meie juhtgrupp analüüsis / iteratsioonis seda ettepanekut ning pärast heakskiitu edastati disain tavaliselt inseneride meeskonnale. Sellisel juhul „omastas” inseneride meeskond juurdepääsetavuse funktsionaalsuse, kuna nad pidid lahendama kõik sellega seotud probleemid.

Alguses oli see üsna keeruline töö – selgitada, et ligipääsetavus ja kasutusmugavus on tihedalt seotud ning et see tuleb arvesse võtta juba projekteerimise etapis, vastasel juhul viib see suurte muudatuste ja mõnede rollide ümbersuunamiseni. Sellegipoolest, juhtkonna ja võtmeisikute toetusel, edastasime selle idee ja panime selle tööle, et kujundused läbiksid ligipääsetavuse ja kasutusmugavuse kontrolli enne, kui need ette kantakse juhtkonnale.

Ja need tagasisided olid kõikidele äärmiselt väärtuslikud – see oli fantastiline teadmiste vahetamise harjutus, kuidas kasutajad suhtlevad veebirakendustega. Me tuvastasime arvukad kasutajaliidese probleemsed kohad enne nende ehitamist. Arendustiimidel on nüüd tunduvalt paremad spetsifikatsioonid, mis käsitlevad mitte ainult visuaalseid, vaid ka käitumuslikke disainiaspekte. Tegelikud arutelud – need on lõbusad, energilised ja kirglikud arutelud tehniliste aspektide ja interaktsioonide üle.

Me saaksime selle töö veelgi paremini teha, kui nendel (või järgmistel) kohtumistel oleksid kohal nägemispuudega ja erivajadustega kasutajad – see oli keeruline korraldada, kuid nüüd teeme koostööd nii kohalike nägemispuudega organisatsioonidega kui ka ettevõtetega, kes pakuvad välist testimist kostumuse kontrollimiseks arenduse varases staadiumis – nii komponentide kui ka jõudluse tasemel.

Nüüd on inseneridel üsna üksikasjalikud spetsifikatsioonid, kergesti kättesaadavad komponendid, mida nad saavad rakendamiseks kasutada, ja meetod, kuidas kontrollida töövoogu. Osaliselt on kogemus õpetanud meile, mida me pidevalt unustasime – kuidas me saame takistada regressiooni. Samuti saavad inimesed kasutada integratsioonikatseid või lõplikke teste, et kontrollida funktsionaalsust, mis on vajalik muudatuste avastamiseks interaktsioonides ja töövoogudes – nii visuaalsetes kui ka käitumuslikes.

Visuaalse regressiooni määratlemine on üsna konkreetne ülesanne, lisada sellele protsessile on väga vähe, ehkki võib-olla tuleb kontrollida, kas klaviatuuriga navigeerimisel on fookus nähtav. Kaks suhteliselt uut tehnoloogiat ligipääsetavuse osas on palju huvitavamad.

Accessibility Insights on tööriistakomplekt, mida saab kasutada nii brauseris kui ka ehitamis-/testimisprotsessi käigus probleemide tuvastamiseks.
Ekraanilugude töö kontrollimine oli eriti keeruline ülesanne. Ligipääsuandmete tutvustamisega Accessibility DOM, oleme lõpuks saanud võimaluse teha rakenduse ligipääsetavuse vaatenurgast ekranipilte, mis on väga sarnased sellele, kuidas me neid visuaalsete testide jaoks teeme, ning kontrollida neid regressiooni suhtes.

Nii et teise osa loo kohaselt - oleme liikunud HTML-koodi redigeerimiselt kõrgema abstraktsioonitaseme tööle, muutes disainiprotsessi ja viies sisse põhjaliku testimise. Uued protsessid, uued tehnoloogiad ja uued abstraktsioonitasemed on täielikult muutnud arusaama ligipääsetavusest ja sellest, mida tähendab selles valdkonnas töötamine.
Kuid see on alles algus.

Järgnev "teadlikkus" on see, et nägemispuudega kasutajad edendavad uuenduslikke tehnoloogiaid – just nemad saavad kasu mitte ainult eelnevalt kirjeldatud muudatustest, vaid ka sellest, et uued lähenemised ja ideed saavad võimalikuks ML/AI abil. Näiteks Immersive Readeri tehnoloogia võimaldab kasutajatel teksti paremini ja arusaadavamalt esitada. Seda saab lugeda valjult, lause struktuur jagatakse grammatiliselt ning isegi sõnade tähendused kuvatakse graafiliselt. See ei sobitu sugugi vanasse arusaamisse „teha see kergesti kättesaadavaks“ – see on kasutatavuse funktsioon, mis aitab kõiki.

ML/AI toovad esile täiesti uued viisid suhtlemiseks ja töötamiseks ning meil on hea meel olla osa järgmistest sammudest selles uuenduslikus teekonnas. Innovatsioon tuleneb mõtteviisi muutumisest – inimkond on eksisteerinud tuhandetega, masinad sajanditega, veebilehed paarikümnega ja nutitelefonid veelgi vähem, tehnoloogia peab kohanduma inimeste järgi, mitte vastupidi.

P.S. Artikkel on tõlgitud väikeste kõrvalekalletega originaalist. Kuna olen selle artikli kaasautor, olen need kõrvalekalded kooskõlastanud Hughiga.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.