Zo maak je je website en app toegankelijk voor mensen met een visuele beperking

Hoe maak je een website of app toegankelijk voor mensen met een visuele beperking? En hoe weet je dat blinden en slechtzienden je digitale product drempelvrij kunnen gebruiken? Voor ons als developers is het een uitdaging om producten te optimaliseren voor deze doelgroep. Vooral ook omdat we de producten die we bouwen zélf nooit ervaren met beperkt of helemaal geen zicht.

Bij Q42 zien we accessibility echt als onderdeel van productontwikkeling, zoals ik in een eerdere blogpost heb uitgelegd. Dus nodigden we onlangs een groep blinde en slechtziende gebruikers uit voor een toegankelijkheidstest van onze apps en websites. In dit artikel vertel ik meer over de opzet van deze test om vervolgens onze tips te delen voor een toegankelijke website en app.

Richtlijnen
Er zijn natuurlijk al richtlijnen voor webtoegankelijkheid zoals de WCAG 2.1. Zolang je dergelijke internationale standaarden volgt, zit je goed, zou je denken. Totdat je ontdekt, dat de richtlijnen maar een deel van het verhaal vormen. Als je ze exact volgt, weet je namelijk nog steeds niet of het product een prettige gebruikservaring oplevert voor iemand met een visuele handicap. Sterker nog: ze belemmeren je om je in te leven in een groot deel van je doelgroep.

Dat is precies wat ik mij jaren geleden besefte, toen ik aan een website werkte waarmee je je reis kon plannen met het openbaar vervoer. Ik legde een reisadvies, dat net het stempel toegankelijk had gekregen, voor aan een vriend die blind is. Hij kon er helemaal niks mee. Het reisadvies werd voorgelezen in fragmenten, omdat ieder deel in een aparte stukje code stond. Alhoewel technisch helemaal valide en toegankelijk was het moeilijk te volgen als het reisadvies werd voorgelezen door een schermlezer. Ik heb alles opnieuw gebouwd om ervoor te zorgen dat het werd voorgelezen in begrijpelijke volzinnen.

Maar hoe kun je die ervaring dan optimaliseren als je geen idee hebt hoe iemand je product ervaart? Door mensen te bevragen terwijl ze interactie hebben met jouw product. Door ze te zien slagen en falen, terwijl ze het gebruiken.

Usabilitytest met blinden en slechtzienden
Sinds een jaar organiseren we bij Q42 iedere twee maanden een testochtend, de Real User Morning, waarin we ons eigen werk voorleggen aan gebruikers. Over de opzet van deze usabilitytest schreven we al eerder een uitgebreide blogpost. Kort samengevat: we houden een soort speeddate met vijf eindgebruikers die ieder vijf projecten testen. Zo is het mogelijk om op een laagdrempelige manier snel inzicht te krijgen hoe mensen ervaren wat wij maken én onze aannames te valideren.

Deze methode besloten we ook in te zetten voor een usabilitytest met blinden en slechtzienden. Accessibility is echter niet alleen een téchnische kwestie. Wij als developers moeten hierin onze verantwoordelijkheid nemen, maar ontwerpers ook. Daarom hebben we deze testochtend georganiseerd met designbureau Fabrique, waarmee we in meerdere projecten samenwerken.

Ook op andere vlakken was deze Real User Morning net iets anders dan gewoonlijk:

• Waar we doorgaans respondenten werven via een extern bureau, hadden we dit keer snel zelf een groep van zes testers bijeen. Omdat deze testpersonen in dit geval niet allemaal zelfstandig hun weg zouden kunnen vinden, hadden we een aantal mensen bereid gevonden om hen te begeleiden naar en in onze locatie.
• We hebben dit keer gevraagd of testers hun eigen devices mee wilden nemen. Eerdere tests met blinde en slechtziende gebruikers hadden ons geleerd dat dat het beste werkt. Mensen met een visuele beperking gebruiken namelijk veel verschillende instellingen. Om die te reproduceren op een apart testdevice kost veel tijd. Bovendien wordt de test onzuiver, omdat respondenten dan vooral bezig zijn hun weg te vinden op het apparaat en niet met het product dat je eigenlijk wilt testen.
• Ook was er extra tijd ingeruimd om apps op de meegebrachte devices te installeren. Zo konden de zes testers zich echt focussen op het gebruiken van onze producten.
• Voor sommige ontwerpers en ontwikkelaars zou het de eerste keer zijn, dat ze blinden en slechtzienden hun werk zouden zien gebruiken. Daarom besloten we om dit keer per test meer tijd te nemen: dertig in plaats van vijftien minuten. Dat bood ook de mogelijkheid om door te vragen en meer inzicht te krijgen in de ervaring van de testpersoon.

