Op weg naar toegankelijkheid

Op weg naar toegankelijkheid

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

Je staat op het punt het kantoor te verlaten, en dan ā€˜ping’ – een nieuwe e-mail over weer een reorganisatie komt net binnen.

Bedankt xxxx, yyy, vanaf vandaag rapporteer je aan zzzz.
…
En het team van Hugh zal de beschikbaarheid van onze producten voor mensen met een beperking waarborgen.

Oh nee! Waarom verdien ik dit? Willen ze dat ik vertrek? Zich voorbereiden op onaangenaam zwaar werk en proberen de fouten van anderen recht te zetten. Dit gaat zeker mis...

Zo was de toegankelijkheid enkele jaren geleden. Sommige arme mensen kregen de taak om de gebruikersinterface ā€˜schoon’ te maken in een poging deze toegankelijk te maken voor mensen met een beperking.

Wat dit daadwerkelijk betekende, was vrij vaag – waarschijnlijk als je de focusindicator kon zien en je je door de velden kon bewegen met tab, wat alternatieve tekst had en een paar beschrijvingen bij de velden, dan werd aangenomen dat je applicatie toegankelijk was...

Maar plotseling begonnen ā€˜bugs’ zich als een lawine te vermenigvuldigen.

Verschillende schermlezers (Engels. Screen Readers) en browsers gedroegen zich volkomen anders.

Gebruikers klaagden dat de applicatie onbruikbaar was.

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

En simpelweg het wijzigen en corrigeren van fouten in de gebruikersinterface vereiste titanenarbeid.

Ik was daar. Ik heb het overleefd, maar we hebben niet ā€˜gepresteerd’ – technisch hebben we veel schoongemaakt, veel beschrijvingen aan de velden toegevoegd, rollen toegevoegd en een bepaald niveau van compliance bereikt, maar niemand was tevreden. Gebruikers klaagden nog steeds dat ze zich niet konden oriĆ«nteren in de applicatie. De manager klaagde nog steeds over een constante stroom van fouten. Ingenieurs klaagden over onduidelijke opdrachtgevers zonder een eenduidige ā€˜juiste’ oplossing die in alle gevallen werkte.

Op mijn weg naar begrip van toegankelijkheid kwam ik enkele blijkbaar onthullende momenten tegen.
Misschien was het eerste het besef dat het toevoegen van toegankelijkheidsfunctionaliteit bovenop een bestaand product moeilijk is. En nog moeilijker is het om managers ervan te overtuigen dat het ongelooflijk uitdagend is! Nee, het is niet gewoon 'een paar tags toevoegen' en de gebruikersinterface zal perfect werken. Nee, het is onmogelijk om het in drie weken af te krijgen; zelfs drie maanden is te kort.
Mijn volgende waarheidservaring kwam toen ik met eigen ogen zag hoe blinde gebruikers onze applicatie daadwerkelijk gebruiken. Het is ZO anders dan het bekijken van foutmeldingen.

Ik zal hier steeds op terugkomen, maar bijna al onze 'veronderstellingen' over hoe mensen onze applicatie gebruikten, waren verkeerd.

Navigeren door een complexe gebruikersinterface met behulp van toetsenborden Tab/Shift+Tab is gewoon slecht! We hebben iets beters nodig. Toetsencombinaties, koppen.

Verlies van focus bij het wijzigen van de gebruikersinterface is toch geen groot probleem? Laten we daar nog eens over nadenken – het is waanzinnig verwarrend.

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

Dus namen we een stap terug en keken we hoe we dit anders konden aanpakken en succesvol konden zijn, en zodat het eigenlijke werkproces niet saai was!

