Blog

Gust van de Wal

Gust van de Wal

8 april 2019 Toegankelijkheid

Slechtzienden ondersteunen: twee vliegen in één klap!

Een surfende blinde man 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 trigram voor ‘hemel’ in het Chinees. Niet bepaald bruikbaar…

De oplossing (voor developers)

De hamburgerknop maken wij altijd met een label-checkbox-combi zodat we geen JavaScript hoeven te gebruiken voor het openen en sluiten van het hamburgermenu. De hamburgerknop zelf is het label en de checkbox staat als eerste element in de body, zodat ik met sibling selectors (+ en ~) het uiterlijk van het document kan aanpassen. Leuk en aardig, maar een label is klikbaar maar niet te selecteren met het toetsenbord. Ik probeerde allerlei trucjes om dit voor elkaar te krijgen zonder JavaScript, maar niets wilde lukken. Na meer zoekopdrachten dan ik toe zou willen geven, werd de oplossing me ineens duidelijk. Het enige dat ik hoefde te doen, was gebruik te maken van het checkbox zelf. checkboxes zijn namelijk wél te selecteren en activeren met het toetsenbord.

Voorheen maakte ik het element verborgen met display: none;. Dit heb ik aangepast naar opacity: 0; position: fixed; z-index: -1;. Met die styles is het element selecteerbaar en alsnog onzichtbaar. Ik heb vervolgens alle elementen die voor de hamburgerknop komen een tabindex="1" en de checkbox een tabindex="2". Op die manier wordt de selectievolgorde gewaarborgd die je verwacht wanneer je Tab gebruikt.

Dit voorbeeld gaat natuurlijk over onze specifieke aanpak. Als op jouw website een simpele div wordt gebruikt als hamburgerknop, verander het dan in een button. buttons triggeren ook een onclick-event, wanneer ze met Space of Enter worden gebruikt en zijn native selecteerbaar met het toetsenbord.

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.

De oplossing (voor developers)

Wederom, vanwege onze aanpak om op z’n minst de navigatie zonder JavaScript te laten werken, fixte ik dit door andere styles toe te passen. Wanneer het menu opengeklapt was, gaf ik de main content van de pagina simpelweg position: absolute; height: 100vh; overflow: hidden; (na veel geëxperimenteer door de jaren heen, was ik bij die aanpak aanbeland. Het had waarschijnlijk iets met de scrollbalk te maken). De navigatie hing ik erboven met een z-index: 1; en de klus leek klaar. Maar zoals ik bij het vorige probleem heb uitgelegd, moet je met screenreaders in je achterhoofd dingen verbergen. Ik verving de styles met display: none; en het werd niet meer voorgelezen.

Als je geen rekening hoeft te houden met mensen die JavaScript uitgeschakeld hebben, kun je simpelweg aria-hidden=”true” toevoegen aan de elementen die niet geregistreerd moeten worden door screenreaders. Heel veel korter en simpeler.

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 blinden wat omslachtiger kan zijn dan normaal.

De oplossing (voor developers)

Alle graphics die geen foto’s zijn van het echte leven, proberen wij als vector bestanden te importeren. Denk daarbij aan dingen als het logo en social media iconen.

De voordelen zijn schaalbaarheid, bestandsgrootte en snelheid. Die snelheid zit hem in het feit dat we de vector graphics exporteren als SVG bestand, wat een xml structuur heeft die je letterlijk kunt knippen en plakken in HTML. Op die manier kunnen we het gewoon in de body stoppen en hoeven er geen extra requests te worden gedaan.

<svg viewBox="0 0 98 85">
    <path fill="red" d="M49,85C64,75,98,55,98,25C98,13,89,0,75,0S52,9,49,19C46,9,37,0,23,0S0,13,0,25C0,55,34,75,49,85z" />
</svg>

Het nadeel hiervan is dat het niet meer een img tag is, maar een svg. Een alt attribuut kon dus niet meer gebruikt worden. “title dan maar,” dacht ik bij mezelf. Maar ook dat mocht niet baten. Ruud kreeg de namen van de plaatjes niet te horen.

Het is omslachtig, maar om er zeker van te zijn dat iets door een screenreader wordt gelezen, moet je het aria-labelledby=”foo” attribuut gebruiken, in combinatie met een element met id=”foo” met daarin de tekst die voorgelezen moet worden. Zoals we dat in ons geval hebben gedaan ziet er zo uit:

<svg viewBox="0 0 98 85" aria-labelledby=”redhearttitle”>
    <title id=”redhearttitle”>Een rood hart</title>
    <path fill="red" d="M49,85C64,75,98,55,98,25C98,13,89,0,75,0S52,9,49,19C46,9,37,0,23,0S0,13,0,25C0,55,34,75,49,85z" />
</svg>

Deze methode is natuurlijk overal toepasbaar.

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”, “256x256”, “jRc8A52P0” of helemaal niets horen. Hou er daarom rekening mee dat het alt attribuut logisch ingevuld wordt en dat het alleen werkt op plaatjes en een paar andere, zeldzamere, 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.


Wat gehad aan dit artikel? Deel 'm met anderen!

Ontvang de no.dots blog in je inbox

Iedere maand nieuwe tips om succes te behalen met je website.