Fredag er det slutt på arbeidsdagen. Dårlige nyheter kommer alltid på slutten av arbeidsdagen på fredag.
Du er i ferd med å forlate kontoret, et nytt brev om en annen omorganisering har nettopp kommet i posten.
Takk xxxx, ååå fra i dag vil du rapportere zzzz
...
Og Hughs team vil sørge for at produktene våre er tilgjengelige for funksjonshemmede.
Å nei! Hvorfor fortjente jeg dette? Vil de at jeg skal dra? Sett deg opp for utakknemlig hardt arbeid og forsøk på å rette opp andres feil. Dette er definitivt en fiasko...
Dette var tilgjengeligheten for noen år siden. Noen stakkars sjeler fikk jobben med å "rydde opp" brukergrensesnittet for å prøve å gjøre det tilgjengelig for funksjonshemmede.
Hva dette faktisk betydde var ganske vagt - antagelig hvis du kunne se en fokusindikator og ta gjennom felt, ha litt alt-tekst og et par feltbeskrivelser, ville det anses som at søknaden din er tilgjengelig ...
Men plutselig begynte "feilene" å formere seg med hastigheten til et snøskred.
Ulike skjermlesere (Eng. Skjermlesere) og nettlesere oppførte seg helt annerledes.
Brukere har klaget over at appen er ubrukelig.
Så snart en feil ble rettet på ett sted, dukket det opp en annen på et annet.
Og ganske enkelt å endre og korrigere brukergrensesnittfeil krevde Herculean-innsats.
Jeg var der. Jeg overlevde, men vi «lykkes» ikke – teknisk sett ryddet vi mye opp, la til mange feltbeskrivelser, roller og oppnådde et visst nivå av etterlevelse, men ingen var fornøyd. Brukere klaget fortsatt over at de ikke kunne navigere i applikasjonen. Lederen klaget fortsatt over den konstante strømmen av feil. Ingeniører klaget over at problemet ble stilt feil, uten noen klart definert "riktig" løsning som ville fungere i alle tilfeller.
Det var noen desidert øyeåpnende øyeblikk på min reise for å forstå tilgjengelighet.
Den første var kanskje erkjennelsen av at det var vanskelig å legge til tilgjengelighetsfunksjonalitet på toppen av et ferdig produkt. Og det er enda vanskeligere å overbevise ledere om at det er utrolig vanskelig! Nei, det er ikke bare "legg til noen få tagger", og brukergrensesnittet vil fungere helt fint. Nei, dette kan ikke gjennomføres på tre uker, selv tre måneder vil ikke være nok.
Mitt neste sannhetsøyeblikk kom da jeg så førstehånds hvordan blinde brukere faktisk brukte appen vår. Dette er SÅ annerledes enn å se på feilmeldinger.
Jeg kommer tilbake til dette igjen og igjen, men nesten alle våre "antakelser" om hvordan folk brukte appen vår var feil.
Navigere i et komplekst brukergrensesnitt ved hjelp av tastetrykk Tab/Shift+Tab – dette suger! Vi trenger noe bedre. Tastatursnarveier, overskrifter.
Å miste fokus når du endrer brukergrensesnittet er vel ikke noe stort problem? La oss tenke om igjen - dette er utrolig forvirrende.
Jeg fortsatte, jobbet med forskjellige prosjekter en stund, og så startet vi et nytt prosjekt, med et komplekst brukergrensesnitt og en oversiktlig installasjon, for endelig å få riktig tilgjengelighet denne gangen.
Så vi tok et skritt tilbake og så på hvordan vi kunne implementere dette annerledes og lykkes, og gjøre prosessen mindre kjedelig!
Ganske raskt kom vi til noen konklusjoner:
- Vi ønsket ikke at folk som utvikler brukergrensesnittet skulle rote med aria-etiketter/roller og, selvfølgelig, HTML-strukturen til komponentene. Vi trengte å gi dem de riktige komponentene som bygde tilgjengelighet rett ut av esken.
- Tilgjengelighet == Brukervennlighet – dvs. Dette er ikke bare en teknisk utfordring. Vi måtte endre hele designprosessen og sørge for at tilgjengelighet ble tatt i betraktning og diskutert før UI-design begynte. Du må tenke tidlig på hvordan brukere vil oppdage hvilken som helst funksjonalitet, hvordan de vil navigere og hvordan høyreklikk fra tastaturet vil fungere. Tilgjengelighet bør være en integrert del av designprosessen – for noen brukere er det mye mer enn bare utseendet til applikasjonen.
- Helt fra starten ønsket vi å få tilbakemeldinger fra blinde og andre funksjonshemmede brukere om brukervennligheten til applikasjonen.
- Vi trengte virkelig gode måter å fange tilgjengelighetsregresjoner på.
Vel, fra et teknisk synspunkt hørtes den første delen ganske morsom ut - å utvikle en arkitektur og implementere et bibliotek med komponenter. Og det var faktisk slik.
Tar et skritt tilbake, ser og ved å tenke på dette som et designproblem i stedet for et "tilpassningsproblem", introduserte vi noen abstraksjoner. En komponent har en 'Struktur' (består av HTML-elementer) og en 'Behaviour' (hvordan den samhandler med brukeren). For eksempel, i utdragene nedenfor har vi en enkel uordnet liste. Ved å legge til "atferd" blir de tilsvarende rollene lagt til listen for å få den til å fungere som en liste. Vi gjør det samme for menyen.
Faktisk er ikke bare roller lagt til her, men også hendelsesbehandlere for tastaturnavigering.
Dette ser mer ryddig ut. Hvis vi kunne få et rent skille mellom dem, ville det ikke spille noen rolle hvordan strukturen ble skapt, vi kunne bruke Behaviours på den og få riktig tilgjengelighet.
Du kan se dette i aksjon på – UX-bibliotek , som er designet og implementert med tanke på tilgjengelighet fra starten.
Den andre delen - endring av tilnærmingen og prosessene rundt design skremte meg i utgangspunktet: lavmælte ingeniører som prøver å presse gjennom organisasjonsendringer ender ikke alltid godt, men det viste seg å være et av de mest interessante områdene der vi ga betydelige bidrag til prosessen . I et nøtteskall var prosessen vår som følger: ny funksjonalitet ville bli utviklet av ett team, deretter ville lederteamet vårt gjennomgå/iterate forslaget, og så, når det ble godkjent, ville designet typisk bli overlevert til ingeniørteamet. I dette tilfellet "eide" ingeniørteamet effektivt tilgjengelighetsfunksjonaliteten fordi det var deres ansvar å fikse eventuelle problemer knyttet til den.
I begynnelsen var det en ganske vanskelig jobb å forklare at tilgjengelighet og brukervennlighet henger uløselig sammen og at dette måtte gjøres på designstadiet, ellers ville det føre til store endringer og omdefineringer av enkelte roller. Men med støtte fra ledelsen og nøkkelaktører tok vi ideen og satte den i gang slik at design ble testet for tilgjengelighet og brukervennlighet før de ble presentert for ledelsen.
Og denne tilbakemeldingen var ekstremt verdifull for alle - den var fantastisk som en øvelse i kunnskapsdeling/kommunikasjon om hvordan brukere samhandler med nettapplikasjoner, vi identifiserte en rekke UI-problemområder før de ble bygget, utviklingsteamene har nå mye bedre spesifikasjoner for ikke bare visuelle, men også atferdsmessige aspekter ved design. Ekte diskusjoner er morsomme, energiske, lidenskapelige diskusjoner om tekniske aspekter og interaksjoner.
Vi kunne gjort dette enda bedre hvis vi hadde blinde og funksjonshemmede brukere på disse (eller påfølgende) møtene - dette var vanskelig å organisere, men vi samarbeider nå med både lokale blindeorganisasjoner og selskaper , som tilbyr ekstern testing for å verifisere utførelsesflyt tidlig i utvikling – både på komponent- og utførelsesflytnivå.
Ingeniører har nå ganske detaljerte spesifikasjoner, tilgjengelige komponenter de kan bruke til å implementere, og en måte å validere utførelsesflyten på. Noe av det erfaringen har lært oss er det vi har savnet hele tiden – hvordan vi kan stoppe regresjonen. På samme måte kan folk bruke integrasjon eller ende-til-ende-tester for å teste funksjonalitet, som vi trenger for å oppdage endringer i interaksjoner og utførelsesflyt – både visuelle og atferdsmessige.
Å bestemme visuell regresjon er en ganske definert oppgave, det er svært lite som kan legges til prosessen annet enn å kanskje sjekke om fokus er synlig når man navigerer med tastaturet. Mer interessant er to relativt nye teknologier for å jobbe med tilgjengelighet.
- er et sett med verktøy som kan kjøres både i nettleseren og som en del av bygge-/testsyklusen for å identifisere problemer.
- Det har vært en spesielt utfordrende oppgave å verifisere at skjermlesere fungerer som de skal. Med innføringen av tilgang til Tilgjengelighet DOM, er vi endelig i stand til å ta tilgjengelighetsbilder av appen, omtrent som vi gjør for visuelle tester, og teste dem for regresjon.
Så i den andre delen av historien gikk vi fra å redigere HTML-kode til å jobbe på et høyere abstraksjonsnivå, endret designutviklingsprosessen og introduserte grundig testing. Nye prosesser, nye teknologier og nye abstraksjonsnivåer har fullstendig endret tilgjengelighetens landskap og hva det vil si å jobbe i dette rommet.
Men dette er bare begynnelsen.
Den neste "forståelsen" er at blinde brukere driver banebrytende teknologi - det er de som drar mest nytte av ikke bare endringene vi beskrev tidligere, men også at nye tilnærminger og ideer er muliggjort av ML/AI. For eksempel lar Immersive Reader-teknologi brukere presentere tekst enklere og tydeligere. Det kan leses høyt, setningsstrukturen brytes ned grammatisk, og til og med ordbetydninger vises grafisk. Dette passer ikke inn i den gamle «gjør det tilgjengelig»-mentalitet i det hele tatt – det er en brukervennlighetsfunksjon som vil hjelpe alle.
ML/AI muliggjør helt nye måter å samhandle og jobbe på, og vi er glade for å være en del av de neste stadiene av denne banebrytende reisen. Innovasjon er drevet av en endring i tenkning – menneskeheten har eksistert i årtusener, maskiner i hundrevis av år, nettsider i flere tiår, og smarttelefoner enda mindre, teknologien må tilpasse seg mennesker, og ikke omvendt.
PS Artikkelen er oversatt med mindre avvik fra originalen. Som medforfatter av denne artikkelen var jeg enig i disse digresjonene med Hugh.
Kun registrerte brukere kan delta i undersøkelsen. , vær så snill.
Legger du merke til tilgjengeligheten til applikasjonene dine?
-
Ja
-
Ikke
-
Dette er første gang jeg har hørt om app-tilgjengelighet.
17 brukere stemte. 5 brukere avsto.
Kilde: www.habr.com