Al snel kwamen we tot enkele conclusies:

  1. We wilden niet dat de mensen die de gebruikersinterface ontwikkelden rond speelden met aria-labels/rollen en natuurlijk met de HTML-structuur van componenten. We moesten ze voorzien van de juiste componenten waarin toegankelijkheid standaard is ingebouwd.
  2. Toegankelijkheid == Bruikbaarheid – dat wil zeggen, het is niet alleen een technische uitdaging. We moesten het hele ontwerpproces veranderen en ervoor zorgen dat toegankelijkheid in overweging werd genomen en besproken vóór het ontwerp van de gebruikersinterface. We moeten van tevoren nadenken over hoe gebruikers functionaliteit kunnen ontdekken, hoe ze zich zullen verplaatsen en hoe de ā€˜rechter muisklik’ met het toetsenbord zal werken. Toegankelijkheid moet een integraal onderdeel van het ontwerpproces zijn – voor sommige gebruikers is het veel meer dan alleen de uitstraling van de applicatie.
  3. Vanaf het begin wilden we feedback krijgen van blinde en andere gebruikers met een beperking over de gebruiksvriendelijkheid van de applicatie.
  4. We hadden echt goede manieren nodig om regressie in toegankelijkheid te detecteren.

Nou, vanuit een technisch perspectief klonk het eerste deel behoorlijk leuk – het ontwikkelen van de architectuur en het implementeren van de componentenbibliotheek. En dat was het ook echt.

Terugkijkend op de ARIA-voorbeelden en het beschouwen als een ontwerpprobleem in plaats van een probleem van 'aanpassing', hebben we enkele abstracties geĆÆntroduceerd. Een component heeft een 'Structuur' (bestaande uit HTML-elementen) en 'Gedrag' (hoe het met de gebruiker interacteert). Bijvoorbeeld, in de onderstaande fragmenten hebben we een eenvoudige ongesorteerde lijst. Door ā€˜gedrag’ aan de lijst toe te voegen, worden de bijbehorende rollen toegevoegd zodat deze als een lijst functioneert. We doen hetzelfde voor menu's.

Op weg naar toegankelijkheid

Eigenlijk worden hier niet alleen rollen toegevoegd, maar ook gebeurtenishandlers voor navigatie met het toetsenbord.

Het ziet er al een stuk netter uit. Als we een duidelijke scheiding tussen hen zouden kunnen krijgen, zou het niet uitmaken hoe de structuur is gemaakt; we zouden er gedragingen op kunnen toepassen en de juiste toegankelijkheid kunnen verkrijgen.

Dit kan in de praktijk worden gezien op https://stardust-ui.github.io/react/ – de UX-bibliotheek React, die vanaf het begin is ontworpen en gerealiseerd met toegankelijkheid in gedachten.

Het tweede deel – het veranderen van de benadering en processen rondom het ontwerp – maakte me aanvankelijk bang: bescheiden ingenieurs die pogingen doen om organisatorische veranderingen door te voeren, eindigt niet altijd goed, maar het bleek een van de meest interessante gebieden te zijn waar we een aanzienlijke bijdrage hebben geleverd aan het proces. Kort samengevat hadden we het volgende proces: nieuwe functionaliteit werd ontwikkeld door ƩƩn team, daarna analyseerde/onze groep leidinggevenden het voorstel en iteraties, en na goedkeuring werd het ontwerp meestal aan het engineeringteam overgedragen. In dit geval had het engineeringteam feitelijk de 'eigendom' van de toegankelijkheidsfunctionaliteit, aangezien ze alle bijbehorende problemen moesten oplossen.

In het begin was het vrij moeilijk om uit te leggen dat toegankelijkheid en gebruiksvriendelijkheid onlosmakelijk met elkaar verbonden zijn en dat dit al in de ontwerpfase moet worden aangepakt, anders leidt dit tot grote wijzigingen en herschikkingen van bepaalde rollen. Met de steun van het management en belangrijke spelers hebben we dit idee overgebracht en in gang gezet, zodat ontwerpen werden gecontroleerd op toegankelijkheid en gebruiksvriendelijkheid voordat ze aan het management werden gepresenteerd.

En deze feedback was buitengewoon waardevol voor iedereen – het was fantastisch, als een oefening in kennisdeling/informatieoverdracht over hoe gebruikers met webapplicaties omgaan. We hebben talrijke knelpunten in de gebruikersinterface geĆÆdentificeerd voordat ze werden gebouwd. De ontwikkelteams hebben nu veel betere specificaties, niet alleen voor de visuele, maar ook voor de gedragsaspecten van het ontwerp. Echte discussies zijn leuke, energieke, gepassioneerde debatten over technische aspecten en interacties.

