K dostopnosti

K dostopnosti

Petek je konec delovnega dne. Slabe novice vedno pridejo ob koncu delovnega dne v petek.

Zapuščate pisarno, po pošti je pravkar prispelo novo pismo o še eni reorganizaciji.

Hvala xxxx, yyy od danes naprej se boš javljal zzzz
...
In Hughova ekipa bo poskrbela, da bodo naši izdelki dostopni osebam s posebnimi potrebami.

Oh ne! Zakaj sem si to zaslužil? Ali hočejo, da odidem? Pripravite se na nehvaležno trdo delo in poskušajte popraviti napake drugih ljudi. To je vsekakor neuspeh ...

To je bilo na voljo pred nekaj leti. Nekaj ​​ubožcev je dobilo nalogo, da "očistijo" uporabniški vmesnik, da bi ga poskušali narediti dostopnega invalidom.

Kaj je to dejansko pomenilo, je bilo precej nejasno - če bi lahko videli indikator fokusa in tabulator skozi polja, imeli nekaj nadomestnega besedila in nekaj opisov polj, bi veljalo, da je vaša aplikacija dostopna ...

Toda nenadoma so se "hrošči" začeli množiti s hitrostjo plazu.

Različni bralniki zaslona (Angleščina Bralniki zaslona) in brskalniki so se obnašali povsem drugače.

Uporabniki so se pritoževali, da je aplikacija neuporabna.

Takoj ko je bila napaka na enem mestu popravljena, se je na drugem pojavila druga.

In preprosto spreminjanje in popravljanje napak uporabniškega vmesnika je zahtevalo Herkulova prizadevanja.

Jaz sem bil tam. Preživel sem, a nam ni »uspelo« – tehnično smo veliko počistili, dodali veliko opisov polj, vlog in dosegli neko stopnjo skladnosti, a nihče ni bil zadovoljen. Uporabniki so se še vedno pritoževali, da ne morejo krmariti po aplikaciji. Upravitelj se je še vedno pritoževal nad stalnim tokom napak. Inženirji so se pritoževali, da je bil problem zastavljen nepravilno, brez jasno opredeljene "pravilne" rešitve, ki bi delovala v vseh primerih.

Na moji poti do razumevanja dostopnosti je bilo nekaj odmevnih trenutkov.
Morda je bilo prvo spoznanje, da je dodajanje funkcij dostopnosti na vrhu končnega izdelka težko. In še težje je menedžerje prepričati, da je to neverjetno težko! Ne, ne gre samo za "dodajte nekaj oznak" in uporabniški vmesnik bo deloval v redu. Ne, tega se ne da narediti v treh tednih, tudi trije meseci ne bodo dovolj.
Moj naslednji trenutek resnice je prišel, ko sem iz prve roke videl, kako slepi uporabniki dejansko uporabljajo našo aplikacijo. To se ZELO razlikuje od gledanja sporočil o napakah.

K temu se bom vračal znova in znova, vendar so bile skoraj vse naše "predpostavke" o tem, kako so ljudje uporabljali našo aplikacijo, napačne.

Krmarjenje po kompleksnem uporabniškem vmesniku z uporabo tipk Tab/Shift+Tab – to je zanič! Potrebujemo nekaj boljšega. Bližnjice na tipkovnici, glave.

Izguba fokusa pri spreminjanju uporabniškega vmesnika ni velika težava, kajne? Pomislimo še enkrat - to je neverjetno zmedeno.

Nadaljeval sem, nekaj časa delal na različnih projektih, nato pa smo začeli nov projekt s kompleksnim uporabniškim vmesnikom in jasno namestitvijo, da bi tokrat končno dobili pravo dostopnost.

Zato smo naredili korak nazaj in pogledali, kako bi lahko to implementirali drugače in uspeli ter naredili postopek manj dolgočasen!

