Op weg naar toegankelijkheid

Vrijdag is het einde van de werkdag. Slecht nieuws komt altijd aan het einde van de werkdag op vrijdag.

U staat op het punt het kantoor te verlaten, er is zojuist een nieuwe brief over een nieuwe reorganisatie binnengekomen.

Bedankt xxxx, yyy vanaf vandaag rapporteer je zzzz
...
En het team van Hugh zal ervoor zorgen dat onze producten toegankelijk zijn voor mensen met een handicap.

Oh nee! Waarom heb ik dit verdiend? Willen ze dat ik wegga? Bereid je voor op ondankbaar hard werken en proberen de fouten van anderen te corrigeren. Dit is absoluut een mislukking...

Dit was de beschikbaarheid een paar jaar geleden. Sommige arme zielen kregen de taak om de gebruikersinterface "op te ruimen" om te proberen deze toegankelijk te maken voor mensen met een handicap.

Wat dit eigenlijk betekende was behoorlijk vaag - vermoedelijk als je een focusindicator zou kunnen zien en door velden zou kunnen bladeren, wat alt-tekst en een paar veldbeschrijvingen zou hebben, zou je ervan uitgaan dat je applicatie toegankelijk is ...

Maar plotseling begonnen de ‘insecten’ zich te vermenigvuldigen met de snelheid van een lawine.

Verschillende schermlezers (Eng. Schermlezers) en browsers gedroegen zich totaal anders.

Gebruikers hebben geklaagd dat de app onbruikbaar is.

Zodra op de ene plaats een fout werd gecorrigeerd, verscheen er op een andere plaats een andere.

En het simpelweg veranderen en corrigeren van fouten in de gebruikersinterface vergde enorme inspanningen.

Ik was daar. Ik heb het overleefd, maar het is ons niet "geslaagd" - technisch gezien hebben we veel opgeruimd, veel veldbeschrijvingen en rollen toegevoegd en een zekere mate van naleving bereikt, maar niemand was blij. Gebruikers klaagden nog steeds dat ze niet door de applicatie konden navigeren. De manager klaagde nog steeds over de constante stroom fouten. Ingenieurs klaagden dat het probleem verkeerd werd gesteld, zonder dat er een duidelijk gedefinieerde “juiste” oplossing bestond die in alle gevallen zou werken.

Er waren een aantal beslist eye-openende momenten tijdens mijn reis naar het begrijpen van toegankelijkheid.
Misschien was de eerste het besef dat het moeilijk was om toegankelijkheidsfunctionaliteit toe te voegen aan een eindproduct. En het is nog moeilijker om managers ervan te overtuigen dat het ongelooflijk moeilijk is! Nee, het is niet alleen maar "een paar tags toevoegen" en de gebruikersinterface werkt prima. Nee, dit kan niet in drie weken worden afgerond; zelfs drie maanden zullen niet genoeg zijn.
Mijn volgende moment van de waarheid kwam toen ik uit de eerste hand zag hoe blinde gebruikers onze app daadwerkelijk gebruikten. Dit is ZO anders dan kijken naar foutmeldingen.

Ik kom hier steeds weer op terug, maar bijna al onze ‘aannames’ over hoe mensen onze app gebruikten, waren verkeerd.

Navigeren door een complexe gebruikersinterface met behulp van toetsaanslagen Tab/Shift+Tab – dit is stom! We hebben iets beters nodig. Sneltoetsen, kopteksten.

Het verliezen van de focus bij het veranderen van de gebruikersinterface is geen groot probleem, toch? Laten we er nog eens over nadenken: dit is ongelooflijk verwarrend.

Ik ging door, werkte een tijdje aan verschillende projecten, en toen begonnen we aan een nieuw project, met een complexe gebruikersinterface en een duidelijke installatie, om deze keer eindelijk de toegankelijkheid goed te krijgen.

We hebben dus een stapje terug gedaan en gekeken hoe we dit anders konden implementeren en slagen, en het proces minder saai konden maken!

Al snel kwamen we tot enkele conclusies:

