På vej mod tilgængelighed

Fredag ​​er arbejdsdagens afslutning. Dårlige nyheder kommer altid i slutningen af ​​arbejdsdagen om fredagen.

Du er ved at forlade kontoret, et nyt brev om endnu en omorganisering er lige kommet med posten.

Tak xxxx, yyy fra i dag vil du rapportere zzzz
...
Og Hughs team vil sikre, at vores produkter er tilgængelige for mennesker med handicap.

Åh nej! Hvorfor fortjente jeg dette? Vil de have mig til at gå? Forbered dig på utaknemmeligt hårdt arbejde og forsøg på at rette op på andres fejl. Dette er bestemt en fiasko...

Dette var tilgængeligheden for et par år siden. Nogle stakkels sjæle fik jobbet med at "rydde op" i brugergrænsefladen for at forsøge at gøre det tilgængeligt for mennesker med handicap.

Hvad dette faktisk betød, var ret vagt - formentlig hvis du kunne se en fokusindikator og tabulator gennem felter, have noget alt-tekst og et par feltbeskrivelser, ville det anses for, at din ansøgning er tilgængelig ...

Men pludselig begyndte "bugs" at formere sig med en lavinehastighed.

Forskellige skærmlæsere (engelsk Skærmlæsere) og browsere opførte sig helt anderledes.

Brugere har klaget over, at appen er ubrugelig.

Så snart en fejl blev rettet et sted, dukkede en anden op et andet.

Og blot at ændre og rette fejl i brugergrænsefladen krævede Herculean indsats.

Jeg var der. Jeg overlevede, men det lykkedes ikke – teknisk set ryddede vi meget op, tilføjede en masse feltbeskrivelser, roller og opnåede en vis grad af compliance, men ingen var glade. Brugere klagede stadig over, at de ikke kunne navigere i applikationen. Lederen klagede stadig over den konstante strøm af fejl. Ingeniører klagede over, at problemet var stillet forkert, uden nogen klart defineret "korrekt" løsning, der ville fungere i alle tilfælde.

Der var nogle deciderede øjenåbnende øjeblikke på min rejse til at forstå tilgængelighed.
Måske var den første erkendelsen af, at det var svært at tilføje tilgængelighedsfunktionalitet oven på et færdigt produkt. Og det er endnu sværere at overbevise ledere om, at det er utroligt svært! Nej, det er ikke bare "tilføj et par tags", og brugergrænsefladen vil fungere fint. Nej, dette kan ikke afsluttes på tre uger, selv tre måneder vil ikke være nok.
Mit næste øjeblik af sandhed kom, da jeg på første hånd så, hvordan blinde brugere faktisk brugte vores app. Dette er SÅ anderledes end at se på fejlmeddelelser.

Jeg vil vende tilbage til dette igen og igen, men næsten alle vores "antagelser" om, hvordan folk brugte vores app, var forkerte.

Navigering af en kompleks brugergrænseflade ved hjælp af tastetryk Tab/Shift+Tab – det er ærgerligt! Vi har brug for noget bedre. Tastaturgenveje, overskrifter.

At miste fokus, når du ændrer brugergrænsefladen, er vel ikke et stort problem? Lad os tro om igen - det er utroligt forvirrende.

Jeg fortsatte, arbejdede på forskellige projekter i et stykke tid, og så startede vi et nyt projekt, med en kompleks brugergrænseflade og en overskuelig installation, for endelig at få tilgængelighed rigtigt denne gang.

Så vi tog et skridt tilbage og så på, hvordan vi kunne implementere dette anderledes og lykkes, og gøre processen mindre kedelig!

Ret hurtigt kom vi til nogle konklusioner:

1. Vi ønskede ikke, at folk, der udviklede brugergrænsefladen, skulle rode med aria-etiketter/roller og selvfølgelig HTML-strukturen af ​​komponenterne. Vi var nødt til at give dem de rigtige komponenter, der skabte tilgængelighed lige ud af boksen.
2. Tilgængelighed == Brugervenlighed – dvs. Dette er ikke kun en teknisk udfordring. Vi var nødt til at ændre hele designprocessen og sikre, at tilgængelighed blev taget i betragtning og diskuteret, før UI-design begyndte. Du skal tidligt tænke på, hvordan brugere vil opdage enhver funktionalitet, hvordan de vil navigere, og hvordan højreklik fra tastaturet vil fungere. Tilgængelighed bør være en integreret del af designprocessen - for nogle brugere er det meget mere end blot applikationens udseende.
3. Helt fra begyndelsen ønskede vi at få feedback fra blinde og andre handicappede brugere om brugervenligheden af ​​applikationen.
4. Vi havde brug for rigtig gode måder at fange tilgængelighedsregressioner på.

Nå, fra et ingeniørmæssigt synspunkt lød første del ret sjovt - at udvikle en arkitektur og implementere et bibliotek af komponenter. Og det var faktisk sådan.

Går et skridt tilbage, kigger ARIA eksempler og ved at tænke på dette som et designproblem snarere end et "tilpasningsproblem", introducerede vi nogle abstraktioner. En komponent har en 'Struktur' (består af HTML-elementer) og en 'Behaviour' (hvordan den interagerer med brugeren). For eksempel har vi i uddragene nedenfor en simpel uordnet liste. Ved at tilføje "adfærd" tilføjes de tilsvarende roller til listen for at få den til at fungere som en liste. Det samme gør vi for menuen.

Faktisk tilføjes ikke kun roller her, men også hændelseshandlere til tastaturnavigation.

Det her ser mere pænt ud. Hvis vi kunne få en ren adskillelse mellem dem, ville det være lige meget, hvordan strukturen blev skabt, vi kunne anvende Behaviours på den og få den rigtige tilgængelighed.

Du kan se dette i aktion på https://stardust-ui.github.io/react/ – UX bibliotek Reagerer, som er designet og implementeret med tilgængelighed for øje fra starten.

Den anden del - at ændre tilgangen og processerne omkring design skræmte mig oprindeligt: ​​ringe ingeniører, der forsøger at presse igennem organisatoriske forandringer, ender ikke altid godt, men det viste sig at være et af de mest interessante områder, hvor vi ydede væsentlige bidrag til processen . I en nøddeskal var vores proces som følger: ny funktionalitet ville blive udviklet af et team, derefter ville vores ledelsesteam gennemgå/iterere forslaget, og derefter, når det var godkendt, ville designet typisk blive overdraget til ingeniørteamet. I dette tilfælde "ejede" ingeniørteamet effektivt tilgængelighedsfunktionaliteten, fordi det var deres ansvar at løse eventuelle problemer forbundet med den.

I starten var det et ret svært arbejde at forklare, at tilgængelighed og brugervenlighed hænger uløseligt sammen, og at dette skulle gøres på designstadiet, ellers ville det føre til store ændringer og omdefineringer af nogle roller. Men med støtte fra ledelsen og nøgleaktører tog vi ideen og satte den i gang, så designs blev testet for tilgængelighed og brugervenlighed, inden de blev præsenteret for ledelsen.

Og denne feedback var ekstremt værdifuld for alle - det var fantastisk som en øvelse i videndeling/kommunikation om, hvordan brugere interagerer med webapplikationer, vi identificerede adskillige UI problemområder, før de blev bygget, udviklingsteamene i nu har meget bedre specifikationer for ikke kun visuelle, men også adfærdsmæssige aspekter af design. Rigtige diskussioner er sjove, energiske, passionerede diskussioner om tekniske aspekter og interaktioner.

Vi kunne gøre dette endnu bedre, hvis vi havde blinde og handicappede brugere på disse (eller efterfølgende) møder - dette var svært at organisere, men vi arbejder nu med både lokale blinde organisationer og virksomheder, som leverer ekstern test for at verificere eksekveringsflowet tidligt i udvikling – både på komponent- og udførelsesflowniveau.

Ingeniører har nu ret detaljerede specifikationer, tilgængelige komponenter, de kan bruge til at implementere, og en måde at validere udførelsesflowet på. En del af det, erfaringen har lært os, er, hvad vi har manglet hele tiden – hvordan vi kan stoppe regression. Ligeledes kan folk bruge integration eller ende-til-ende-tests til at teste funktionalitet, som vi har brug for for at opdage ændringer i interaktioner og eksekveringsflows – både visuelle og adfærdsmæssige.

At bestemme visuel regression er en ret defineret opgave, der er meget lidt der kan tilføjes til processen udover måske at tjekke om fokus er synligt når man navigerer med tastaturet. Mere interessant er to relativt nye teknologier til at arbejde med tilgængelighed.

1. Tilgængelighed Insights er et sæt værktøjer, der kan køres både i browseren og som en del af bygge-/testcyklussen for at identificere problemer.
2. Det har været en særlig udfordrende opgave at kontrollere, at skærmlæsere fungerer korrekt. Med indførelsen af ​​adgang til Tilgængelighed DOM, er vi endelig i stand til at tage snapshots af tilgængeligheden af ​​appen, ligesom vi gør til visuelle tests, og teste dem for regression.

Så i anden del af historien gik vi fra at redigere HTML-kode til at arbejde på et højere abstraktionsniveau, ændrede designudviklingsprocessen og introducerede grundig test. Nye processer, nye teknologier og nye abstraktionsniveauer har fuldstændig ændret tilgængelighedens landskab og hvad det vil sige at arbejde i dette rum.
Men dette er kun begyndelsen.

Den næste "forståelse" er, at blinde brugere driver banebrydende teknologi - det er dem, der får mest gavn af ikke kun de ændringer, vi beskrev tidligere, men også at nye tilgange og ideer er muliggjort af ML/AI. For eksempel giver Immersive Reader-teknologien brugerne mulighed for at præsentere tekst lettere og tydeligere. Det kan læses højt, sætningsstrukturen nedbrydes grammatisk, og endda ordbetydninger vises grafisk. Dette passer slet ikke ind i den gamle "gør det tilgængeligt"-mentalitet – det er en brugervenlig funktion, der vil hjælpe alle.

ML/AI muliggør helt nye måder at interagere og arbejde på, og vi er glade for at være en del af de næste faser af denne banebrydende rejse. Innovation er drevet af en ændring i tænkning – menneskeheden har eksisteret i årtusinder, maskiner i hundreder af år, hjemmesider i flere årtier, og smartphones endnu mindre, teknologien skal tilpasse sig mennesker, og ikke omvendt.

P.S. Artiklen er oversat med mindre afvigelser fra originalen. Som medforfatter af denne artikel var jeg enig i disse afvigelser med Hugh.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Er du opmærksom på tilgængeligheden af ​​dine applikationer?

• Ja

• Nej

• Det er første gang, jeg har hørt om app-tilgængelighed.

17 brugere stemte. 5 brugere undlod at stemme.

Kilde: www.habr.com