Kar hitro smo prišli do nekaterih zaključkov:

  1. Nismo želeli, da bi se ljudje, ki razvijajo uporabniški vmesnik, ubadali z arijskimi oznakami/vlogami in seveda strukturo HTML komponent. Zagotoviti smo jim morali prave komponente, ki so zgradile dostopnost takoj po izdelavi.
  2. Dostopnost == Enostavnost uporabe – tj. To ni samo tehnični izziv. Morali smo spremeniti celoten proces oblikovanja in zagotoviti, da je bila dostopnost upoštevana in obravnavana pred začetkom oblikovanja uporabniškega vmesnika. Že zgodaj morate razmišljati, kako bodo uporabniki odkrili katero koli funkcionalnost, kako bodo krmarili in kako bo deloval desni klik na tipkovnici. Dostopnost bi morala biti sestavni del procesa oblikovanja – za nekatere uporabnike je veliko več kot le videz aplikacije.
  3. Že od samega začetka smo želeli od slepih in drugih invalidov pridobiti povratne informacije o enostavnosti uporabe aplikacije.
  4. Potrebovali smo res dobre načine, da bi ujeli regresije dostopnosti.

No, z inženirskega vidika je prvi del zvenel precej zabavno - razvijanje arhitekture in implementacija knjižnice komponent. In res je bilo tako.

Korak nazaj, pogled Primeri ARIA in z razmišljanjem o tem kot o problemu načrtovanja in ne o problemu "prileganja", smo uvedli nekaj abstrakcij. Komponenta ima 'strukturo' (sestoji iz elementov HTML) in 'obnašanje' (kako deluje z uporabnikom). Na primer, v spodnjih delčkih imamo preprost neurejen seznam. Z dodajanjem »vedenja« se ustrezne vloge dodajo na seznam, da deluje kot seznam. Enako naredimo za jedilnik.

K dostopnosti

Pravzaprav tukaj niso dodane samo vloge, ampak tudi obdelovalci dogodkov za navigacijo s tipkovnico.

To izgleda bolj urejeno. Če bi jih lahko jasno ločili, ne bi bilo pomembno, kako je bila struktura ustvarjena, lahko bi zanjo uporabili Behaviors in dobili pravo dostopnost.

To lahko vidite v akciji na https://stardust-ui.github.io/react/ – Knjižnica UX Reagirajo, ki je zasnovan in implementiran z mislijo na dostopnost že od samega začetka.

Drugi del - sprememba pristopa in procesov okoli oblikovanja me je sprva prestrašil: nizki inženirji, ki poskušajo preriniti organizacijske spremembe, se ne končajo vedno dobro, vendar se je izkazalo, da je to eno najzanimivejših področij, kjer smo pomembno prispevali k procesu . Na kratko, naš postopek je bil naslednji: novo funkcionalnost bi razvila ena ekipa, nato bi naša vodstvena ekipa pregledala/ponovila predlog, in potem, ko bi bila odobrena, bi bila zasnova običajno predana inženirski skupini. V tem primeru je inženirska ekipa dejansko »v lasti« funkcionalnosti dostopnosti, ker je bila njihova odgovornost odpraviti vse težave, povezane z njo.

Na začetku je bilo precej težko razložiti, da sta dostopnost in uporabnost neločljivo povezani in da je to treba storiti že v fazi načrtovanja, sicer bi prišlo do velikih sprememb in redefinicij nekaterih vlog. Vendar smo s podporo vodstva in ključnih akterjev idejo prevzeli in jo uresničili, tako da so bili dizajni testirani glede dostopnosti in uporabnosti, preden so bili predstavljeni vodstvu.

In te povratne informacije so bile izjemno dragocene za vse – bilo je fantastično kot vaja pri izmenjavi znanja/komunikaciji o tem, kako uporabniki komunicirajo s spletnimi aplikacijami, identificirali smo številna problematična področja uporabniškega vmesnika, preden so bili zgrajeni, razvojne ekipe imajo zdaj veliko boljše specifikacije ne samo vizualni, pa tudi vedenjski vidiki oblikovanja. Prave razprave so zabavne, energične, strastne razprave o tehničnih vidikih in interakcijah.

