Mot tillgänglighet

Fredag är slutet på arbetsdagen. Dåliga nyheter kommer alltid på fredag eftermiddagen.

Du är på väg att lämna kontoret, ett "ding" nytt mejl om ännu en omorganisation har just kommit in i inkorgen.

Tack xxxx, yyy från och med idag kommer du att rapportera till zzzz.
…
Och teamet Hu kommer att säkerställa tillgången till våra produkter för personer med funktionsnedsättningar.

Åh nej! Vad har jag gjort för att förtjäna detta? Vill de att jag ska gå? Att ställa in sig på ett tacksamt tufft arbete och försöka rätta till andra människors misstag. Detta kan bara sluta i fiasko…

Så här var tillgången för några år sedan. Vissa stackare fick jobb att "rensa" användargränssnittet för att försöka göra det tillgängligt för personer med funktionsnedsättningar.

Vad detta egentligen innebar var ganska vagt – troligen, om du kunde se fokusindikatorn och navigera fälten med tabulatortangenten, ha någon alternativ text och ett par beskrivningar av fälten, så skulle det anses att din applikation var tillgänglig…

Men plötsligt började "buggar" dyka upp i en rasande takt.

Olika skärmläsare (eng. Screen Readers) och webbläsare fungerade helt olika.

Användarna klagade på att applikationen var oanvändbar.

Så snart en bugg åtgärdades på ett ställe, dök en annan upp på ett annat.

Och att bara byta och rätta till användargränssnittets misstag krävde titaniska ansträngningar.

Jag har varit där. Jag överlevde, men vi "lyckades" inte – tekniskt sett städade vi mycket, la till mycket beskrivningar av fälten, roller och nådde någon nivå av överensstämmelse, men ingen var nöjd. Användarna klagade fortfarande på att de inte kunde navigera i applikationen. Chefen klagade fortfarande på det konstanta flödet av buggar. Ingenjörerna klagade på felaktig uppdragsformulering, utan en klart definierad "rätt" lösning som skulle fungera i alla fall.

På min väg till att förstå tillgänglighet stötte jag på vissa tydligt avslöjande ögonblick.
Kanske var den första insikten att lägga till tillgänglig funktionalitet ovanpå en färdig produkt är svårt. Ännu svårare är det att övertyga chefer om att det verkligen är oerhört svårt! Nej, det handlar inte bara om att "lägga till några taggar" så att användargränssnittet fungerar utmärkt. Nej, det är omöjligt att avsluta på tre veckor, även tre månader är för lite.
Mitt nästa ögonblick av sanning kom när jag faktiskt såg hur blinda användare använde vår app. Det är så annorlunda än att bara se felmeddelanden.

Jag kommer att återkomma till detta gång på gång, men nästan alla våra "antaganden" om hur människor använde vår app var felaktiga.

Navigera genom ett komplext användargränssnitt med hjälp av tangenter Tab/Shift+Tab – är uselt! Vi behöver något bättre. Tangentkombinationer, rubriker.

Att tappa fokus vid ändring av UI är väl inte en stor fråga? Låt oss tänka en gång till – det är vansinnigt förvirrande.

Jag fortsatte, arbetade ett tag med olika projekt, och sedan började vi ett nytt projekt med ett komplext användargränssnitt och en tydlig avsikt att äntligen denna gång få rätt tillgänglighet.

Så vi tog ett steg tillbaka och tittade på hur vi kan genomföra detta på ett annat sätt och lyckas, och göra själva arbetsprocessen intressant!

Ganska snabbt kom vi fram till några slutsatser:

1. Vi ville inte att de som utvecklar användargränssnitt skulle bekymra sig över aria-etiketter/roller och naturligtvis HTML-strukturen för komponenterna. Vi behövde förse dem med rätt komponenter, där tillgängligheten är inbyggd från början.
2. Tillgänglighet == Användbarhet – dvs. det är inte bara en teknisk uppgift. Vi behövde förändra hela designprocessen och se till att tillgänglighet beaktas och diskuteras innan designen av användargränssnittet påbörjas. Det är viktigt att tänka på hur användare kan upptäcka någon funktionalitet, hur de kommer att navigera och hur "högerklick" med tangentbordet kommer att fungera. Tillgänglighet bör vara en integrerad del av designprocessen – för vissa användare är det något mycket mer än bara utseendet på appen.
3. Från början ville vi få återkoppling från blinda och andra användare med funktionshinder om hur lättanvända applikationen är.
4. Vi behövde verkligen bra sätt att fånga upp tillgänglighetsregressioner.

Ur ett ingenjörsperspektiv kändes första delen ganska rolig – att utveckla arkitekturen och implementera komponentbiblioteket. Och så var det verkligen.

Genom att ta ett steg tillbaka och se på exempel på ARIA och tänka på detta som en designfråga snarare än en fråga om 'anpassning', införde vi vissa abstraktioner. Komponenten har en 'Struktur' (bestående av HTML-element) och ett 'Beteende' (hur det interagerar med användaren). Till exempel, i de nedanstående fragmenten har vi en enkel oordnad lista. Vid tillägg av 'beteendet' till listan tillförs motsvarande roller så att den fungerar som en lista. På motsvarande sätt gör vi för menyer.

I själva verket läggs det inte bara till roller här, utan även händelseshanterare för navigering med tangentbord.

Det ser mycket mer ordnat ut. Om vi kunde få en ren uppdelning mellan dem skulle det vara oviktigt hur strukturen skapades, vi skulle kunna tillämpa beteenden på den och få rätt tillgänglighet.

I praktiken kan detta ses på adressen https://stardust-ui.github.io/react/ – UX-biblioteket React, som designas och implementeras med tillgänglighet i åtanke från början.

Den andra delen – att förändra tillvägagångssättet och processerna kring designen skrämde mig först: blyga ingenjörer som försöker driva organisatoriska förändringar slutar inte alltid bra, men det visade sig vara ett av de mest intressanta områdena där vi har gjort ett betydande bidrag till processen. Kort sagt hade vi följande process: ny funktionalitet utvecklades av ett team, sedan analyserade/itererade vår grupp av ledare detta förslag, och sedan, efter godkännande, överlämnades designen vanligtvis till ingenjörsteamet. I det här fallet 'ägd' ingenjörsteamet faktiskt tillgänglighetsfunktionaliteten, eftersom de måste lösa alla relaterade problem.

I början var det en ganska svår uppgift – att förklara att tillgänglighet och användbarhet är intimt sammanlänkade och att detta måste beaktas redan på designstadiet, annars ledde det till stora förändringar och omdefiniering av vissa roller. Tack vare stödet från ledningen och viktiga aktörer fick vi fram denna idé och satte den i verket så att designen skulle kontrolleras för tillgänglighet och användbarhet innan de presenterades för ledningen.

Och dessa synpunkter var oerhört värdefulla för alla – det var fantastiskt som en övning i kunskapsutbyte/information om hur användarna interagerar med webbapplikationer, vi identifierade många problemområden i användargränssnittet innan de byggdes, utvecklingsteamen har nu mycket bättre specifikationer för både visuella och beteendemässiga aspekter av designen. Riktiga diskussioner är roliga, energiska och passionerade diskussioner om tekniska aspekter och interaktioner.

Vi skulle kunna göra detta arbete ännu bättre om vi hade blinda användare och användare med funktionshinder med oss på dessa (eller kommande) möten – det var svårt att organisera, men nu samarbetar vi verkligen med både lokala organisationer för blinda och företag som erbjuder extern testning för att kontrollera flödet i tidiga utvecklingsstadier – både på komponentnivå och flödesnivå.

Nu har ingenjörerna ganska detaljerade specifikationer, tillgängliga komponenter som de kan använda för implementation och ett sätt att kontrollera flödet. Dels har erfarenheten lärt oss vad vi ständigt missade – hur vi kan förhindra regression. På liknande sätt kan folk använda integrations- eller genomgående tester för att kontrollera funktionaliteten, vilket vi behöver för att upptäcka förändringar i interaktioner och flöden – både visuella och beteendemässiga.

Definitionen av visuell regression är en ganska specifik uppgift, det finns egentligen inte mycket mer att tillägga till denna process, förutom möjligen att kontrollera om fokus är synligt när man navigerar med tangentbordet. Mer intressanta är två relativt nya teknologier för att arbeta med tillgänglighet.

1. Accessibility Insights är en uppsättning verktyg som kan köras både i webbläsaren och inom bygg-/testcykeln för att identifiera problem.
2. Att kontrollera att skärmläsarens program fungerar korrekt har varit en särskilt svår uppgift. Med introduktionen av Accessibility DOM, har vi äntligen fått möjlighet att ta snappbilder av applikationen ur tillgänglighetssynvinkel, mycket liknande hur vi tar dem för visuella tester, och kontrollerar dem för regression.

Så i den andra delen av historien har vi flyttat från att redigera HTML-kod till att arbeta på en högre abstraktionsnivå, ändrat designprocessen och infört noggrant testande. Nya processer, nya teknologier och nya nivåer av abstraktion har helt förändrat förståelsen av tillgänglighet och vad det betyder att arbeta inom detta område.
Men det här är bara början.

Den nästa "förståelsen" är att blinda användare driver fram teknik – de är just de som får störst nytta inte bara av de förändringar vi tidigare har beskrivit, utan av att nya tillvägagångssätt och idéer blir möjliga med hjälp av ML/AI. Till exempel, Immersive Reader-teknologi gör det enklare och mer förståeligt för användare att ta till sig text. Den kan läsas högt, meningsstrukturen delas grammatiskt och till och med betydelsen av ord visas grafiskt. Det här passar absolut inte in i den gamla uppfattningen av att "göra det tillgängligt" – det är en användbarhetsfunktion som hjälper alla.

Med ML/AI kommer helt nya sätt att interagera och arbeta, och vi är glada över att vara en del av de kommande stegen på denna banbrytande väg. Innovationer kommer genom förändrad tankesätt – mänskligheten har funnits i årtusenden, maskiner i hundratals år, webbplatser i några decennier, och smartphones ännu mindre, teknologin måste anpassa sig till människorna, inte tvärtom.

P.S. Artikeln har översatts med små avvikelser från originaltexten. Som medförfattare till denna artikel har jag diskuterat dessa avvikelser med Hugh.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Fokuserar du på tillgängligheten av dina applikationer?

• Ja

• Ingen

• Jag har aldrig hört talas om applikationers tillgänglighet.

17 användare har röstat. 5 användare avstod.

Källa: habr.com