1. We wilden niet dat mensen die de gebruikersinterface ontwikkelden, zouden knoeien met aria-labels/-rollen en natuurlijk met de HTML-structuur van de componenten. We moesten ze voorzien van de juiste componenten die toegankelijkheid direct uit de doos mogelijk maakten.
2. Toegankelijkheid == Gebruiksgemak – d.w.z. Dit is niet alleen een technische uitdaging. We moesten het hele ontwerpproces veranderen en ervoor zorgen dat er rekening werd gehouden met toegankelijkheid en dat deze werd besproken voordat het UI-ontwerp begon. U moet al vroeg nadenken over hoe gebruikers functionaliteit zullen ontdekken, hoe ze zullen navigeren en hoe klikken met de rechtermuisknop vanaf het toetsenbord zal werken. Toegankelijkheid moet een integraal onderdeel zijn van het ontwerpproces; voor sommige gebruikers is het veel meer dan alleen het uiterlijk van de applicatie.
3. Vanaf het allereerste begin wilden we feedback krijgen van blinde en andere gehandicapte gebruikers over het gebruiksgemak van de applicatie.
4. We hadden echt goede manieren nodig om toegankelijkheidsregressies op te vangen.

Vanuit technisch oogpunt klonk het eerste deel best leuk: het ontwikkelen van een architectuur en het implementeren van een bibliotheek met componenten. En inderdaad, het was zo.

Een stap achteruit doen, kijken ARIA-voorbeelden en door dit als een ontwerpprobleem te beschouwen in plaats van als een 'inpassen'-probleem, introduceerden we enkele abstracties. Een component heeft een 'Structuur' (bestaat uit HTML-elementen) en een 'Gedrag' (hoe deze met de gebruiker omgaat). In de onderstaande fragmenten hebben we bijvoorbeeld een eenvoudige, ongeordende lijst. Door 'gedrag' toe te voegen, worden de overeenkomstige rollen aan de lijst toegevoegd, zodat deze als een lijst fungeert. Hetzelfde doen we voor het menu.

In feite worden hier niet alleen rollen toegevoegd, maar ook gebeurtenishandlers voor toetsenbordnavigatie.

Dit ziet er netter uit. Als we er een duidelijke scheiding tussen konden krijgen, zou het niet uitmaken hoe de structuur tot stand kwam; we zouden er Gedrag op kunnen toepassen en de toegankelijkheid goed kunnen krijgen.

Je kunt dit in actie zien op https://stardust-ui.github.io/react/ – UX-bibliotheek Reageren, dat vanaf het begin is ontworpen en geïmplementeerd met toegankelijkheid in gedachten.

Het tweede deel – het veranderen van de aanpak en processen rond ontwerp maakte me aanvankelijk bang: eenvoudige ingenieurs die organisatorische veranderingen proberen door te voeren, lopen niet altijd goed af, maar het bleek een van de interessantste gebieden waarop we een belangrijke bijdrage aan het proces hebben geleverd. . In een notendop was ons proces als volgt: nieuwe functionaliteit zou door één team worden ontwikkeld, vervolgens zou ons leiderschapsteam het voorstel beoordelen/herbeoordelen, en vervolgens, eenmaal goedgekeurd, zou het ontwerp doorgaans worden overgedragen aan het technische team. In dit geval was het technische team in feite ‘eigenaar’ van de toegankelijkheidsfunctionaliteit, omdat het hun verantwoordelijkheid was om eventuele problemen die ermee gepaard gingen op te lossen.

In het begin was het een hele lastige klus om uit te leggen dat toegankelijkheid en bruikbaarheid onlosmakelijk met elkaar verbonden zijn en dat dit al in de ontwerpfase moest gebeuren, anders zou het leiden tot grote veranderingen en herdefinities van sommige rollen. Met de steun van het management en de belangrijkste spelers hebben we het idee echter in praktijk gebracht, zodat ontwerpen werden getest op toegankelijkheid en bruikbaarheid voordat ze aan het management werden gepresenteerd.

En deze feedback was uiterst waardevol voor iedereen - het was fantastisch als een oefening in het delen van kennis/communicatie over hoe gebruikers omgaan met webapplicaties, we hebben talloze UI-probleemgebieden geïdentificeerd voordat ze werden gebouwd, de ontwikkelingsteams hebben nu veel betere specificaties van niet alleen visuele, maar ook gedragsaspecten van design. Echte discussies zijn leuke, energieke, gepassioneerde discussies over technische aspecten en interacties.

We zouden dit nog beter kunnen doen als we bij deze (of daaropvolgende) bijeenkomsten blinde en gehandicapte gebruikers hadden - dit was moeilijk te organiseren, maar we werken nu samen met zowel lokale blinde organisaties als bedrijven, die externe tests leveren om de uitvoeringsstroom in een vroeg stadium te verifiëren ontwikkeling – zowel op het niveau van de componenten als op het niveau van de uitvoeringsstroom.

Ingenieurs beschikken nu over vrij gedetailleerde specificaties, beschikbare componenten die ze kunnen gebruiken om te implementeren en een manier om de uitvoeringsstroom te valideren. Een deel van wat de ervaring ons heeft geleerd, is wat we de hele tijd hebben gemist: hoe we de achteruitgang kunnen stoppen. Op dezelfde manier kunnen mensen integratie- of end-to-end-tests gebruiken om de functionaliteit te testen, wat we nodig hebben om veranderingen in interacties en uitvoeringsstromen te detecteren, zowel visueel als gedragsmatig.

Het bepalen van visuele regressie is een vrij gedefinieerde taak; er kan heel weinig aan het proces worden toegevoegd, behalve misschien controleren of de focus zichtbaar is tijdens het navigeren met het toetsenbord. Interessanter zijn twee relatief nieuwe technologieën om met toegankelijkheid te werken.

1. Toegankelijkheidsinzichten is een set tools die zowel in de browser als als onderdeel van de build-/testcyclus kunnen worden uitgevoerd om problemen te identificeren.
2. Het verifiëren dat schermlezers correct werken was een bijzonder uitdagende taak. Met de introductie van toegang tot Toegankelijkheid DOM, kunnen we eindelijk momentopnamen van de toegankelijkheid van de app maken, net zoals we doen voor visuele tests, en deze testen op regressie.

Dus in het tweede deel van het verhaal zijn we overgestapt van het bewerken van HTML-code naar het werken op een hoger abstractieniveau, hebben we het ontwerpontwikkelingsproces gewijzigd en grondig testen geïntroduceerd. Nieuwe processen, nieuwe technologieën en nieuwe abstractieniveaus hebben het landschap van toegankelijkheid en wat het betekent om in deze ruimte te werken volledig veranderd.
Maar dit is nog maar het begin.

Het volgende ‘begrip’ is dat blinde gebruikers de nieuwste technologie aansturen – zij zijn degenen die niet alleen het meeste profiteren van de veranderingen die we eerder hebben beschreven, maar ook dat nieuwe benaderingen en ideeën mogelijk worden gemaakt door ML/AI. Met Immersive Reader-technologie kunnen gebruikers bijvoorbeeld tekst gemakkelijker en duidelijker presenteren. Het kan voorgelezen worden, de zinsstructuur wordt grammaticaal opgesplitst en zelfs woordbetekenissen worden grafisch weergegeven. Dit past helemaal niet in de oude 'maak het toegankelijk'-mentaliteit - het is een bruikbaarheidsfunctie die iedereen zal helpen.

ML/AI maakt geheel nieuwe manieren van interactie en werken mogelijk, en we zijn verheugd deel uit te maken van de volgende fasen van dit baanbrekende traject. Innovatie wordt aangedreven door een verandering in het denken: de mensheid bestaat al duizenden jaren, machines al honderden jaren, websites al tientallen jaren en smartphones nog minder. Technologie moet zich aanpassen aan mensen, en niet andersom.

P.S. Het artikel is vertaald met kleine afwijkingen van het origineel. Als co-auteur van dit artikel was ik het met Hugh eens over deze uitweidingen.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Let jij op de toegankelijkheid van jouw applicaties?

• Ja

• Geen

• Dit is de eerste keer dat ik hoor over app-toegankelijkheid.

17 gebruikers hebben gestemd. 5 gebruikers onthielden zich van stemming.

Bron: www.habr.com