
We hebben recentelijk de nieuwe website van DirectVPS, onze eigen host, mogen maken. Tegen de tijd dat we de eerste versies begonnen te testen, deden we de gebruikelijke “iets meer witruimte hier”, “tóch iets donkerder daar” en “niets werkt in Internet Explorer” aanpassingen. Er kwamen echter ook enorm veel, voor ons vreemde, problemen naar boven die te maken hadden met de toegankelijkheid van de website. Ze kwamen, zoals de titel van dit artikel waarschijnlijk al heeft weg gegeven, van een contactpersoon bij DirectVPS met een beperking: blindheid.
70 procent van de websites is niet toegankelijk voor slechtzienden, en deze website was er deel van geweest als we niet op de hoogte waren gesteld van de fouten die erin zaten. De aanpassingen die ik daarentegen moest doen, hebben naast het uitzoekwerk de beste moeite/resultaat verhouding die ik ooit ben tegengekomen. Daarom bespaar ik je met dit artikel die tijd en behandel ik drie cruciale punten die je website met enkele minuten werk toegankelijk(er) maken voor slechtzienden.
“Ik kan het menu niet openen” – 7 minuten werk
“Ik kan het menu niet openen”, is wat onze contactpersoon, Ruud, op een gegeven moment zei. Zoals op de meeste websites, verdwijnt het menu achter een hamburgerknop wanneer het scherm zo breed is dat de normale navigatiebalk niet meer in beeld past. Alleen wist Ruud het menu maar niet naar voren te toveren.
Ik kon met m’n muis zo naar de knop toe, erop klikken, en het menu openen. Ruud niet. Wat ging er fout? De knop was voor Ruud geen knop, maar een simpel stukje tekst: ☰, het Taoïstische trigram voor ‘hemel’. Niet bepaald bruikbaar…
Takeaway
Knoppen zijn vaak te gebruiken met de muis, omdat dit ingebouwd zit in de browser of omdat de klikevenementen worden afgehandeld met JavaScript. Echter, wanneer je de muis uit de formule haalt, wordt navigeren op de meeste website nagenoeg onmogelijk.
Wat moet je doen? Heel simpel: kijk bij het testen van de website altijd of je alles kunt doen wat je moet kunnen doen, als je je muis niet kunt gebruiken. Haal hem er letterlijk uit en zie hoe ver je komt.
“Wanneer het menu open is, leest hij nog steeds de hele pagina voor” – 1 minuut werk (ja, echt)
Nadat we de hamburgerknop bruikbaar hadden gemaakt voor Ruud, kwam al snel een volgend probleem naar voren: wanneer het hamburgermenu geopend was, en de screenreader de linkjes voor ging lezen, las hij daarna nog steeds de hele pagina voor.
Takeaway
Het probleem hier was ongeveer het tegenovergestelde van het vorige. Een element dat visueel verborgen was, werd nog wel geregistreerd door de screenreader vanwege de techniek die werd gebruikt. Een kleine aanpassing was genoeg om dit te fixen. Naast ons specifieke geval, is het natuurlijk belangrijk dat een developer altijd nadenkt over zijn methode om elementen te verbergen. Het is niet bepaald wenselijk dat je screenreader alle pop-ups en modals van de pagina gaat voorlezen.
“De namen van de plaatjes worden niet voorgelezen” – 4 minuten werk
Iedereen weet dat plaatjes op het web altijd een alt
attribuut moeten hebben, zodat zoekmachines weten wat voor plaatjes je op de website hebt staan. Dat er geen inhoudelijke informatie wordt ingevuld is niet heel uitzonderlijk. Bij ons werd er echter niets voorgelezen, omdat we plaatjes op een andere manier inladen dan de meesten. Ik kwam erachter dat extra informatie geven aan slechtzienden wat omslachtiger kan zijn dan normaal.
Takeaway
Het kan heel frustrerend zijn voor slechtzienden als ze op een website zijn die heel visueel is, en dan constant dingen als “afbeelding 20”, “256×256”, “jRc8A52P0” of helemaal niets horen. Hou er daarom rekening mee dat het alt
attribuut logisch ingevuld wordt en dat alt
attribuut alleen werkt op plaatjes en een paar andere, meer zeldzame, elementen. Het title
attribuut wordt vaak door screenreaders genegeerd, ook al is het een attribuut dat universeel toepasbaar zou moeten zijn. Om extra informatie voorgelezen te laten worden door screenreaders, moet dus altijd even getest worden of dat gebeurt met een screenreader. Vindt Google ook fijn, als het weet wat je wilt zeggen ?.

Tot slot
Sommige webbureaus (die nooit hebben gehoord van services zoals BrowserStack) hebben een test-suite, gemaakt van rijen aan Apple-, Windows- en Android-apparaten, waar ze hun werk direct op kunnen testen. Het is tijd dat aan die gigantische rij een extra test-case toegevoegd wordt: eentje van een computer zonder scherm, zonder muis en met een screenreader aan. Rekening houden met slechtzienden is niet moeilijk, maar je moet je maar net bewust zijn van de problemen. Waar sommige bureaus uren en uren extra tijd stoppen in het ondersteunen van mensen die JavaScript hebben uitgeschakeld (iets minder dan 1 procent), kun je met enkele minuten werk slechtzienden (iets meer dan 1 procent) ondersteunen. Je hoeft geen wiskundige te zijn om in te zien dat het logischer is om de laatste van die twee te prioriteren. En natuurlijk, naast de bezoekerstoename, help je tevens een groep mensen die gewend is dat het merendeel van de websites die ze bezoeken niet toegankelijk is. Meer conversie én moreel verantwoord; dat zijn twee hele dikke vliegen voor één klap.