De usabilitytest leidde tot een aantal interessante bevindingen. Hieronder zet ik de belangrijkste op een rijtje, inclusief tips over hoe je met toegankelijkheid rekening houdt als je een app of website ontwikkelt.

1. Zoveel mensen, zoveel wensen
Het idee dat iedereen met een visuele beperking dezelfde ervaring heeft, moesten we heel snel loslaten. Iedere testpersoon gebruikte zijn of haar eigen voorkeursplatform, -software en -instellingen. De één prefereerde een iPad met VoiceOver, de ander Window met Jaws en Zoomtext. Terwijl weer een ander de voorkeur gaf aan de schermlezer en -vergroter Supernova. Alhoewel één respondent een uitgesproken voorkeur had voor Android, was iPhone qua gebruik de overall winnaar onder de testers.

Een reden voor deze verscheidenheid is de hoeveelheid oogaandoeningen. Elke aandoening heeft zo zijn eigen complicaties en gevolgen die leiden tot verschillende instellingen en voorkeuren in schermgebruik.

Blind zijn betekent dat iemand niet of minder ziet dan 5% of dat het gezichtsveld is beperkt tot minder dan 10 graden. Blind zijn houdt dus niet altijd in dat iemand helemaal niets meer ziet. Sommige mensen zien nog wel het verschil tussen licht en donker. (Visio)

In sommige gevallen kan iemand die slechtziend is het scherm nog in zijn geheel overzien, maar zijn de details niet of nauwelijks meer te onderscheiden. In ander gevallen is het zichtveld beperkt en ziet iemand alleen nog delen van het scherm.

Sowieso moet het duidelijk zijn waar iemand naar zit te kijken. Het is dus belangrijk dat alle visuele elementen een tekstueel alternatief hebben. Zo kan iemand gesproken feedback krijgen over wat er op het scherm staat. (Zie punten 5 en 6.)

2. Responsive is king
Alle slechtzienden maakten gebruik van de zoomfunctionaliteit op hun device. Op iPhone en iPad werd gebruikgemaakt van de reeds aanwezige functionaliteit hiervoor. Op computers zagen we echter veel verschillende manieren: Supernova, Zoomtext, maar ook de zoomfunctie van de browser werd gebruikt.

Websites waarbij goed was nagedacht over responsive gedrag bleken zich prima staande te houden als gebruik wordt gemaakt van de browsers zoomfunctionaliteit. Een goede responsive site voorkomt namelijk dat er horizontale scrollbars worden getoond, waardoor iemand zowel horizontaal als verticaal moet scrollen om te lezen.

Testers maakten dus ook gebruik van hulptechnologie die inzoomt op bepaalde onderdelen van het scherm. Doordat slechts kleine delen van de website zichtbaar zijn, is het onoverkomelijk dat een gebruiker horizontaal en verticaal moet scrollen. Voor iemand die op deze manier jouw website gebruikt zijn een consistente navigatiestructuur en bekende patronen heel belangrijk. (Zie ook punt 8.) Zonder die zekerheden kan iemand eindeloos blijven zoeken naar houvast.

Houd er bij het ontwikkelen van een website en mobiele app dus rekening mee, dat mensen gebruik kunnen maken van de door het systeem geboden zoomfunctionaliteit. Ondersteun de mogelijkheid voor een gebruiker om tekst te vergroten in een iOS- of Android-app en zorg dat je website responsive is.

