Vendredo estas la fino de la labortago. Malbonaj novaĵoj ĉiam venas ĉe la fino de la labortago vendrede.
Vi estas forironta la oficejon, nova letero pri alia reorganizo ĵus alvenis en la poŝto.
Dankon xxxx, yyy ekde hodiaŭ vi raportos zzzz
...
Kaj la teamo de Hugh certigos, ke niaj produktoj estas alireblaj por homoj kun handikapoj.
Ho ne! Kial mi meritis ĉi tion? Ĉu ili volas, ke mi foriru? Preparu vin por sendanka laborego kaj provi korekti la erarojn de aliaj homoj. Ĉi tio certe estas fiasko...
Ĉi tio estis la havebleco antaŭ kelkaj jaroj. Kelkaj malriĉaj animoj ricevis la taskon "purigi" la UI por provi fari ĝin alirebla por homoj kun handikapoj.
Kion ĉi tio fakte signifis estis sufiĉe malklara - supozeble se vi povus vidi fokusan indikilon kaj klapeton tra kampoj, havi iom da altteksto kaj kelkajn kampopriskribojn, oni konsiderus ke via aplikaĵo estas alirebla...
Sed subite la "cimoj" komencis multobliĝi kun la rapideco de lavango.
Diversaj ekranlegiloj (la angla Ekranlegiloj) kaj retumiloj kondutis tute alie.
Uzantoj plendis, ke la aplikaĵo estas neuzebla.
Tuj kiam eraro estis korektita en unu loko, alia aperis en alia.
Kaj simple ŝanĝi kaj korekti uzantinterfacajn erarojn postulis herkulajn klopodojn.
Mi estis tie. Mi pluvivis, sed ni ne "sukcesis" - teknike ni multe purigis, aldonis multajn kampajn priskribojn, rolojn kaj atingis iun nivelon de plenumado, sed neniu estis feliĉa. Uzantoj ankoraŭ plendis, ke ili ne povas navigi la aplikaĵon. La administranto ankoraŭ plendis pri la konstanta fluo de eraroj. Inĝenieroj plendis ke la problemo estis prezentita neĝuste, kun neniu klare difinita "ĝusta" solvo kiu funkcius en ĉiuj kazoj.
Estis iuj decidinde malfermaj momentoj dum mia vojaĝo al komprenado de alirebleco.
Eble la unua estis la ekkompreno, ke aldoni alireblecon aldone al preta produkto estis malfacila. Kaj estas eĉ pli malfacile konvinki administrantojn, ke ĝi estas nekredeble malfacila! Ne, ĝi ne estas nur "aldonu kelkajn etikedojn" kaj la UI funkcios bone. Ne, ĉi tio ne povas esti finita en tri semajnoj; eĉ tri monatoj ne sufiĉos.
Mia sekva momento de vero venis kiam mi unuamane vidis kiel blindaj uzantoj efektive uzis nian apon. Ĉi tio estas TRE malsama ol rigardi erarmesaĝojn.
Mi revenos al ĉi tio denove kaj denove, sed preskaŭ ĉiuj niaj "supozoj" pri kiel homoj uzis nian apon estis malĝustaj.
Navigante kompleksan uzantinterfacon per klavopremoj Tab/Shift+Tab – ĉi tio fias! Ni bezonas ion pli bonan. Klavaj ŝparvojoj, kaplinioj.
Perdi fokuson dum ŝanĝado de la UI ne estas granda problemo, ĉu ne? Ni pripensu denove - ĉi tio estas nekredeble konfuza.
Mi daŭrigis, laboris pri malsamaj projektoj dum kelka tempo, kaj poste ni komencis novan projekton, kun kompleksa uzantinterfaco kaj klara instalado, por finfine akiri alireblecon ĉi-foje.
Do, ni faris paŝon malantaŭen kaj rigardis kiel ni povus efektivigi ĉi tion alimaniere kaj sukcesi, kaj fari la procezon malpli enuiga!
Sufiĉe rapide ni alvenis al kelkaj konkludoj:
- Ni ne volis, ke homoj evoluantaj la uzantinterfacon fuŝu kun ariaj etikedoj/roloj kaj, kompreneble, la HTML-strukturo de la komponantoj. Ni devis provizi ilin per la ĝustaj komponantoj kiuj konstruis alireblecon tuj el la skatolo.
- Alirebleco == Facileco de uzado - t.e. Ĉi tio ne estas nur teknika defio. Ni devis ŝanĝi la tutan dezajnprocezon kaj certigi, ke alirebleco estas konsiderata kaj diskutita antaŭ ol UI-dezajno komenciĝis. Vi devas frue pensi pri kiel uzantoj malkovros iun ajn funkcion, kiel ili navigos, kaj kiel dekstre klakado funkcios. Alirebleco devus esti integra parto de la dezajnprocezo - por iuj uzantoj ĝi estas multe pli ol nur la aspekto de la aplikaĵo.
- De la komenco, ni volis ricevi komentojn de blindaj kaj aliaj handikapitaj uzantoj pri la facileco de uzado de la aplikaĵo.
- Ni bezonis vere bonajn manierojn kapti alireblajn regresojn.
Nu, el inĝenieristiko vidpunkto, la unua parto sonis sufiĉe amuza - disvolvi arkitekturon kaj efektivigi bibliotekon de komponantoj. Kaj efektive estis tiel.
Farante paŝon malantaŭen, rigardante kaj pensante pri tio kiel dezajnproblemon prefere ol "kongrua" problemo, ni enkondukis kelkajn abstraktaĵojn. Komponanto havas 'Strukton' (konsistas el HTML-elementoj) kaj 'Konduton' (kiel ĝi interagas kun la uzanto). Ekzemple, en la subaj fragmentoj ni havas simplan neordigitan liston. Aldonante "kondutojn" la respondaj roloj estas aldonitaj al la listo por ke ĝi agu kiel listo. Ni faras la samon por la menuo.
Fakte, ne nur roloj estas aldonitaj ĉi tie, sed ankaŭ evento-traktiloj por klavarnavigado.
Ĉi tio aspektas pli bonorda. Se ni povus akiri puran apartigon inter ili, ne gravas kiel la strukturo estis kreita, ni povus apliki Kondutojn al ĝi kaj akiri la alireblecon ĝuste.
Vi povas vidi ĉi tion en ago ĉe - UX-biblioteko , kiu estas desegnita kaj efektivigita kun alirebleco en menso de la komenco.
La dua parto - ŝanĝi la aliron kaj procezojn ĉirkaŭ dezajno komence timigis min: humilaj inĝenieroj klopodantaj antaŭenpuŝi organizan ŝanĝon ne ĉiam finiĝas bone, sed ĝi rezultis esti unu el la plej interesaj areoj kie ni faris signifajn kontribuojn al la procezo. . Resume, nia procezo estis jena: nova funkcieco estus evoluigita fare de unu teamo, tiam nia gvida teamo revizius/ripetus la proponon, kaj tiam, post kiam aprobite, la dezajno estus tipe transdonita al la inĝenieristikteamo. En ĉi tiu kazo, la inĝenieristikteamo efike "posedis" la alireblecon ĉar estis ilia respondeco ripari iujn ajn problemojn asociitajn kun ĝi.
En la komenco, estis sufiĉe malfacila laboro klarigi, ke alirebleco kaj uzebleco estas nedisigeble ligitaj kaj ke tio devis esti farita en la dezajnstadio, alie ĝi kondukus al grandaj ŝanĝoj kaj redifinoj de iuj roloj. Tamen, kun la subteno de administrado kaj ŝlosilaj ludantoj, ni prenis la ideon kaj metis ĝin en moviĝon por ke dezajnoj estis testitaj pri alirebleco kaj uzebleco antaŭ ol ili estis prezentitaj al administrado.
Kaj ĉi tiu sugesto estis ege valora por ĉiuj - ĝi estis mirinda kiel ekzerco en konigo/komunikado pri kiel uzantoj interagas kun TTT-aplikoj, ni identigis multajn UI-problemajn areojn antaŭ ol ili estis konstruitaj, la evoluteamoj nun havas multe pli bonajn specifojn pri ne. nur vidaj, sed ankaŭ kondutismaj aspektoj de dezajno. Veraj diskutoj estas amuzaj, energiaj, pasiaj diskutoj pri teknikaj aspektoj kaj interagoj.
Ni povus fari tion eĉ pli bone se ni havus blindulojn kaj handikapitajn uzantojn ĉe ĉi tiuj (aŭ postaj) renkontiĝoj - tio estis malfacile organizebla, sed ni nun laboras kun kaj lokaj blindulorganizoj kaj kompanioj , kiuj disponigas eksterajn testadojn por kontroli ekzekutfluon frue en la komenco. evoluo - kaj ĉe la komponento kaj ekzekutfluoniveloj.
Inĝenieroj nun havas sufiĉe detalajn specifojn, disponeblajn komponentojn, kiujn ili povas uzi por efektivigi, kaj manieron validigi la ekzekutfluon. Parto de tio, kion la sperto instruis al ni, estas tio, kion ni mankis dum la tuta tempo—kiel ni povas ĉesigi la regreson. Same, homoj povas uzi integriĝon aŭ fin-al-finajn testojn por testi funkciecon, kiujn ni bezonas por detekti ŝanĝojn en interagoj kaj ekzekutfluoj - kaj vidaj kaj kondutismaj.
Determini vidan regreson estas sufiĉe difinita tasko, estas tre malmulte da kiu povas esti aldonita al la procezo krom eble kontroli ĉu fokuso estas videbla dum navigado per la klavaro. Pli interesaj estas du relative novaj teknologioj por labori kun alirebleco.
- estas aro de iloj, kiuj povas esti rulitaj kaj en la retumilo kaj kiel parto de la konstruo/prova ciklo por identigi problemojn.
- Kontroli ke ekranlegiloj funkcias ĝuste estis aparte defia tasko. Kun la enkonduko de aliro al Alirebleco DOM, ni finfine povas preni alireblajn momentfotojn de la programo, same kiel ni faras por vidaj testoj, kaj testi ilin por regreso.
Do, en la dua parto de la rakonto, ni transiris de redaktado de HTML-kodo al laborado je pli alta nivelo de abstraktado, ŝanĝis la projektan disvolvan procezon kaj enkondukis ĝisfundajn testadojn. Novaj procezoj, novaj teknologioj kaj novaj niveloj de abstraktado tute ŝanĝis la pejzaĝon de alirebleco kaj kion signifas labori en ĉi tiu spaco.
Sed ĉi tio estas nur la komenco.
La sekva "kompreno" estas, ke blindaj uzantoj stiras avangardan teknologion - ili estas tiuj, kiuj plej profitas ne nur de la ŝanĝoj, kiujn ni priskribis antaŭe, sed ankaŭ, ke novaj aliroj kaj ideoj estas ebligitaj de ML/AI. Ekzemple, Immersive Reader-teknologio permesas al uzantoj prezenti tekston pli facile kaj klare. Ĝi estas laŭtlegita, frazstrukturo estas malkonstruita gramatike, kaj eĉ vortsignifoj estas montritaj grafike. Ĉi tio tute ne konvenas al la malnova pensmaniero "igi ĝin alirebla" - ĝi estas uzebleco, kiu helpos ĉiujn.
ML/AI ebligas tute novajn manierojn interagi kaj labori, kaj ni ĝojas esti parto de la sekvaj etapoj de ĉi tiu avangarda vojaĝo. Novigado estas pelata de ŝanĝo de pensado - homaro ekzistas de jarmiloj, maŝinoj dum centoj da jaroj, retejoj dum pluraj jardekoj, kaj saĝtelefonoj eĉ malpli, teknologio devas adaptiĝi al homoj, kaj ne inverse.
P.S. La artikolo estis tradukita kun etaj devioj de la originalo. Kiel kunaŭtoro de ĉi tiu artikolo, mi konsentis pri ĉi tiuj digresoj kun Hugh.
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Ĉu vi atentas la alireblecon de viaj aplikaĵoj?
-
Jes
-
Neniu
-
Ĉi tio estas la unua fojo, ke mi aŭdas pri alirebleco de aplikaĵoj.
17 uzantoj voĉdonis. 5 uzantoj sindetenis.
fonto: www.habr.com