Perjantai on työpäivän päätös. Huonot uutiset tulevat aina perjantain työpäivän päätteeksi.
Olet lähdössä toimistosta, postissa on juuri saapunut uusi kirje toisesta uudelleenjärjestelystä.
Kiitos xxxx, yyy tästä päivästä lähtien ilmoitat zzzz
...
Ja Hughin tiimi varmistaa, että tuotteemme ovat vammaisten saatavilla.
Voi ei! Miksi ansaitsin tämän? Haluavatko he minun lähtevän? Valmistaudu kiittämättömään kovaan työhön ja yrittämiseen korjata muiden ihmisten virheitä. Tämä on ehdottomasti epäonnistuminen...
Tämä oli saatavuus muutama vuosi sitten. Joillekin köyhille sieluille annettiin tehtäväksi "siivota" käyttöliittymä yrittääkseen tehdä siitä vammaisten käytettävissä.
Mitä tämä itse asiassa tarkoitti, oli melko epämääräistä - oletettavasti, jos näkisit tarkennuksen ilmaisimen ja välilehden kenttien läpi, sinulla olisi vaihtoehtoinen teksti ja pari kenttäkuvausta, katsottaisiin, että sovelluksesi on käytettävissä...
Mutta yhtäkkiä "virheet" alkoivat lisääntyä lumivyöryn nopeudella.
Erilaisia näytönlukuohjelmia (Eng. Näytönlukijat) ja selaimet toimivat täysin eri tavalla.
Käyttäjät ovat valittaneet, että sovellus on käyttökelvoton.
Heti kun virhe korjattiin yhdessä paikassa, toinen ilmestyi toiseen.
Ja pelkkä käyttöliittymävirheiden muuttaminen ja korjaaminen vaati Herkuleen ponnisteluja.
Olin siellä. Selvisin, mutta emme "onnistuneet" - teknisesti siivosimme paljon, lisäsimme paljon kenttäkuvauksia, rooleja ja saavutimme jonkin verran vaatimustenmukaisuutta, mutta kukaan ei ollut tyytyväinen. Käyttäjät valittivat edelleen, etteivät he pystyneet navigoimaan sovelluksessa. Johtaja valitti edelleen jatkuvasta virhevirrasta. Insinöörit valittivat, että ongelma oli asetettu väärin, eikä siinä ollut selkeästi määriteltyä "oikeaa" ratkaisua, joka toimisi kaikissa tapauksissa.
Matkallani saavutettavuuden ymmärtämiseen oli joitain selvästi silmiä avaavia hetkiä.
Ehkä ensimmäinen oli ymmärrys siitä, että esteettömyystoimintojen lisääminen valmiin tuotteen päälle oli vaikeaa. Ja vielä vaikeampaa on saada johtajat vakuuttuneiksi siitä, että se on uskomattoman vaikeaa! Ei, se ei ole vain "lisää muutama tunniste" ja käyttöliittymä toimii hienosti. Ei, tätä ei voida saada päätökseen kolmessa viikossa; edes kolme kuukautta ei riitä.
Seuraava totuuden hetki tuli, kun näin omakohtaisesti, kuinka sokeat käyttäjät todella käyttivät sovellustasi. Tämä on TOSI erilaista kuin virheilmoitusten katsominen.
Palaan tähän uudestaan ja uudestaan, mutta melkein kaikki "oletuksemme" siitä, kuinka ihmiset käyttivät sovellustamme, olivat vääriä.
Navigointi monimutkaisessa käyttöliittymässä näppäinpainalluksella Tab/Shift+Tab – tämä on perseestä! Tarvitsemme jotain parempaa. Pikanäppäimet, otsikot.
Tarkennuksen menettäminen käyttöliittymää vaihdettaessa ei ole suuri ongelma, vai mitä? Mietitäänpä uudestaan – tämä on uskomattoman hämmentävää.
Jatkoin, työskentelin jonkin aikaa eri projekteissa, ja sitten aloitimme uuden projektin, jossa oli monimutkainen käyttöliittymä ja selkeä asennus, jotta saavutettaisiin vihdoin tällä kertaa oikein.
Joten otimme askeleen taaksepäin ja pohdimme, kuinka voisimme toteuttaa tämän toisin ja onnistua ja tehdä prosessista vähemmän tylsä!
Melko nopeasti teimme joitain johtopäätöksiä:
- Emme halunneet, että käyttöliittymää kehittävät ihmiset sotkevat aria-tunnisteita/rooleja ja tietysti komponenttien HTML-rakennetta. Meidän täytyi tarjota heille oikeat komponentit, jotka loivat esteettömyyden heti käyttöön.
- Helppokäyttöisyys == Helppokäyttöisyys – ts. Tämä ei ole vain tekninen haaste. Meidän piti muuttaa koko suunnitteluprosessia ja varmistaa, että saavutettavuus otettiin huomioon ja siitä keskusteltiin ennen käyttöliittymäsuunnittelun aloittamista. Sinun on mietittävä varhain, kuinka käyttäjät löytävät toiminnot, kuinka he liikkuvat ja kuinka hiiren oikealla painikkeella napsauttaminen näppäimistöstä toimii. Helppokäyttöisyyden pitäisi olla olennainen osa suunnitteluprosessia - joillekin käyttäjille se on paljon enemmän kuin vain sovelluksen ulkonäkö.
- Alusta alkaen halusimme saada sokeilta ja muilta vammaisilta palautetta sovelluksen helppokäyttöisyydestä.
- Tarvitsimme todella hyviä tapoja saavuttaa esteettömyysregressioita.
No, insinöörin näkökulmasta ensimmäinen osa kuulosti varsin hauskalta - arkkitehtuurin kehittäminen ja komponenttikirjaston toteuttaminen. Ja niin tosiaan oli.
Otetaan askel taaksepäin, katsotaan ja pitämällä tätä suunnitteluongelmana pikemminkin kuin "sovitusongelmana", otimme käyttöön joitain abstraktioita. Komponentilla on "rakenne" (koostuu HTML-elementeistä) ja "käyttäytyminen" (miten se on vuorovaikutuksessa käyttäjän kanssa). Esimerkiksi alla olevissa katkelmissa meillä on yksinkertainen järjestämätön luettelo. Lisäämällä "käyttäytymistä" vastaavat roolit lisätään luetteloon, jotta se toimisi luettelona. Teemme samoin valikon kanssa.
Itse asiassa tähän ei lisätä vain rooleja, vaan myös tapahtumakäsittelijöitä näppäimistön navigointia varten.
Tämä näyttää siistimmältä. Jos saisimme puhtaan eron niiden välille, ei sillä olisi väliä, miten rakenne on luotu, voisimme soveltaa siihen käyttäytymismalleja ja saada esteettömyyden oikein.
Voit nähdä tämän toiminnassa osoitteessa – UX-kirjasto , joka on suunniteltu ja toteutettu esteettömyyttä ajatellen alusta alkaen.
Toinen osa - suunnittelun lähestymistavan ja prosessien muuttaminen pelotti minua aluksi: matalat insinöörit, jotka yrittävät ajaa läpi organisaatiomuutosta, eivät aina pääty hyvin, mutta se osoittautui yhdeksi mielenkiintoisimmista alueista, joilla annoimme merkittävän panoksen prosessiin. . Lyhyesti sanottuna prosessimme oli seuraava: uudet toiminnallisuudet kehitettiin yhden tiimin toimesta, sitten johtoryhmämme tarkasteli/iteroi ehdotuksen ja hyväksymisen jälkeen suunnittelu luovutettiin yleensä suunnittelutiimille. Tässä tapauksessa suunnittelutiimi "omisti" esteettömyystoiminnon, koska heidän vastuullaan oli korjata kaikki siihen liittyvät ongelmat.
Alussa oli melko vaikeaa selittää, että saavutettavuus ja käytettävyys liittyvät erottamattomasti toisiinsa ja että tämä oli tehtävä suunnitteluvaiheessa, muuten se johtaisi suuriin muutoksiin ja joidenkin roolien uudelleenmäärittelyihin. Kuitenkin johdon ja avaintoimijoiden tuella otimme idean käyttöön ja toteutimme sen niin, että suunnitelmien saavutettavuus ja käytettävyys testattiin ennen kuin ne esitettiin johdolle.
Ja tämä palaute oli erittäin arvokasta kaikille - se oli loistava harjoitus tiedon jakamiseen/viestintään siitä, miten käyttäjät ovat vuorovaikutuksessa verkkosovellusten kanssa, tunnistimme lukuisia käyttöliittymän ongelmakohtia ennen niiden rakentamista. Kehitystiimeillä on nyt paljon parempia teknisiä tietoja. vain visuaaliset, mutta myös käyttäytymiseen liittyvät näkökohdat suunnittelussa. Todelliset keskustelut ovat hauskoja, energisiä, intohimoisia keskusteluja teknisistä näkökohdista ja vuorovaikutuksista.
Voisimme tehdä tämän vielä paremmin, jos meillä olisi sokeita ja vammaisia käyttäjiä näissä (tai myöhemmissä) kokouksissa – tätä oli vaikea järjestää, mutta teemme nyt yhteistyötä sekä paikallisten sokeiden organisaatioiden että yritysten kanssa , jotka tarjoavat ulkopuolista testausta varmistaakseen suoritusvirran varhaisessa vaiheessa. kehitys – sekä komponentti- että suoritusvirran tasolla.
Insinööreillä on nyt melko yksityiskohtaiset tekniset tiedot, käytettävissä olevat komponentit, joita he voivat käyttää toteuttamiseen, ja tapa validoida suoritusvirta. Osa siitä, mitä kokemus on opettanut meille, on se, mitä meiltä on puuttunut koko ajan – kuinka voimme pysäyttää regression. Samoin ihmiset voivat käyttää integraatiota tai päästä päähän -testejä toiminnallisuuden testaamiseen, joita tarvitsemme havaitaksemme muutokset vuorovaikutuksessa ja suoritusvirroissa – sekä visuaalisissa että käyttäytymisissä.
Visuaalisen regression määrittäminen on melko määritelty tehtävä, prosessiin ei voi juurikaan lisätä muuta kuin ehkä tarkistaa, näkyykö tarkennus näppäimistöllä navigoitaessa. Mielenkiintoisempaa on kaksi suhteellisen uutta esteettömyystekniikkaa.
- on joukko työkaluja, joita voidaan käyttää sekä selaimessa että osana rakennus-/testisykliä ongelmien tunnistamiseksi.
- Näytönlukuohjelmien oikean toiminnan varmistaminen on ollut erityisen haastava tehtävä. Käyttöönoton myötä Esteettömyys DOM, voimme vihdoin ottaa esteettömyyskuvia sovelluksesta, aivan kuten teemme visuaalisissa testeissä, ja testata niitä regression suhteen.
Joten tarinan toisessa osassa siirryimme HTML-koodin muokkaamisesta korkeampaan abstraktiotasoon, muutimme suunnittelun kehitysprosessia ja otettiin käyttöön perusteellinen testaus. Uudet prosessit, uudet teknologiat ja uudet abstraktion tasot ovat muuttaneet esteettömyyden maisemaa ja sen, mitä tässä tilassa työskentely tarkoittaa.
Mutta tämä on vasta alkua.
Seuraava "ymmärrys" on, että sokeat käyttäjät ajavat huipputeknologiaa – he ovat niitä, jotka hyötyvät eniten aiemmin kuvailemistamme muutoksista, mutta myös siitä, että ML/AI mahdollistaa uusia lähestymistapoja ja ideoita. Esimerkiksi Immersive Reader -tekniikan avulla käyttäjät voivat esittää tekstiä helpommin ja selkeämmin. Se voidaan lukea ääneen, lauserakenne puretaan kieliopillisesti ja jopa sanojen merkitykset näytetään graafisesti. Tämä ei sovi ollenkaan vanhaan "tehdä siitä saataville" -mentaliteettiin - se on käytettävyysominaisuus, joka auttaa kaikkia.
ML/AI mahdollistaa täysin uusia tapoja vuorovaikutukseen ja työskentelyyn, ja olemme innoissamme voidessamme olla mukana tämän huippuluokan matkan seuraavissa vaiheissa. Innovaatiota ohjaa ajattelun muutos - ihmiskunta on ollut olemassa tuhansia vuosia, koneet satoja vuosia, nettisivut useita vuosikymmeniä ja älypuhelimet vielä vähemmän, teknologian on mukauduttava ihmisiin, eikä päinvastoin.
P.S. Artikkeli on käännetty pienin poikkeavin alkuperäisestä. Tämän artikkelin kirjoittajana olin samaa mieltä näistä poikkeamista Hughin kanssa.
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Kiinnitätkö huomiota sovelluksiesi saavutettavuuteen?
-
Kyllä
-
Ei
-
Tämä on ensimmäinen kerta, kun kuulen sovellusten esteettömyydestä.
17 käyttäjää äänesti. 5 käyttäjää pidättyi äänestämästä.
Lähde: will.com