🥇Käegakatsutav kättesaadavuse suunas

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

Olete lahkumas kontorist, kui tuli uus e-kiri reorganiseerimise kohta.

Aitäh xxxx, yyy, alates tänasest vastutate zzzz ees.
…
Ja Hugh'i meeskond tagab meie toodete juurdepääsetavuse erivajadustega inimestele.

Oh ei! Mille eest ma seda teen? Kas nad tahavad, et ma lahkuks? Valmistuda tänamatu raske tööks ja püüda parandada teiste inimeste vigu. See on kindlasti läbikukkumine...

Selline oli juurdepääsetavus mõned aastat tagasi. Mõned hädalised said töö, et 'koristada' kasutajaliidest, et teha see juurdepääsetavaks erivajadusega inimestele.

Tegelikult tähendas see üsna häguselt – tõenäoliselt, kui sa suutsid näha fookuse indikaatorit ja liikuda väljadesse tabiga, olla mingi alternatiivne tekst ja paar väljade kirjeldust, siis arvestati, et teie rakendus on juurdepääsetav…

Kuid äkki hakkasid 'vead' paljunema nagu laviin.

Erinevad ekraanilugejad (inglise. Screen Readers) ja brauserid käitusid täiesti erinevalt.

Kasutajad kaebasid, et rakendus ei ole kasutatav.

Niipea kui üks viga parandati, ilmnes kusagil teine.

Ja lihtsalt kasutajaliidese vigade muutmine ja parandamine nõudis hiiglaslikke jõupingutusi.

Ma olin seal. Ma ellu jäin, kuid me ei 'õnnestunud' – tehniliselt puhastasime palju, lisasime palju väljateid ja saavutatud vastavust, aga keegi ei olnud rahul. Kasutajad ikka kaebasid, et ei suuda rakenduses orienteeruda. Juht kaebas pideva veade voogu. Insenerid kaebasid vale ülesande määramise üle, ilma selgelt määratletud ' õige' lahenduseta, mis töötaks igas olukorras.

Minu teel juurdepääsetavuse mõistmise poole tuli ette mõned ilmsed äratundmishetked.
Võimalik, et esimene arusaam oli see, et juurutada ligipääsetavuse funktsionaalsus valmis toote peale – see on keeruline. Ja veelgi keerulisem on veenda juhte, et see on uskumatult keeruline! Ei, see ei tähenda lihtsalt "mõne sildi lisamist" ja kasutajaliides töötab suurepäraselt. Ei, see ei ole võimalik kolme nädalaga lõpetada, isegi kolm kuud jääb väheks.
Minu järgmine tõdemus tuli siis, kui ma nägin, kuidas pimedad kasutajad meie rakendust tegelikult kasutavad. See on NII erinev vigade teateid vaadates.

Ma tulen selle juurde tagasi korduvalt, kuid peaaegu kõik meie "eeldused" selle kohta, kuidas inimesed meie rakendust kasutasid, olid vale.

Kliendi liidese keerulistest navigeerimist klaviatuuriga Tab/Shift+Tab on tõeline jama! Me vajame midagi paremat. Klahvikombinatsioonid, pealkirjad.

Kas fookuse kaotus liidese muutmisel ei ole suur probleem? Mõtleme veel kord – see on uskumatult segadusttekitav.

Ma jätkasin, töötasin mõnda aega erinevate projektidega, kuni me alustasime uut projekti, keerulise kasutajaliidese ja selge eesmärgiga – lõpuks õigete ligipääsetavuse lahenduste saavutamine.

Nii et me astusime sammu tagasi ja vaatasime, kuidas saame selle hoopis teisiti ellu viia ja edutult suutma, et tööprotsess oleks ka huvitav!

Suhteliselt kiiresti jõudsime mitmete järeldusteni:

Me ei tahtnud, et kasutajaliidese arendajad jamaksid aria siltide/rollidega ja loomulikult komponentide HTML struktuuriga. Me pidime tagama neile õigeid komponente, kus ligipääsetavus on välja töötatud otse karbist.
Ligipääsetavus == Kasutatavus – see ei ole ainult tehniline ülesanne. Me pidime muutma kogu disainiprotsessi ja veenduma, et ligipääsetavust arvestatakse ja arutatakse enne kasutajaliidese projekteerimise algust. Tuleb alguses mõelda, kuidas kasutajad saavad avastada mis tahes funktsionaalsuse, kuidas nad liiguvad ja kuidas "hiire parema klõpsuga" klaviatuurilt töötab. Ligipääsetavus peab olema disainiprotsessi lahutamatu osa – mõnele kasutajale on see midagi palju enamat kui lihtsalt rakenduse välimus.
Alates esimesest päevast soovisime saada tagasisidet pimedatelt ja teistelt erivajadustega kasutajatelt rakenduse kasutusmugavuse kohta.
Vajasime tõeliselt häid viise, et tuvastada ligipääsetavuse regressioon.

Noh, inseneri seisukohast tundus esimene osa üsna lõbus - arhitektuuri arendamine ja komponentide raamatukogu rakendamine. Ja tõepoolest, see oligi nii.

Vaadates tagasi, arvestades ARIA näiteid ja mõeldes sellele kui disainiprobleemile, mitte probleemile „kohandumises”, oleme tutvustanud teatud abstraktsioone. Komponent on koos 'Struktuuri' (mis koosneb HTML-elementidest) ja 'Käitumisega' (kuidas see kasutajaga suhtleb). Näiteks allpool toodud fragmentides on meil lihtne järjekorratu loend. Loendile käitumise lisamiseks lisatakse vastavad rollid, et see toimiks kui loend. Teeme sama ka menüü jaoks.

Tegelikult lisatakse siia mitte ainult rollid, vaid ka sündmuste töötlejate jaoks klaviatuuriga navigeerimiseks.

See näeb juba palju korralikum välja. Kui me saaksime saavutada puhta eristuse nende vahel, ei oleks oluline, kuidas struktuur on loodud, saaksime rakendada sellele käitumisi (Behaviours) ja saavutada õige ligipääsetavuse.

Seda saab näha aadressil https://stardust-ui.github.io/react/ – UX raamatukogus React, mis on projekteeritud ja rakendatud ligipääsetavuse arvessevõtmisega alates algusest.

Teine osa - lähenemise ja protsesside muutmine disaini ümber hirmutas mind alguses: tagasihoidlikud insenerid, kes püüavad edendada organisatsioonilisi muudatusi, ei lõppe alati hästi, kuid see osutus üheks kõige huvitavamaks valdkonnaks, kus oleme protsessi olulise panuse andnud. Lühidalt öeldes oli meil järgmine protsess: uus funktsionaalsus töötati välja ühe meeskonna poolt, seejärel analüüsis ja iteratsioonis meie juhtgrupp seda ettepanekut, ja siis, pärast heakskiitu, anti disain tavaliselt inseneride meeskonnale üle. Sel juhul „omanik” inseneride meeskond tegelikult ligi pääsetavuse funktsionaalsusest, kuna nad pidid eemaldama kõik sellega seotud probleemid.

Alguses oli see üsna keeruline ülesanne – selgitada, et ligipääsetavus ja kasutatavus on omavahel tihedalt seotud ning et seda on vaja arvestada juba projekteerimise etapis, vastasel juhul toob see kaasa suuri muudatusi ja mõningate rollide ümbermääramist. Siiski, juhtkonna ja võtmeisikute toetusel suutsime selle idee edastada ning viia ellu, et kujundused läbisid ligipääsetavuse ja kasutatavuse kontrolli, enne kui need esitatakse juhile.

Need tagasisided olid äärmiselt väärtuslikud kõigile – see oli fantastiline teave vahetamise harjutus, kuidas kasutajad veebirakendustega suhtlevad; määrasime mitmeid kasutajaliidese probleemseid valdkondi enne nende loomist, praegu on arendustiimidel palju paremad spetsifikatsioonid mitte ainult visuaalsete, vaid ka käitumuslike disaini aspektide kohta. Reaalsed arutelud on lõbusad, energilised, kirglikud diskussioonid tehniliste aspektide ja interaktsioonide üle.