3. Contrast
Goed onderscheid kunnen maken tussen elementen op het scherm door middel van voldoende contrast is niet alleen belangrijk voor mensen die kleurenblind zijn. Voor iemand die alleen nog vormen kan onderscheiden is het van minstens zo groot belang dat het duidelijk is waar een vorm begint en waar die eindigt.

Zorg er daarom voor dat de belangrijke elementen op een scherm duidelijk van elkaar te onderscheiden zijn door gebruik te maken van voldoende contrast.

4. Ondersteun dark mode
Slechtziendheid gaat vaak gepaard met een overgevoeligheid voor licht. Je kunt je vast voorstellen dat het in dat geval niet fijn is om naar tekst op een grote witte pagina te moeten kijken. Daarom willen slechtziende gebruikers de mogelijkheid hebben hun scherm donkerder te maken. In veel van de gebruikte toepassingen zoals Supernova en ZoomText wordt een optie aangeboden om de kleuren op het scherm om te draaien. Wit wordt dan zwart en vice versa. Dit heeft echter ook gevolgen voor afbeeldingen en video’s: deze worden in negatief getoond.

Door dark mode te ondersteunen kun je gebruikers een betere, custom-made ervaring bieden. Voor websites kun je dat doen door een aparte stylesheet te maken waarmee de toepassing er perfect uit blijft zien. Een iOS-app biedt hier al ondersteuning voor, zolang je gebruikmaakt van de standaard Views en Controls. Voor Android-apps kun je dat ook doen, zoals Q’er Frank in een eerdere blogpost heeft uitgelegd.

5. Tekst in plaats van beeld
Voor gebruik met screenreaders is het belangrijk dat alle visuele content ook een tekstvariant of equivalent heeft. Dat geldt voor onderdelen in de interface die puur grafisch worden weergegeven, zoals iconen. Maar zeker ook voor afbeeldingen.

De regel dat een decoratieve afbeelding moet worden verborgen, bijvoorbeeld door het leeg laten van het alt-attribuut, gaat voor gebruikers met een visuele beperking zeker niet altijd op. Zo worden grote afbeeldingen bij een artikel wel degelijk waargenomen door slechtzienden. Door het leeg laten van een alt-attribuut krijgen ze geen enkele feedback over het deel van het scherm waar ze naar zitten te kijken.

Zorg er dus voor dat afbeeldingen altijd beschrijvingen hebben die hardop voorgelezen kunnen worden door schermlezers.

6. Labels, labels, labels
Omdat tekst het belangrijkste en soms het enige ankerpunt is voor een gebruiker, is het van belang dat je niet alleen naar het ontwerp kíjkt maar ook luístert. Zo voorkom je een interface vol met acties als “Klik hier om verder te gaan”. Maak dus labels en links waaruit iemand kan afleiden, wat het gevolg zal zijn van een klik of tap.

7. Poetsen of vegen
Mensen gebruiken schermlezers op twee manieren: ze poetsen of ze vegen. Vegen houdt in dat iemand een vegende beweging maakt om de focus op het scherm te verplaatsen. Poetsen is het aftasten van het scherm met een vinger op zoek naar audiofeedback voor de onderliggende elementen.

Je zou verwachten dat poetsen dé manier is om te ontdekken waar je precies naar zit te kijken, als je slechtziend bent en op het scherm nog iets kunt onderscheiden. Door een combinatie van spraak en zicht ontdek je namelijk al poetsend, wat die vormen onder je vinger precies betekenen.

Op basis van eerdere ervaringen uit gebruikstesten was ik altijd in de veronderstelling dat slechtzienden poetsen en blinden vegen. Tijdens de test bleek ook dit geen gouden regel te zijn maar afhankelijk van persoonlijke voorkeuren. Dat betekent dat je voor beide manieren van interactie moet optimaliseren. Wat dat precies betekent, leg ik hierna verder uit.

8. Semantiek en patronen
De manier waarop iemand door je app of website gaat, heeft ook gevolgen voor de beleving. Bij het vegen is de volgorde waarin zaken worden aangeboden heel belangrijk. Zorg daarom dat de semantiek op orde is en dat de hiërarchische structuur klopt: wat iemand als eerste zou moeten tegenkomen, krijgt dan ook daadwerkelijk als eerst de focus. Dus zet het belangrijkste altijd bovenaan. Niet alleen visueel maar ook in je code.

