På fredag är det slut på arbetsdagen. Dåliga nyheter kommer alltid i slutet av arbetsdagen på fredag.
Du är på väg att lämna kontoret, ett nytt brev om ytterligare en omorganisation har precis kommit med posten.
Tack xxxx, ååå från och med idag kommer du att rapportera zzzz
.
Och Hughs team kommer att se till att våra produkter är tillgängliga för personer med funktionsnedsättning.
Å nej! Varför förtjänade jag detta? Vill de att jag ska gå? Förbered dig på otacksamt hårt arbete och försök att rätta till andras misstag. Detta är definitivt ett misslyckande...
Detta var tillgängligheten för några år sedan. Några stackars själar fick jobbet att "städa upp" användargränssnittet för att försöka göra det tillgängligt för personer med funktionshinder.
Vad detta egentligen betydde var ganska vagt - förmodligen om du kunde se en fokusindikator och ta en flik genom fält, ha lite alt-text och ett par fältbeskrivningar, skulle det anses att din ansökan är tillgänglig ...
Men plötsligt började "buggarna" föröka sig med hastigheten av en lavin.
Olika skärmläsare (engelsk Skärmläsare) och webbläsare betedde sig helt annorlunda.
Användare har klagat på att appen är oanvändbar.
Så fort ett fel åtgärdats på ett ställe dök ett annat upp på ett annat.
Och att helt enkelt ändra och korrigera användargränssnittsfel krävde Herculean-ansträngningar.
Jag var där. Jag överlevde, men vi "lyckades" inte - tekniskt sett städade vi mycket, la till många fältbeskrivningar, roller och uppnådde en viss grad av efterlevnad, men ingen var nöjd. Användare klagade fortfarande på att de inte kunde navigera i programmet. Chefen klagade fortfarande över den ständiga strömmen av fel. Ingenjörer klagade på att problemet var felaktigt ställt, utan en tydligt definierad "rätt" lösning som skulle fungera i alla fall.
Det fanns några avgjort ögonöppnande ögonblick längs min resa till att förstå tillgänglighet.
Den första var kanske insikten om att det var svårt att lägga till tillgänglighetsfunktioner ovanpå en färdig produkt. Och det är ännu svårare att övertyga chefer om att det är otroligt svårt! Nej, det är inte bara "lägg till några taggar" och användargränssnittet kommer att fungera bra. Nej, detta kan inte slutföras på tre veckor, inte ens tre månader räcker.
Mitt nästa ögonblick av sanning kom när jag såg hur blinda användare faktiskt använde vår app. Detta är SÅ annorlunda från att titta på felmeddelanden.
Jag kommer att återkomma till detta om och om igen, men nästan alla våra "antaganden" om hur folk använde vår app var fel.
Navigera i ett komplext användargränssnitt med hjälp av tangenttryckningar Tab/Shift+Tab – det här suger! Vi behöver något bättre. Kortkommandon, rubriker.
Att tappa fokus när man ändrar användargränssnittet är väl inget stort problem? Låt oss tänka om - det här är otroligt förvirrande.
Jag fortsatte, jobbade med olika projekt ett tag, och sedan startade vi ett nytt projekt, med ett komplext användargränssnitt och en tydlig installation, för att äntligen få rätt tillgänglighet den här gången.
Så vi tog ett steg tillbaka och tittade på hur vi kunde implementera detta på ett annat sätt och lyckas, och göra processen mindre tråkig!
Ganska snabbt kom vi till några slutsatser:
- Vi ville inte att folk som utvecklade användargränssnittet skulle bråka med ariaetiketter/roller och, naturligtvis, komponenternas HTML-struktur. Vi behövde förse dem med rätt komponenter som skapade tillgänglighet direkt ur lådan.
- Tillgänglighet == Användarvänlighet – d.v.s. Detta är inte bara en teknisk utmaning. Vi behövde ändra hela designprocessen och säkerställa att tillgänglighet togs i beaktande och diskuterades innan UI-design började. Du måste tänka tidigt på hur användare kommer att upptäcka någon funktionalitet, hur de kommer att navigera och hur högerklicka från tangentbordet kommer att fungera. Tillgänglighet bör vara en integrerad del av designprocessen - för vissa användare är det mycket mer än bara utseendet på applikationen.
- Redan från början ville vi få feedback från blinda och andra funktionshindrade användare om hur lätt det är att använda applikationen.
- Vi behövde riktigt bra sätt att fånga tillgänglighetsregressioner.
Tja, ur teknisk synvinkel lät den första delen ganska rolig - att utveckla en arkitektur och implementera ett bibliotek med komponenter. Och det var verkligen så.
Tar ett steg tillbaka, tittar och genom att tänka på detta som ett designproblem snarare än ett "passningsproblem" introducerade vi några abstraktioner. En komponent har en 'Struktur' (består av HTML-element) och ett 'Beteende' (hur den interagerar med användaren). Till exempel, i utdragen nedan har vi en enkel oordnad lista. Genom att lägga till "beteenden" läggs motsvarande roller till i listan så att den fungerar som en lista. Vi gör samma sak för menyn.
Faktum är att inte bara roller läggs till här, utan även händelsehanterare för tangentbordsnavigering.
Det här ser snyggare ut. Om vi kunde få en ren separation mellan dem skulle det inte spela någon roll hur strukturen skapades, vi kunde tillämpa Behaviours på den och få rätt tillgänglighet.
Du kan se detta i aktion på – UX-bibliotek , som är designad och implementerad med tillgänglighet i åtanke från början.
Den andra delen - att ändra tillvägagångssätt och processer kring design skrämde mig till en början: låga ingenjörer som försöker driva igenom organisatoriska förändringar slutar inte alltid bra, men det visade sig vara ett av de mest intressanta områdena där vi gav betydande bidrag till processen . I ett nötskal var vår process följande: ny funktionalitet skulle utvecklas av ett team, sedan skulle vårt ledningsteam granska/iterera förslaget och sedan, när det godkänts, skulle designen vanligtvis överlämnas till ingenjörsteamet. I det här fallet "ägde" ingenjörsteamet tillgänglighetsfunktionen eftersom det var deras ansvar att åtgärda eventuella problem i samband med den.
I början var det ganska svårt att förklara att tillgänglighet och användbarhet är oupplösligt sammanlänkade och att detta måste göras på designstadiet, annars skulle det leda till stora förändringar och omdefinieringar av vissa roller. Men med stöd av ledningen och nyckelaktörer tog vi idén och satte igång den så att design testades för tillgänglighet och användbarhet innan de presenterades för ledningen.
Och denna feedback var oerhört värdefull för alla - den var fantastisk som en övning i kunskapsdelning/kommunikation om hur användare interagerar med webbapplikationer, vi identifierade många problemområden för användargränssnittet innan de byggdes, utvecklingsteamen har nu mycket bättre specifikationer för att inte endast visuella, men också beteendemässiga aspekter av design. Riktiga diskussioner är roliga, energiska, passionerade diskussioner om tekniska aspekter och interaktioner.
Vi skulle kunna göra detta ännu bättre om vi hade blinda och funktionshindrade användare vid dessa (eller efterföljande) möten - detta var svårt att organisera, men vi arbetar nu med både lokala blinda organisationer och företag , som tillhandahåller externa tester för att verifiera exekveringsflödet tidigt i utveckling – både på komponent- och utförandeflödesnivåer.
Ingenjörer har nu ganska detaljerade specifikationer, tillgängliga komponenter de kan använda för att implementera och ett sätt att validera exekveringsflödet. En del av vad erfarenheten har lärt oss är vad vi har saknat hela tiden – hur vi kan stoppa regressionen. På samma sätt kan människor använda integration eller end-to-end-tester för att testa funktionalitet, som vi behöver för att upptäcka förändringar i interaktioner och exekveringsflöden – både visuella och beteendemässiga.
Att fastställa visuell regression är en ganska definierad uppgift, det finns väldigt lite som kan läggas till i processen annat än att kanske kontrollera om fokus är synligt när man navigerar med tangentbordet. Mer intressant är två relativt nya tekniker för att arbeta med tillgänglighet.
- är en uppsättning verktyg som kan köras både i webbläsaren och som en del av bygg-/testcykeln för att identifiera problem.
- Att verifiera att skärmläsare fungerar korrekt har varit en särskilt utmanande uppgift. Med införandet av tillgång till Tillgänglighet DOM, vi kan äntligen ta tillgänglighetsbilder av appen, ungefär som vi gör för visuella tester, och testa dem för regression.
Så, i den andra delen av berättelsen - gick vi från att redigera HTML-kod till att arbeta på en högre abstraktionsnivå, ändrade designutvecklingsprocessen och introducerade grundliga tester. Nya processer, ny teknik och nya abstraktionsnivåer har helt förändrat tillgänglighetslandskapet och vad det innebär att arbeta i detta utrymme.
Men det här är bara början.
Nästa "förståelse" är att blinda användare driver banbrytande teknik – det är de som drar mest nytta av inte bara de förändringar vi beskrev tidigare, utan också att nya tillvägagångssätt och idéer möjliggörs av ML/AI. Till exempel låter Immersive Reader-tekniken användare presentera text enklare och tydligare. Det kan läsas högt, meningsstrukturen bryts ner grammatiskt och till och med ordets betydelser visas grafiskt. Detta passar inte alls in i den gamla "gör det tillgängligt"-mentalitet – det är en användbarhetsfunktion som kommer att hjälpa alla.
ML/AI möjliggör helt nya sätt att interagera och arbeta, och vi är glada över att vara en del av nästa steg i denna banbrytande resa. Innovation drivs av ett förändrat tänkande – mänskligheten har funnits i årtusenden, maskiner i hundratals år, webbplatser i flera decennier och smartphones ännu mindre, tekniken måste anpassa sig till människor, och inte tvärtom.
PS Artikeln har översatts med mindre avvikelser från originalet. Som medförfattare till den här artikeln höll jag med Hugh om dessa avvikelser.
Endast registrerade användare kan delta i undersökningen. , Snälla du.
Är du uppmärksam på tillgängligheten för dina applikationer?
-
Ja
-
Ingen
-
Det är första gången jag har hört talas om apptillgänglighet.
17 användare röstade. 5 användare avstod från att rösta.
Källa: will.com