Saaksime seda tööd veelgi paremaks muuta, kui neil (või järgmistel) koosolekutel oleksid kohal nägemispuudega kasutajad ja puuetega inimesed – seda oli raske korraldada, kuid nüüd teeme tõeliselt koostööd nii kohalikest nägemispuudega organisatsioonidest kui ka ettevõtetest, mis pakuvad välist testimist, et kontrollida töövoogude käitumist arendamise varajastes etappides – nii koostisosade kui ka töövoogude tasandil.

Nüüd on inseneridel üsna üksikasjalikud spetsifikatsioonid, kergesti kättesaadavad komponendid, mida nad saavad kasutada juurutamiseks, ja meetod töövoogude kontrollimiseks. Osaliselt on kogemus õpetanud meid, mida pidevalt unustame – kuidas saame regresseerimise peatada. Samuti saavad inimesed kasutada integratsiooniteste või lõpp-teste, et kontrollida funktsionaalsust, mida vajame interaktsioonide ja töövoogude muutuste avastamiseks – nii visuaalsete kui käitumuslike.

Visuaalse regressiooni määratlemine on üsna spetsiifiline ülesanne, millega on vähe lisada, välja arvatud võib-olla kontrollimine, kas fookus on nähtav navigeerimisel klaviatuuri abil. Kaugelt huvitavamad on kaks suhteliselt uut tehnoloogiat ligipääsetavuse töötamiseks.

Accessibility Insights on tööriistade komplekt, mida saab kasutada nii brauseris kui ka kogumise/testimise tsüklis probleemide leidmiseks.
Ekraanilugejatega töötamise kontrollimine oli eriti keeruline ülesanne. Ligipääsu andmete kasutusele võtuga Accessibility DOM, saime lõpuks võimaluse teha rakendustest ligipääsetavuse seisukohalt fotosid, mis meenutavad väga neid, mida teeme visuaalsete testide jaoks, ja kontrollida neid regressiooni vastu.

Nii et teisel ajaloo poolel – oleme liikunud HTML-koodi redigeerimise juurest kõrgema abstraktsioonitaseme töötamise suunas, muutes disainiarenduse protsessi ning viies sisse hoolika testimise. Uued protsessid, uued tehnoloogiad ja uued abstraktsioonitasemed on täielikult muutnud arusaama ligipääsetavusest ja sellest, mida see valdkonnas töötamine tähendab.
See on alles algus.

Järgmine "arusaam" on see, et pimedad kasutajad edendavad uusi tehnoloogiaid – just nemad saavad kõige rohkem kasu mitte ainult varem kirjeldatud muudatustest, vaid ka sellest, et uued lähenemisviisid ja ideed saavad võimalikuks ML/AI abil. Näiteks, tehnoloogia Immersive Reader võimaldab kasutajatel teksti lihtsamalt ja selgemini esitada. Seda saab lugeda valjult, lause struktuur jaguneb grammatiliselt ja isegi sõnade tähendused kuvatakse graafiliselt. See ei sobi absoluutselt vanasse arusaama "teha see ligipääsetavaks" – see on kasutatavuse funktsioon, mis aitab kõiki.

ML/AI toovad esile täiesti uusi viise suhtlemiseks ja töötamiseks ning me oleme rõõmsad, et saame osa võtta tulevaste etappide edasiviimisest. Innovatsioonid on tingitud mõtteviisi muutumisest – inimkond on eksisteerinud tuhandete aastate jooksul, masinad – sadu aastaid, veebisaidid paari kümne aasta jooksul, ja nutitelefonid veelgi vähem, tehnoloogia peab kohanduma inimeste järgi, mitte vastupidi.

P.S. Artikkel on tõlgitud väikeste kõrvalekalletega originaalist. Artikli kaasautoris olen need kõrvalekalded kokku leppinud Hugh’ga.

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