To bi lahko storili še bolje, če bi imeli na teh (ali poznejših) srečanjih slepe in invalidne uporabnike – to je bilo težko organizirati, vendar zdaj sodelujemo z lokalnimi organizacijami in podjetji za slepe, ki zagotavljajo zunanje testiranje za zgodnje preverjanje toka izvajanja razvoj—tako na ravni komponente kot izvedbenega toka.

Inženirji imajo zdaj dokaj podrobne specifikacije, razpoložljive komponente, ki jih lahko uporabijo za implementacijo, in način za preverjanje toka izvajanja. Del tega, kar so nas izkušnje naučile, je tisto, kar smo ves čas pogrešali – kako lahko zaustavimo nazadovanje. Podobno lahko ljudje uporabljajo integracijske ali end-to-end teste za testiranje funkcionalnosti, ki jih potrebujemo za odkrivanje sprememb v interakcijah in tokovih izvajanja – tako vizualnih kot vedenjskih.

Ugotavljanje vizualne regresije je dokaj definirana naloga, procesu je mogoče dodati zelo malo, razen morda preverjanja, ali je fokus viden pri krmarjenju s tipkovnico. Bolj zanimivi sta dve relativno novi tehnologiji za delo z dostopnostjo.

  1. Dostopnost Vpogled je nabor orodij, ki jih je mogoče zagnati v brskalniku in kot del cikla izdelave/testiranja za odkrivanje težav.
  2. Preverjanje, ali bralniki zaslona delujejo pravilno, je bila še posebej zahtevna naloga. Z uvedbo dostopa do Dostopnost DOM, smo končno lahko posneli posnetke dostopnosti aplikacije, podobno kot pri vizualnih preizkusih, in jih preizkusili glede regresije.

Tako smo v drugem delu zgodbe z urejanja kode HTML prešli na delo na višji ravni abstrakcije, spremenili proces razvoja dizajna in uvedli temeljito testiranje. Novi procesi, nove tehnologije in nove ravni abstrakcije so popolnoma spremenile krajino dostopnosti in kaj pomeni delati v tem prostoru.
Ampak to je šele začetek.

Naslednje »razumevanje« je, da slepi uporabniki poganjajo vrhunsko tehnologijo – oni so tisti, ki imajo največ koristi ne le od sprememb, ki smo jih opisali prej, ampak tudi, da ML/AI omogoča nove pristope in ideje. Na primer, tehnologija Immersive Reader uporabnikom omogoča lažjo in jasnejšo predstavitev besedila. Lahko se bere na glas, struktura stavkov je slovnično razčlenjena in celo pomeni besed so prikazani grafično. To se nikakor ne ujema s staro miselnostjo "naj bo dostopno" - to je funkcija uporabnosti, ki bo pomagala vsem.

ML/AI omogoča povsem nove načine interakcije in dela in veseli smo, da smo del naslednjih stopenj tega vrhunskega potovanja. Inovacije poganjajo spremembe v razmišljanju – človeštvo obstaja že tisočletja, stroji na stotine let, spletne strani več desetletij, pametni telefoni pa še manj, tehnologija se mora prilagajati ljudem in ne obratno.

PS Članek je preveden z manjšimi odstopanji od izvirnika. Kot soavtor tega članka sem se o teh digresijah strinjal s Hughom.

V anketi lahko sodelujejo samo registrirani uporabniki. Prijaviti se, prosim.

Ste pozorni na dostopnost svojih aplikacij?

  • Da

  • Št

  • Prvič slišim za dostopnost aplikacij.

Glasovalo je 17 uporabnikov. 5 uporabnikov se je vzdržalo.

Vir: www.habr.com

Dodaj komentar