Bij het poetsen tast iemand het scherm af op zoek naar ankerpunten. Hiervoor is het van groot belang dat gebruikgemaakt wordt van herkenbare patronen. Voorbeeld: in een iOS-app wordt de back / terug-functie linksboven verwacht en instellingen worden vaak rechtsboven of in een tabbar onderin gezocht.

Voor zowel website als app is het belangrijk dat je gebruikmaakt van bestaande interactiepatronen. Als er een gegronde reden is om hiervan af te wijken, dan is het zaak dat je dat goed uitlegt. Zorg er ook voor dat je navigatiestructuur consistent is en maak voor een app zoveel mogelijk gebruik van de bestaande componenten. Maar vooral: houd het simpel. Hoe meer lagen je aanbiedt in je navigatie, des te groter de kans dat iemand verdwaalt.

9. Vermijd verrassingen
Zodra er iets verandert op je scherm of in een app, kun je dat zien. Maar, je voelt ‘m vast al aankomen: hoe weet je dat als je die verandering niet kunt waarnemen? Iedere pop-up of schermwisseling is in potentie het moment waarop iemand met een visuele beperking in verwarring raakt - en je website of app verlaat. Ineens verandert alles onder haar vingers en ze heeft geen idee waarom.

Daarom is het van groot belang dat je veranderingen expliciet meldt. Zolang je de standaarden volgt, is dat geen probleem. Maak dus op iOS en Android zoveel mogelijk gebruik van de componenten die het systeem je biedt als ontwikkelaar.

Op het web ligt dat tegenwoordig iets complexer. Het openen van een nieuwe pagina wordt door screenreaders altijd aangekondigd met een geluid. Er worden echter steeds minder websites gebouwd waar je doorheen navigeert door middel van het openen van nieuwe pagina’s. Met het groeien van de hoeveelheid JavaScript-toepassingen zijn page refreshes vervangen door single page interfaces waarin content dynamisch wordt geladen. In het zicht maar uit het gehoor dus.

Een typisch voorbeeld van content die je vaak wel kunt zien maar niet kunt horen, zijn foutmeldingen in formulieren. Een gebruiker met een schermlezer moet daar duidelijke feedback over krijgen, zoals dit voorbeeld laat zien.

Zorg er in het geval van dynamisch geladen content dus altijd voor, dat een gebruiker kan horen dat er iets verandert en verplaats als het even kan de focus naar die verandering. Dat neemt heel wat websitehindernissen weg.

Veranderingen vinden echter ook op een ander niveau plaats, namelijk in de vorm van app-updates. Het is dus van belang dat je ook díe veranderingen goed aangeeft. Bijvoorbeeld bij de eerste keer opstarten van de app na een update en door het duidelijk aan te geven in de release notes.

Tot slot
Denk niet na het lezen van deze tips: ik weet genoeg. Je product onderwerpen aan een toegankelijkheidscheck met blinde en slechtziende gebruikers is slechts het begin om digitale barrières voor hen weg te nemen. Ik daag je daarom uit om zélf dit soort accessibility reviews te gaan doen en je inzichten te delen (mail me vooral!), zodat we samen wijzer worden en een beter beeld krijgen van wat toegankelijkheid echt betekent.

Bedankt
Deze editie van onze testochtend werd mede mogelijk gemaakt door de inzet van Wendy Steffens van Fabrique. Samen zetten we ons al geruime tijd in voor toegankelijkheid binnen onze projecten. We voelden allebei de noodzaak om deze usabilitytest gezamenlijk te organiseren. Wendy zette eveneens haar bevindingen op papier in dit Engelstalige artikel.

Dankzij het netwerk van Cathelijne Denekamp van het Rijksmuseum hadden we heel snel een testpanel samengesteld. Dank daarvoor en voor alles wat je doet om het museum toegankelijker te maken.

Dit verhaal was er niet geweest zonder de hulp van mijn collega Maurice Haak. Bedankt voor jouw geduld en jouw gave om mijn gedachtenbrei om te zetten in iets leesbaars.