{"id":38463,"date":"2019-10-31T22:23:52","date_gmt":"2019-10-31T19:23:52","guid":{"rendered":"https:\/\/prohoster.info\/blog\/po-napravleniyu-k-dostupnosti\/"},"modified":"2019-10-31T22:23:52","modified_gmt":"2019-10-31T19:23:52","slug":"po-napravleniyu-k-dostupnosti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/po-napravleniyu-k-dostupnosti","title":{"rendered":"Op weg naar toegankelijkheid","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Op
\n
\nVrijdag is het einde van de werkdag. Slecht nieuws komt altijd op vrijdag tegen het einde van de werkdag.<\/p>\n

Je staat op het punt het kantoor te verlaten, en dan \u2018ping\u2019 \u2013 een nieuwe e-mail over weer een reorganisatie komt net binnen.<\/p>\n

Bedankt xxxx, yyy, vanaf vandaag rapporteer je aan zzzz.
\n\u2026
\nEn het team van Hugh zal de beschikbaarheid van onze producten voor mensen met een beperking waarborgen.<\/i>\n<\/p><\/blockquote>\n

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...<\/p>\n

Zo was de toegankelijkheid enkele jaren geleden. Sommige arme mensen kregen de taak om de gebruikersinterface \u2018schoon\u2019 te maken in een poging deze toegankelijk te maken voor mensen met een beperking.
\n<\/a><\/noindex>
\nWat dit daadwerkelijk betekende, was vrij vaag \u2013 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...<\/p>\n

Maar plotseling begonnen \u2018bugs\u2019 zich als een lawine te vermenigvuldigen.<\/p>\n

Verschillende schermlezers (Engels.<\/i> Screen Readers) en browsers gedroegen zich volkomen anders.<\/p>\n

Gebruikers klaagden dat de applicatie onbruikbaar was.<\/p>\n

Zodra een fout op de ene plaats werd opgelost, verscheen er een andere op een andere plaats.<\/p>\n

En simpelweg het wijzigen en corrigeren van fouten in de gebruikersinterface vereiste titanenarbeid.<\/p>\n

Ik was daar. Ik heb het overleefd, maar we hebben niet \u2018gepresteerd\u2019 \u2013 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\u00ebnteren in de applicatie. De manager klaagde nog steeds over een constante stroom van fouten. Ingenieurs klaagden over onduidelijke opdrachtgevers zonder een eenduidige \u2018juiste\u2019 oplossing die in alle gevallen werkte.<\/p>\n

Op mijn weg naar begrip van toegankelijkheid kwam ik enkele blijkbaar onthullende momenten tegen.
\nMisschien 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.
\nMijn 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.<\/p>\n

Ik zal hier steeds op terugkomen, maar bijna al onze 'veronderstellingen' over hoe mensen onze applicatie gebruikten, waren verkeerd.<\/p>\n

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

Verlies van focus bij het wijzigen van de gebruikersinterface is toch geen groot probleem? Laten we daar nog eens over nadenken \u2013 het is waanzinnig verwarrend.<\/p>\n

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.<\/p>\n

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!<\/p>\n

Al snel kwamen we tot enkele conclusies:<\/p>\n

    \n
  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.<\/li>\n
  2. Toegankelijkheid == Bruikbaarheid \u2013 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\u00f3\u00f3r het ontwerp van de gebruikersinterface. We moeten van tevoren nadenken over hoe gebruikers functionaliteit kunnen ontdekken, hoe ze zich zullen verplaatsen en hoe de \u2018rechter muisklik\u2019 met het toetsenbord zal werken. Toegankelijkheid moet een integraal onderdeel van het ontwerpproces zijn \u2013 voor sommige gebruikers is het veel meer dan alleen de uitstraling van de applicatie.<\/li>\n
  3. Vanaf het begin wilden we feedback krijgen van blinde en andere gebruikers met een beperking over de gebruiksvriendelijkheid van de applicatie.<\/li>\n
  4. We hadden echt goede manieren nodig om regressie in toegankelijkheid te detecteren.<\/li>\n<\/ol>\n

    \nNou, vanuit een technisch perspectief klonk het eerste deel behoorlijk leuk \u2013 het ontwikkelen van de architectuur en het implementeren van de componentenbibliotheek. En dat was het ook echt.<\/p>\n

    Terugkijkend op de ARIA-voorbeelden<\/a><\/noindex> En dit als een ontwerpprobleem beschouwend in plaats van een kwestie van \"aanpassen\", hebben we bepaalde abstracties ge\u00efntroduceerd. Het component heeft een 'Structuur' (bestaande uit HTML-elementen) en 'Gedrag' (hoe het met de gebruiker interacteert). In de onderstaande fragmenten hebben we bijvoorbeeld een eenvoudige ongeordende lijst. Bij het toevoegen van 'gedrag' aan de lijst worden de bijbehorende rollen toegevoegd zodat het functioneert als een lijst. Op een vergelijkbare manier doen we dat voor het menu.<\/p>\n

    \"Op
    \n
    \nEigenlijk worden hier niet alleen rollen toegevoegd, maar ook gebeurtenishandlers voor navigatie met het toetsenbord.<\/p>\n

    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.<\/p>\n

    Dit kan in de praktijk worden gezien op https:\/\/stardust-ui.github.io\/react\/<\/a><\/noindex> \u2013 de UX-bibliotheek React<\/a><\/noindex>, die vanaf het begin is ontworpen en gerealiseerd met toegankelijkheid in gedachten.<\/p>\n

    Het tweede deel \u2013 het veranderen van de benadering en processen rondom het ontwerp \u2013 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 \u00e9\u00e9n 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.<\/p>\n

    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.<\/p>\n

    En deze feedback was buitengewoon waardevol voor iedereen \u2013 het was fantastisch, als een oefening in kennisdeling\/informatieoverdracht over hoe gebruikers met webapplicaties omgaan. We hebben talrijke knelpunten in de gebruikersinterface ge\u00efdentificeerd 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.<\/p>\n

    We zouden dit werk nog beter kunnen doen als er blinde gebruikers en gebruikers met beperkingen bij deze (of volgende) vergaderingen waren geweest \u2013 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 \u2013 zowel op componentniveau als op het niveau van de user flow.<\/p>\n

    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 \u2013 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 \u2013 zowel visueel als gedragsmatig.<\/p>\n

    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\u00ebn voor toegankelijkheid zijn interessanter.<\/p>\n

      \n
    1. Accessibility Insights<\/a><\/noindex> is een verzameling tools die in zowel de browser als binnen de build\/testcyclus kunnen worden uitgevoerd om problemen te identificeren.<\/li>\n
    2. Het testen van de werking van schermlezers was een bijzonder uitdagende taak. Met de introductie van toegang tot Accessibility DOM<\/b>, 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.<\/li>\n<\/ol>\n

      \nDus, in het tweede deel van het verhaal \u2013 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\u00ebn en nieuwe abstractieniveaus hebben het begrip van toegankelijkheid en wat het betekent om in dit domein te werken volledig veranderd.
      \nMaar dit is pas het begin.<\/p>\n

      Het volgende \u2018begrip\u2019 is dat blinde gebruikers voorop lopen in de technologie \u2013 juist zij profiteren het meest, niet alleen van de eerder beschreven veranderingen, maar ook van het feit dat nieuwe benaderingen en idee\u00ebn 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 \u2018het toegankelijk maken\u2019 \u2013 het is een gebruiksvriendelijkheidfunctie die iedereen helpt.<\/p>\n

      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 \u2013 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>\n

      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.<\/p>\n

      Alleen geregistreerde gebruikers kunnen deelnemen aan de enqu\u00eate. Log in<\/a><\/noindex>, alstublieft.<\/p>\n

      Besteedt u aandacht aan de toegankelijkheid van uw applicaties?<\/h2>\n