We zouden dit werk nog beter kunnen doen als er blinde gebruikers en gebruikers met beperkingen bij deze (of volgende) vergaderingen waren geweest – dat was moeilijk te organiseren, maar nu werken we daadwerkelijk samen met lokale organisaties voor blinden en bedrijven die extern testen voor het controleren van de user flow in de vroege ontwikkelingsfasen – zowel op componentniveau als op het niveau van de user flow.

Nu hebben ingenieurs vrij gedetailleerde specificaties en beschikbare componenten die ze kunnen gebruiken voor implementatie, evenals een manier om de user flow te controleren. De ervaring heeft ons deels geleerd wat we voortdurend over het hoofd zagen – hoe we regressie kunnen voorkomen. Evenzo kunnen mensen integratietests of end-to-end tests gebruiken om functionaliteit te controleren, wat we nodig hebben om veranderingen in interacties en user flows te detecteren – zowel visueel als gedragsmatig.

De definitie van visuele regressie is een vrij specifieke taak, er valt weinig aan dit proces toe te voegen, behalve mogelijk de controle of de focus zichtbaar is bij navigatie via het toetsenbord. Twee relatief nieuwe technologieƫn voor toegankelijkheid zijn interessanter.

  1. Accessibility Insights is een verzameling tools die in zowel de browser als binnen de build/testcyclus kunnen worden uitgevoerd om problemen te identificeren.
  2. Het testen van de werking van schermlezers was een bijzonder uitdagende taak. Met de introductie van toegang tot Accessibility DOM, hebben we eindelijk de mogelijkheid om snapshots van de applicatie vanuit het perspectief van toegankelijkheid te maken, die zeer vergelijkbaar zijn met hoe we deze maken voor visuele tests, en ze te controleren op regressie.

Dus, in het tweede deel van het verhaal – we zijn overgestapt van het bewerken van HTML-code naar werken op een hoger abstractieniveau, hebben het ontwerpproces veranderd en uitvoerige tests ingevoerd. Nieuwe processen, nieuwe technologieĆ«n en nieuwe abstractieniveaus hebben het begrip van toegankelijkheid en wat het betekent om in dit domein te werken volledig veranderd.
Maar dit is pas het begin.

Het volgende ā€˜begrip’ is dat blinde gebruikers voorop lopen in de technologie – juist zij profiteren het meest, niet alleen van de eerder beschreven veranderingen, maar ook van het feit dat nieuwe benaderingen en ideeĆ«n mogelijk worden gemaakt door ML/AI. Bijvoorbeeld, de technologie Immersive Reader stelt gebruikers in staat om tekst eenvoudiger en duidelijker te begrijpen. Het kan hardop worden voorgelezen, de structuur van zinnen wordt grammaticaal gesplitst en zelfs de betekenissen van woorden worden grafisch weergegeven. Dit valt absoluut niet binnen het oude begrip van ā€˜het toegankelijk maken’ – het is een gebruiksvriendelijkheidfunctie die iedereen helpt.

Met ML/AI verschijnen er totaal nieuwe manieren van interactie en werken, en we zijn blij deel uit te maken van de volgende stappen op dit voorhoede-pad. Innovatie komt voort uit een verandering in denken – de mensheid bestaat al duizenden jaren, machines honderden jaren, websites enkele tientallen jaren, en smartphones nog minder, technologie moet zich aanpassen aan mensen en niet andersom.

P.S. Het artikel is met kleine afwijkingen van het origineel vertaald. Als co-auteur van dit artikel heb ik deze afwijkingen met Hugh afgestemd.

Alleen geregistreerde gebruikers kunnen deelnemen aan de enquĆŖte. Log in, alstublieft.

Besteedt u aandacht aan de toegankelijkheid van uw applicaties?

  • Yes

  • No

  • Ik hoor voor het eerst over de toegankelijkheid van applicaties.

17 gebruikers hebben gestemd. 5 gebruikers hebben zich onthouden.

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers šŸ”„ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster