Penktadienis yra darbo dienos pabaiga. Blogos žinios visada ateina penktadienio darbo dienos pabaigoje.
Jūs ruošiatės išeiti iš biuro, paštu ką tik atkeliavo naujas laiškas apie kitą reorganizaciją.
Ačiū xxxx, yyy nuo šiandien pranešite zzzz
...
Hugh komanda užtikrins, kad mūsų produktai būtų prieinami žmonėms su negalia.
O ne! Kodėl aš to nusipelniau? Ar jie nori, kad išeičiau? Pasiruoškite nedėkingam sunkiam darbui ir bandymui ištaisyti kitų žmonių klaidas. Tai tikrai nesėkmė...
Tai buvo prieinamumas prieš keletą metų. Kai kurioms neturtingoms sieloms buvo pavesta „išvalyti“ vartotojo sąsają, kad ji būtų prieinama žmonėms su negalia.
Ką tai iš tikrųjų reiškė, buvo gana neaiški – tikriausiai, jei laukuose matytumėte židinio indikatorių ir skirtuką, būtų šiek tiek alternatyvaus teksto ir porą laukų aprašymų, būtų laikoma, kad jūsų programa yra pasiekiama...
Tačiau staiga „klaidos“ pradėjo daugintis lavinos greičiu.
Įvairūs ekrano skaitytuvai (Anglų Ekrano skaitytuvai) ir naršyklės veikė visiškai skirtingai.
Vartotojai skundėsi, kad programa yra netinkama naudoti.
Kai tik vienoje vietoje buvo ištaisyta klaida, kitoje atsirado kita.
O tiesiog pakeisti ir ištaisyti vartotojo sąsajos klaidas prireikė Heraklio pastangų.
Aš ten buvau. Išgyvenau, bet „nepavyko“ – techniškai daug išvalėme, pridėjome daug lauko aprašymų, vaidmenų, pasiekėme tam tikrą atitikties lygį, bet niekas nebuvo patenkintas. Vartotojai vis dar skundėsi, kad negali naršyti programoje. Vadovas vis dar skundėsi nuolatiniu klaidų srautu. Inžinieriai skundėsi, kad problema buvo iškelta neteisingai, nesant aiškiai apibrėžto „teisingo“ sprendimo, kuris veiktų visais atvejais.
Mano kelionėje į prieinamumo supratimą buvo keletas akimirkų neabejotinai atveriančių akis.
Galbūt pirmasis buvo supratimas, kad pridėti prieinamumo funkciją prie galutinio produkto buvo sunku. Ir dar sunkiau įtikinti vadovus, kad tai nepaprastai sunku! Ne, tai ne tik „pridėkite kelias žymas“, o vartotojo sąsaja veiks puikiai. Ne, tai negali būti atlikta per tris savaites, nepakaks net trijų mėnesių.
Kitas mano tiesos momentas atėjo, kai iš pirmų lūpų pamačiau, kaip akli vartotojai iš tikrųjų naudojasi mūsų programa. Tai labai skiriasi nuo klaidų pranešimų žiūrėjimo.
Prie to grįšiu vėl ir vėl, bet beveik visos mūsų „prielaidos“ apie tai, kaip žmonės naudojosi mūsų programėle, buvo klaidingos.
Naršymas sudėtingoje vartotojo sąsajoje naudojant klavišų paspaudimus Tab/Shift+Tab - tai bjauru! Mums reikia kažko geresnio. Spartieji klavišai, antraštės.
Fokuso praradimas keičiant vartotojo sąsają nėra didelė problema, ar ne? Pagalvokime dar kartą – tai neįtikėtinai painu.
Aš tęsiau, kurį laiką dirbau su įvairiais projektais, o tada pradėjome naują projektą su sudėtinga vartotojo sąsaja ir aiškiu diegimu, kad pagaliau šį kartą būtų prieinama.
Taigi, žengėme žingsnį atgal ir pažiūrėjome, kaip galėtume tai įgyvendinti kitaip, kad pavyktų, o procesas būtų ne toks nuobodus!
Gana greitai padarėme keletą išvadų:
- Nenorėjome, kad žmonės, kuriantys vartotojo sąsają, maišytųsi su aria etiketėmis / vaidmenimis ir, žinoma, komponentų HTML struktūra. Mums reikėjo suteikti jiems tinkamus komponentus, kurie sukurtų prieinamumą iš karto.
- Prieinamumas == Naudojimo paprastumas – t.y. Tai ne tik techninis iššūkis. Mums reikėjo pakeisti visą projektavimo procesą ir užtikrinti, kad prieš pradedant kurti vartotojo sąsają būtų atsižvelgta ir aptartas prieinamumas. Turite iš anksto pagalvoti, kaip vartotojai atras bet kokias funkcijas, kaip jie naršys ir kaip veiks klaviatūros dešiniuoju pelės klavišu spustelėjimas. Prieinamumas turėtų būti neatsiejama projektavimo proceso dalis – kai kuriems vartotojams tai yra daug daugiau nei tik programos išvaizda.
- Nuo pat pradžių norėjome sulaukti aklųjų ir kitų neįgalių vartotojų atsiliepimų apie programos naudojimo paprastumą.
- Mums reikėjo tikrai gerų būdų, kaip užfiksuoti prieinamumo regresijas.
Na, o iš inžinerinės pusės, pirma dalis skambėjo visai smagiai – kuriant architektūrą ir diegiant komponentų biblioteką. Ir tikrai taip buvo.
Žengdamas žingsnį atgal, žiūri ir galvodami apie tai kaip apie dizaino problemą, o ne į „pritaikymo“ problemą, pristatėme kai kurias abstrakcijas. Komponentas turi „Struktūrą“ (susideda iš HTML elementų) ir „Elgseną“ (kaip jis sąveikauja su vartotoju). Pavyzdžiui, toliau pateiktuose fragmentuose turime paprastą netvarkingą sąrašą. Pridėjus „elgesį“, atitinkami vaidmenys įtraukiami į sąrašą, kad jis veiktų kaip sąrašas. Tą patį darome ir su meniu.
Tiesą sakant, čia pridedami ne tik vaidmenys, bet ir klaviatūros naršymo įvykių tvarkyklės.
Tai atrodo tvarkingiau. Jei galėtume juos aiškiai atskirti, nesvarbu, kaip struktūra buvo sukurta, galėtume jai pritaikyti elgseną ir pritaikyti tinkamą pasiekiamumą.
Tai galite pamatyti veikiant adresu – UX biblioteka , kuri sukurta ir įgyvendinta nuo pat pradžių atsižvelgiant į prieinamumą.
Antroji dalis – požiūrio ir procesų, susijusių su dizainu, keitimas iš pradžių mane išgąsdino: žemi inžinieriai, bandantys prastumti organizacinius pokyčius, ne visada baigiasi gerai, tačiau tai pasirodė viena įdomiausių sričių, kurioje mes svariai prisidėjome prie šio proceso. . Trumpai tariant, mūsų procesas buvo toks: naujas funkcijas sukurtų viena komanda, tada mūsų vadovų komanda peržiūrėtų / kartotų pasiūlymą, o tada, kai jis bus patvirtintas, dizainas paprastai būtų perduotas inžinierių komandai. Šiuo atveju inžinierių komanda iš tikrųjų „priklausė“ pritaikymo neįgaliesiems funkcijai, nes jos pareiga buvo išspręsti visas su ja susijusias problemas.
Pradžioje buvo gana sunkus darbas paaiškinti, kad prieinamumas ir patogumas yra neatsiejamai susiję ir kad tai turėjo būti daroma projektavimo stadijoje, kitaip tai lemtų didelius pokyčius ir kai kurių vaidmenų apibrėžimus. Tačiau, padedami vadovybės ir pagrindinių veikėjų, ėmėmės idėjos ir ją įgyvendinome, kad prieš pristatant vadovybei dizainas būtų išbandytas dėl prieinamumo ir tinkamumo naudoti.
Ir šis atsiliepimas buvo labai vertingas visiems – tai buvo fantastiška kaip dalijimosi žiniomis/bendravimo apie tai, kaip vartotojai sąveikauja su žiniatinklio programomis, pratimas, mes nustatėme daugybę UI probleminių sričių prieš jas sukūrę, o kūrėjų komandos dabar turi daug geresnes specifikacijas. tik vizualiniai, bet ir elgsenos dizaino aspektai. Tikros diskusijos – tai linksmos, energingos, aistringos diskusijos apie techninius aspektus ir sąveiką.
Galėtume tai padaryti dar geriau, jei šiuose (ar vėlesniuose) susitikimuose turėtume aklų ir neįgalių naudotojų – tai buvo sunku organizuoti, bet dabar dirbame ir su vietinėmis aklųjų organizacijomis, ir su įmonėmis , kurios teikia išorinius bandymus, kad patikrintų vykdymo eigą anksti. plėtra – tiek komponento, tiek vykdymo srauto lygiu.
Dabar inžinieriai turi gana išsamias specifikacijas, galimus komponentus, kuriuos jie gali naudoti įgyvendindami, ir būdą, kaip patvirtinti vykdymo srautą. Dalis to, ko mus išmokė patirtis, yra tai, ko mums visą laiką trūko – kaip galime sustabdyti regresiją. Taip pat žmonės gali naudoti integraciją arba galutinius testus, kad patikrintų funkcionalumą, kurio mums reikia norint aptikti sąveikos ir vykdymo srautų pokyčius – tiek vaizdinius, tiek elgsenos.
Vizualinės regresijos nustatymas yra gana apibrėžta užduotis, prie proceso galima pridėti labai mažai ką, išskyrus galbūt patikrinimą, ar fokusas matomas naršant klaviatūra. Įdomesnės yra dvi palyginti naujos technologijos, skirtos dirbti su prieinamumu.
- yra įrankių rinkinys, kurį galima paleisti ir naršyklėje, ir kaip kūrimo/bandymo ciklo dalį problemoms nustatyti.
- Patvirtinti, kad ekrano skaitytuvai veikia tinkamai, buvo ypač sudėtinga užduotis. Įvedus prieigą prie Prieinamumas DOM, pagaliau galime padaryti programos pritaikymo neįgaliesiems momentines nuotraukas, panašiai kaip darome atliekant vizualinius testus, ir patikrinti juos regresijai.
Taigi antroje istorijos dalyje nuo HTML kodo redagavimo perėjome prie darbo aukštesniu abstrakcijos lygiu, pakeitėme dizaino kūrimo procesą ir įvedėme išsamų testavimą. Nauji procesai, naujos technologijos ir nauji abstrakcijos lygiai visiškai pakeitė prieinamumo kraštovaizdį ir tai, ką reiškia dirbti šioje erdvėje.
Bet tai tik pradžia.
Kitas „supratimas“ yra tas, kad aklieji vartotojai naudojasi pažangiausiomis technologijomis – jie yra tie, kurie gauna didžiausią naudą ne tik iš anksčiau aprašytų pokyčių, bet ir iš to, kad ML/AI įgalina naujus požiūrius ir idėjas. Pavyzdžiui, Immersive Reader technologija leidžia vartotojams lengviau ir aiškiau pateikti tekstą. Jį galima perskaityti garsiai, gramatiškai suskaidoma sakinio struktūra, net žodžių reikšmės atvaizduojamos grafiškai. Tai visiškai netelpa į senąjį „padaryti jį prieinamą“ mentalitetą – tai patogumo funkcija, kuri padės kiekvienam.
ML/AI įgalina visiškai naujus bendravimo ir darbo būdus, todėl džiaugiamės galėdami dalyvauti kituose šios pažangiausios kelionės etapuose. Inovacijas skatina mąstymo pasikeitimas – žmonija egzistuoja tūkstantmečius, mašinos – šimtus metų, svetainės – kelis dešimtmečius, o išmanieji telefonai dar mažiau, technologijos turi prisitaikyti prie žmonių, o ne atvirkščiai.
PS Straipsnis išverstas su nedideliais nukrypimais nuo originalo. Kaip šio straipsnio bendraautorius, aš sutariau su Hugh dėl šių nukrypimų.
Apklausoje gali dalyvauti tik registruoti vartotojai. , Prašau.
Ar atkreipiate dėmesį į savo programų prieinamumą?
-
Taip
-
Ne
-
Tai pirmas kartas, kai girdžiu apie programų pritaikymą neįgaliesiems.
Balsavo 17 vartotojų. 5 vartotojai susilaikė.
Šaltinis: www.habr.com