Reedel on tööpäeva lõpp. Halvad uudised tulevad alati reedese tööpäeva lõpus.
Oled kontorist lahkumas, just saabus postiga uus kiri järjekordse ümberkorralduse kohta.
Aitäh xxxx, yyy alates tänasest teavitate zzzz-st
...
Ja Hughi meeskond tagab, et meie tooted on puuetega inimestele kättesaadavad.
Oh ei! Miks ma selle ära teenisin? Kas nad tahavad, et ma lahkuksin? Seadke end tänamatuks raskeks tööks ja püüdke parandada teiste inimeste vigu. See on kindlasti ebaõnnestumine ...
Selline oli saadavus paar aastat tagasi. Mõnele vaesele hingele anti ülesanne kasutajaliides "puhastada", et teha see puuetega inimestele kättesaadavaks.
Mida see tegelikult tähendas, oli üsna ebamäärane – arvatavasti, kui näete fookuse indikaatorit ja tabeldusmärki läbi väljade, teil on alternatiivteksti ja paar väljade kirjeldust, peetakse teie rakendust juurdepääsetavaks ...
Kuid järsku hakkasid "vead" laviini kiirusel paljunema.
Erinevad ekraanilugejad (Eng. Ekraanilugejad) ja brauserid käitusid täiesti erinevalt.
Kasutajad on kurtnud, et rakendus on kasutuskõlbmatu.
Niipea, kui ühes kohas viga parandati, tekkis teises teine.
Ja lihtsalt kasutajaliidese vigade muutmine ja parandamine nõudis Heraklese jõupingutusi.
Ma olin seal. Elasin üle, aga "ei õnnestunud" - tehniliselt koristasime palju, lisasime palju valdkonnakirjeldusi, rolle ja saavutasime mingilgi tasemel vastavuse, aga keegi ei olnud rahul. Kasutajad kaebasid endiselt, et nad ei saa rakenduses navigeerida. Juhataja kurtis endiselt pideva vigade voo üle. Insenerid kaebasid, et probleem püstitati valesti, ilma selgelt määratletud "õige" lahenduseta, mis toimiks kõigil juhtudel.
Minu teekonnal ligipääsetavuse mõistmiseni oli mõningaid selgelt silmi avavaid hetki.
Võib-olla esimene oli arusaam, et juurdepääsetavuse funktsiooni lisamine valmistootele oli keeruline. Ja veelgi raskem on juhte veenda, et see on uskumatult raske! Ei, see pole lihtsalt "paar sildi lisamine" ja kasutajaliides töötab suurepäraselt. Ei, seda ei saa teha kolme nädalaga, isegi kolmest kuust ei piisa.
Minu järgmine tõehetk saabus siis, kui nägin omal nahal, kuidas pimedad kasutajad meie rakendust tegelikult kasutasid. See erineb NII veateadete vaatamisest.
Ma tulen selle juurde ikka ja jälle tagasi, kuid peaaegu kõik meie "eeldused" selle kohta, kuidas inimesed meie rakendust kasutasid, olid valed.
Keerulises kasutajaliideses navigeerimine klahvivajutuste abil Tab/Shift+Tab - see on nõme! Me vajame midagi paremat. Klaviatuuri otseteed, päised.
Fookuse kaotamine kasutajaliidese muutmisel pole suur probleem, kas pole? Mõelgem uuesti – see on uskumatult segane.
Jätkasin, töötasin mõnda aega erinevate projektidega ja siis alustasime uue projektiga, keerulise kasutajaliidese ja selge installatsiooniga, et seekord lõpuks ometi ligipääsetavus õigeks saada.
Niisiis, astusime sammu tagasi ja vaatasime, kuidas saaksime seda teistmoodi rakendada ja õnnestuda ning muuta protsess vähem igavaks!
Üsna kiiresti jõudsime järeldusele:
- Me ei tahtnud, et kasutajaliidest arendavad inimesed segaksid aria siltide/rollidega ja loomulikult komponentide HTML-i struktuuriga. Meil oli vaja pakkuda neile õigeid komponente, mis loovad juurdepääsetavuse kohe karbist välja.
- Juurdepääsetavus == Kasutusmugavus – st. See ei ole ainult tehniline väljakutse. Peame muutma kogu disainiprotsessi ja tagama, et juurdepääsetavust võetaks arvesse ja arutataks enne kasutajaliidese kujundamise algust. Peate varakult mõtlema, kuidas kasutajad mis tahes funktsioonid avastavad, kuidas nad navigeerivad ja kuidas klaviatuuril paremklõpsamine töötab. Juurdepääsetavus peaks olema disainiprotsessi lahutamatu osa – mõne kasutaja jaoks on see palju enamat kui lihtsalt rakenduse välimus.
- Tahtsime algusest peale saada pimedatelt ja teistelt puuetega kasutajatelt tagasisidet rakenduse kasutusmugavuse kohta.
- Vajasime tõeliselt häid viise juurdepääsetavuse regressioonide tabamiseks.
Noh, inseneri seisukohalt kõlas esimene osa päris lõbusalt – arhitektuuri arendamine ja komponentide teegi juurutamine. Ja nii see tõepoolest oli.
Astudes sammu tagasi, vaadates ja pidades seda pigem disainiprobleemiks kui "sissesobitamise" probleemiks, võtsime kasutusele mõned abstraktsioonid. Komponendil on 'Struktuur' (koosneb HTML-i elementidest) ja 'Käitumine' (kuidas see kasutajaga suhtleb). Näiteks allolevates väljalõigetes on meil lihtne järjestamata loend. "Käitumiste" lisamisega lisatakse loendisse vastavad rollid, nii et see toimib loendina. Sama teeme ka menüüga.
Tegelikult pole siia lisatud mitte ainult rolle, vaid ka sündmuste käitlejaid klaviatuuril navigeerimiseks.
See näeb korralikum välja. Kui saaksime need üksteisest puhtalt eraldada, poleks vahet, kuidas struktuur loodi, saaksime sellele rakendada käitumise ja muuta juurdepääsetavuse õigeks.
Näete seda tegevuses aadressil - UX raamatukogu , mis on loodud ja juurutatud algusest peale juurdepääsetavust silmas pidades.
Teine osa – disainiga seotud lähenemisviisi ja protsesside muutmine hirmutas mind alguses: madalad insenerid, kes üritavad läbi suruda organisatsioonilisi muutusi, ei lõpe alati hästi, kuid see osutus üheks huvitavamaks valdkonnaks, kus me protsessi oluliselt kaasa aitasime. . Lühidalt oli meie protsess järgmine: uus funktsionaalsus töötaks välja üks meeskond, seejärel vaatas meie juhtkond ettepaneku läbi/kordustab ja pärast heakskiitmist antakse kujundus tavaliselt üle inseneride meeskonnale. Sellisel juhul kuulus juurdepääsetavuse funktsioon insenerimeeskonnale, sest nende ülesanne oli lahendada kõik sellega seotud probleemid.
Alguses oli päris keeruline töö seletada, et juurdepääsetavus ja kasutatavus on lahutamatult seotud ning seda tuleb teha juba projekteerimisetapis, sest muidu toob see kaasa suuri muutusi ja mõne rolli ümberdefineerimise. Kuid juhtkonna ja võtmeisikute toel võtsime idee kasutusele ja viisime selle ellu, nii et disainilahenduste juurdepääsetavust ja kasutatavust testiti enne nende juhtkonnale esitamist.
Ja see tagasiside oli kõigile äärmiselt väärtuslik – see oli fantastiline teadmiste jagamise/suhtlemise harjutus selle kohta, kuidas kasutajad veebirakendustega suhtlevad, tuvastasime enne nende loomist arvukalt kasutajaliidese probleemseid valdkondi, nüüd on arendusmeeskondadel palju paremad spetsifikatsioonid ainult disaini visuaalsed, aga ka käitumuslikud aspektid. Tõelised arutelud on lõbusad, energilised ja kirglikud arutelud tehniliste aspektide ja koostoimete üle.
Saaksime seda veelgi paremini teha, kui meil oleks neil (või järgnevatel) koosolekutel pimedaid ja puudega kasutajaid – seda oli keeruline korraldada, kuid teeme nüüd koostööd nii kohalike pimedate organisatsioonide kui ka ettevõtetega , kes pakuvad välistesti, et kontrollida täitmise voogu varakult. arendus – nii komponendi kui ka täitmise voo tasemel.
Inseneridel on nüüd üsna üksikasjalikud spetsifikatsioonid, saadaolevad komponendid, mida nad saavad rakendamiseks kasutada, ja viis täitmisvoo kinnitamiseks. Osa sellest, mida kogemus on meile õpetanud, on see, millest oleme kogu aeg puudust tundnud – kuidas saaksime taandarengu peatada. Samuti saavad inimesed funktsionaalsuse testimiseks kasutada integratsiooni või täielikke teste, mida vajame interaktsioonide ja täitmisvoogude muutuste tuvastamiseks – nii visuaalsetes kui käitumuslikes.
Visuaalse regressiooni määramine on üsna määratletud ülesanne, protsessile saab väga vähe lisada muud kui võib-olla kontrollida, kas klaviatuuriga navigeerimisel on fookus nähtav. Huvitavamad on ligipääsetavuse töötamiseks kaks suhteliselt uut tehnoloogiat.
- on tööriistade komplekt, mida saab probleemide tuvastamiseks käivitada nii brauseris kui ka ehitus-/testimistsükli osana.
- Ekraanilugerite korrektse töötamise kontrollimine on olnud eriti keeruline ülesanne. Juurdepääsu juurutamisega Juurdepääsetavus DOM, saame lõpuks teha rakendusest juurdepääsetavuse hetktõmmiseid, nagu visuaalsete testide puhul, ja testida neid regressiooni suhtes.
Niisiis liikusime loo teises osas HTML-koodi redigeerimiselt kõrgemal abstraktsioonitasemel tööle, muutsime disaini arendusprotsessi ja võtsime kasutusele põhjaliku testimise. Uued protsessid, uued tehnoloogiad ja uued abstraktsioonitasemed on täielikult muutnud ligipääsetavuse maastikku ja seda, mida tähendab selles ruumis töötamine.
Kuid see on alles algus.
Järgmine "arusaam" on see, et pimedad kasutajad juhivad tipptehnoloogiat – just nemad saavad kõige rohkem kasu mitte ainult varem kirjeldatud muudatustest, vaid ka sellest, et ML/AI võimaldab uusi lähenemisviise ja ideid. Näiteks võimaldab Immersive Reader tehnoloogia kasutajatel teksti lihtsamalt ja selgemalt esitada. Seda saab ette lugeda, lausestruktuur on grammatiliselt jaotatud ja isegi sõnade tähendused kuvatakse graafiliselt. See ei sobi sugugi vanasse "tee ligipääsetavaks" mentaliteediga – see on kasutatavuse funktsioon, mis aitab kõiki.
ML/AI võimaldab täiesti uusi suhtlemis- ja tööviise ning meil on hea meel olla osa selle tipptasemel teekonna järgmistest etappidest. Innovatsiooni veab mõtlemise muutumine – inimkond on eksisteerinud aastatuhandeid, masinad sadu aastaid, veebilehed mitu aastakümmet ja nutitelefonid veel vähem, tehnoloogia peab kohanema inimestega, mitte vastupidi.
P.S. Artikkel on tõlgitud väikeste kõrvalekalletega originaalist. Selle artikli kaasautorina nõustusin Hugh'ga nendes kõrvalepõigetes.
Küsitluses saavad osaleda ainult registreerunud kasutajad. palun.
Kas pöörate tähelepanu oma rakenduste juurdepääsetavusele?
-
Jah
-
ei
-
See on esimene kord, kui kuulen rakenduste juurdepääsetavuse kohta.
17 kasutajat hääletas. 5 kasutajat jäi erapooletuks.
Allikas: www.habr.com