🥇Mod tilgængelighed

Fredag er slutningen på arbejdsdagen. Dårlige nyheder kommer altid fredag eftermiddag.

Du er ved at forlade kontoret, "ding" et nyt brev om endnu en omorganisering er lige ankommet til din e-mail.

Tak xxxx, yyy fra i dag skal du rapportere til zzzz.
…
Og teamet hos Hugh vil sikre tilgængeligheden af vores produkter for personer med handicap.

Åh nej! Hvad har jeg gjort for at fortjene dette? Vil de have, at jeg skal gå? Forberede sig på et utaknemmeligt og hårdt arbejde og forsøge at rette fejlene fra andre. Det kommer helt sikkert til at mislykkes...

Sådan var tilgængeligheden for nogle år siden. Nogle stakkels sjæle fik jobbet med at "rense" brugergrænsefladen for at forsøge at gøre den tilgængelig for personer med handicap.

Det, der faktisk betød, var ret uklart – sandsynligvis, hvis du kunne se fokusindikatoren og navigere gennem felterne med tabulatortasten, have noget alternativ tekst og et par beskrivelser til felterne, ville det blive betragtet som om dit program var tilgængeligt...

Men pludselig begyndte "fejlene" at vokse i et vildt tempo.

Forskellige skærmlæsere (engelsk. Screen Readers) og browsere opførte sig helt forskelligt.

Brugerne klagede over, at programmet ikke var brugbart.

Så snart en fejl blev rettet ét sted, opstod der en anden et andet sted.

Og blot det at ændre og rette fejl i brugergrænsefladen krævede kolossale anstrengelser.

Jeg har været der. Jeg overlevede, men vi "lykkedes" ikke – teknisk set har vi renset en masse, tilføjet mange beskrivelser til felterne, roller og opnået et eller andet niveau af overensstemmelse med kravene, men ingen var glade. Brugerne klagede stadig over, at de ikke kunne navigere i programmet. Lederen klagede stadig over den konstante strøm af fejl. Ingeniørerne klagede over en forkert opgaveformulering, uden en klart defineret "rigtig" løsning, der ville fungere i alle tilfælde.

På min rejse til at forstå tilgængelighed stødte jeg på nogle åbenlyse øjeblikke.
Måske var den første indsigt, at det er 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 ekstremt svært! Nej, det er ikke bare "tilføje et par tags", og brugergrænsefladen vil fungere glimrende. Nej, det er umuligt at afslutte det på tre uger; selv tre måneder vil være for lidt.
Mit næste øjeblik med sandhed kom, da jeg så, hvordan blinde brugere rent faktisk bruger vores app. Det er SÅ forskelligt fra at se fejlmeddelelserne.

Jeg vil vende tilbage til dette gang på gang, men næsten alle vores "antagelser" om, hvordan folk brugte vores app, viste sig at være forkerte.

Navigering gennem en kompleks brugergrænseflade ved hjælp af tasterne Tab/Shift+Tab – det er elendigt! Vi skal have noget bedre. Tastaturkombinationer, overskrifter.

At miste fokus ved ændring af UI er vel ikke et stort problem? Lad os tænke over det igen – det er vanvittigt forvirrende.

Jeg fortsatte, arbejdede et stykke tid på forskellige projekter, og så startede vi et nyt projekt med en kompleks brugergrænseflade og en klar instruktion om endelig at opnå den rigtige tilgængelighed denne gang.

Så vi tog et skridt tilbage og overvejede, hvordan vi kunne gøre dette anderledes og få det til at lykkes, samtidig med at selve arbejdsprocessen blev interessant!

Ret hurtigt kom vi frem til nogle konklusioner:

Vi ønskede ikke, at folk, der udvikler brugergrænsefladen, skulle kæmpe med aria-etiketter/roller og selvfølgelig med HTML-strukturen af komponenterne. Vi havde brug for at give dem de rette komponenter, hvor tilgængelighed var implementeret direkte fra starten.
Tilgængelighed == Brugervenlighed – dvs. det er ikke kun en teknisk opgave. Vi skulle ændre hele designprocessen og sikre os, at tilgængelighed blev taget i betragtning og diskuteret, inden designet af brugergrænsefladen begyndte. Det er nødvendigt at tænke over, hvordan brugere kan finde nogen funktionalitet, hvordan de vil navigere, og hvordan "højreklik" med musen vil fungere fra tastaturet. Tilgængelighed skal være en integreret del af designprocessen – for nogle brugere er det noget, der er meget mere end blot udseendet af applikationen.
Fra begyndelsen ønskede vi at få feedback fra blinde og andre brugere med handicap om, hvor nemt det var at bruge appen.
Vi havde brug for virkelig gode måder at fange regressionsproblemer i tilgængelighed.

Set fra et ingeniørperspektiv lød den første del ret sjovt – at udvikle arkitekturen og implementere komponentbiblioteket. Og det var faktisk også sådan.

Når vi ser tilbage og overvejer eksempler på ARIA og tænker på det som et designproblem snarere end et problem med 'tilpasning', indførte vi nogle abstraktioner. Komponentet har en ‘Struktur’ (bestående af HTML-elementer) og ‘Adfærd’ (hvordan det interagerer med brugeren). For eksempel har vi i de nedenstående fragmenter en simpel uordnet liste. Ved at tilføje 'adfærd' til listen, tilføjes de relevante roller, så det fungerer som en liste. Det gør vi på samme måde for menuer.

Faktisk tilføjes der ikke kun roller her, men også hændelsesbehandlere for navigation ved hjælp af tastaturet.

Det ser allerede mere pænt ud. Hvis vi kunne få en klar opdeling mellem dem, ville det ikke være vigtigt, hvordan strukturen blev oprettet, vi kunne anvende adfærd (Behaviours) på den og opnå korrekt tilgængelighed.

I praksis kan dette ses på https://stardust-ui.github.io/react/ – UX-biblioteket React, som bliver designet og implementeret med tilgængelighed for øje fra starten.

Den anden del – at ændre tilgangen og processerne omkring design var i starten skræmmende for mig: beskedne ingeniører, der forsøgte at presse organisatoriske ændringer igennem, har ikke altid en god afslutning, men det viste sig at være et af de mest interessante områder, hvor vi har gjort betydelige bidrag til processen. Kort sagt, vi havde følgende proces: nye funktioner blev udviklet af et team, hvorefter vores gruppe af ledere analyserede/itererede dette forslag, og derefter, efter godkendelse, blev designet som regel overdraget til ingeniørteamet. I dette tilfælde 'ejede' ingeniørteamet praktisk talt tilgængelighedsfunktionaliteten, da de skulle løse alle relaterede problemer.

I begyndelsen var det et ret udfordrende arbejde at forklare, at tilgængelighed og brugervenlighed er uadskilleligt forbundet, og at det skulle gøres allerede i designfasen, ellers ville det føre til store ændringer og redefinering af nogle roller. Alligevel, med støtte fra ledelsen og nøglespillerne, fik vi formidlet denne idé og bragt den til live, så designene kunne blive testet for tilgængelighed og brugvenlighed, før de blev præsenteret for ledelsen.

Og disse feedback var ekstremt værdifulde for alle – det var fantastisk som en øvelse i vidensdeling/informationsoverdragelse om, hvordan brugere interagerer med webapplikationer. Vi identificerede mange problemområder i brugergrænsefladen, før de blev bygget, og udviklingsteamene har nu langt bedre specifikationer, ikke kun for visuelle, men også for adfærdsmæssige aspekter af designet. De rigtige diskussioner er livlige, energiske og passionerede debatter om de tekniske aspekter og interaktionerne.

Vi kunne have gjort dette arbejde endnu bedre, hvis blinde brugere og brugere med handicap havde været til stede ved disse (eller efterfølgende) møder – det var svært at organisere, men nu samarbejder vi virkelig med lokale organisationer for blinde samt virksomheder, der tilbyder ekstern test for at kontrollere brugerflowet i de tidlige udviklingsfaser – både på komponentniveau og på niveauet for brugerflow.

Nu har ingeniørerne ret detaljerede specifikationer tilgængelige komponenter, som de kan bruge til implementering, og en metode til at kontrollere brugerflowet. Delvist har erfaringen lært os, hvad vi konstant har overset – hvordan vi kan forhindre regression. På samme måde kan folk bruge integrations- eller end-to-end tests til at kontrollere funktionaliteten, som vi har brug for for at opdage ændringer i interaktioner og brugerflows – både visuelle og adfærdsmæssige.

Definition af visuel regression er en ret specifik opgave, og der kan ikke tilføjes meget til denne proces, bortset fra muligvis at kontrollere, om fokus er synligt, når der navigeres med tastaturet. To relativt nye teknologier i arbejdet med tilgængelighed er mere interessante.

Accessibility Insights er et sæt af værktøjer, der kan køre både i browseren og som en del af bygge-/testcyklussen for at identificere problemer.
At kontrollere korrekt funktion af skærmlæsere har været en særlig udfordrende opgave. Med introduktionen af Accessibility DOM, har vi endelig fået mulighed for at tage snapshots af applikationen fra et tilgængelighedsperspektiv, meget lig de visuelle tests vi udfører, og tjekke dem for regression.

Så i den anden del af historien – er vi gået fra at redigere HTML-kode til at arbejde på et højere abstraktionsniveau, ændret designudviklingsprocessen og indført omhyggelig test. Nye processer, nye teknologier og nye abstraktionsniveauer har fuldstændig ændret opfattelsen af tilgængelighed og hvad det betyder at arbejde i dette område.
Men det er kun begyndelsen.

Den næste 'forståelse' er, at blinde brugere driver avanceret teknologi - det er dem, der får den største fordel ikke kun af de ændringer, vi har beskrevet tidligere, men også i, at nye tilgange og ideer bliver mulige med hjælp fra ML/AI. For eksempel gør teknologien Immersive Reader det lettere for brugere at forstå teksten. Den kan blive læst højt, sætningsstrukturen opdeles grammatisk, og endda betydningen af ord vises grafisk. Dette passer slet ikke ind i den gamle forståelse af 'at gøre det tilgængeligt' - det er en brugervenlighedsfunktion, der vil hjælpe alle.

Med ML/AI opstår der helt nye måder at interagere og arbejde på, og vi er glade for at være en del af de kommende faser af denne avancerede rejse. Innovationer er drevet af en ændring i tankegangen - menneskeheden har eksisteret i årtusinder, maskiner i hundreder af år, websites i flere årtier, og smartphones i endnu kortere tid, teknologien skal tilpasse sig mennesker, ikke omvendt.

P.S. Artikel er oversat med små afvigelser fra originalen. Som medforfatter af denne artikel har jeg godkendt disse afvigelser med Hugh.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.