Zorgen dat je website toegankelijk is voor álle bezoekers; dat verstaan we onder accessibility. Digitale toegankelijkheid moet ervoor zorgen dat mensen met een functionele beperking (zoals doven, slechthorenden en (kleuren)blinden) en mensen met autisme, dyslexie of een motorische beperking niet afhaken als ze jouw website bezoeken. En dan is er nog de groep ‘gewone’ gebruikers die ervoor kiest het toetsenbord te gebruiken bij hun sitebezoek. Iedereen moet gebruik kunnen maken van websites, webshops en andere online platforms. Dat is voor (semi)overheden zelfs vastgelegd in de wet.
We krijgen steeds vaker de vraag vanuit onze klanten om hun websites meer en beter toegankelijk te maken. Accessibility wordt steeds belangrijker en ook in de media neemt de aandacht hiervoor toe. Er zijn verschillende niveaus om je website toegankelijker te maken: van een aantal simpele verbeteringen tot helemaal drempelvrij. Maar met slechts een aantal kleine wijzigingen kan je al flinke stappen maken om een website toegankelijker te maken. Er is hierbij een aantal doelgroepen om rekening mee te houden.
Doven en slechthorenden
Je zou misschien denken dat dove mensen geen smartphone gebruiken, maar veel dove mensen zijn vanaf hun telefoon zeer actief zijn op het internet. Het enige wat zij niet doen op hun smartphone is bellen. Ik ken zelf een aantal dove mensen en hun grootste ergernis is meestal dat zij filmpjes zonder ondertitels niet kunnen volgen; voor hen zit daar de grootste winst als het gaat om accessibility. Dat geldt trouwens niet alleen voor doven en slechthorenden. Ook niet-doven kijken vaak filmpjes met ondertiteling, bijvoorbeeld in de trein als je geen oordopjes in hebt.
Blinden en slechtzienden
Voor blinden en slechtzienden is het van belang dat de html-code voorziet in accessibility. Zelf heeft deze doelgroep meestal al de nodige toegankelijkheid tools en -software in hun browser of smartphone, zoals screenreaders die een site voorlezen. Als ontwikkelaar hier zelf iets voor maken is dus onnodig. Een voorbeeld van een screenreader is ChromeVox.
Om een site klaar te maken voor screenreaders is het wel van belang dat de code hierin voorziet. Onderaan deze blog heb ik alle do’s en don’ts voor je op een rijtje gezet.
Blinden en slechtzienden browsen een site anders dan reguliere gebruikers. Ze kunnen van boven naar beneden door een site ‘tabben’ waarbij hun screenreader alles voorleest. Maar vaak wordt gekozen voor alleen het oplezen van h1’s en h2’s, het oplezen van alle linkteksten op een pagina, of direct scrollen naar navigatie-elementen of andere html5-elementen (bijv. <footer>).
Verder is voor mensen met een visuele beperking ook het contrast van belang. Letters moeten bijvoorbeeld genoeg contrast hebben met de achtergrond om niet tegen de achtergrond weg te vallen. Dit geldt overigens niet alleen voor slechtzienden maar ook voor gebruikers met wat slechtere verouderde schermen. Niets zo irritant als iets niet kunnen lezen omdat er bijvoorbeeld lichtgrijs op wit is gebruikt.
Toetsenbord gebruikers
Toestsenbordgebruikers zijn gebruikers die bijvoorbeeld door een beperking of blessure hun muis niet (goed) kunnen gebruiken en veel meer hun toetsenbord gebruiken om door een site te browsen. Voor deze groep gebruikers is het, net als bij blinden en slechtzienden, van belang dat de hele site met de tab- en de enter toets te browsen is. De gebruiksvriendelijkheid neemt daarbij toe als er een extra visuele indicatie is op tab-focus. Denk aan een teaser die oplicht, een link die van kleur verandert of een border om een knop. Zo wordt de gebruiker geholpen te zien waar hij zich bevindt op de site en welke interacties er mogelijk zijn.
Gewone gebruikers
Accessibility is trouwens niet alleen van belang voor mensen met een beperking. Denk bijvoorbeeld aan de grootte van knoppen of links op mobiel. Niets zo irritant als een te kleine knop waar je constant naast ‘touched’. Of linkjes die te dicht op elkaar staan waardoor je steeds op het verkeerde klikt, een filmpje dat spontaan opent terwijl je naar beneden swiped. Bij formulieren gaat het ook nog wel eens mis met de toegankelijkheid. Soms zijn ze te lang (en kun je niet vooraf zien hóe lang) of is onduidelijk wat er ingevuld moet worden. En staat er bij een wachtwoord-instelling niet vermeld waar het wachtwoord aan moet voldoen, dan blijf je met een beetje pech foutmeldingen krijgen (‘wachtwoord moet ook cijfers bevatten’, ‘wachtwoord moet ook een speciaal character bevatten’, ‘wachtwoord mag geen uitroepteken bevatten’).
Als bedrijf loop je met zo’n haperende accessibility voor je het weet klanten, opdrachten, bestellingen, donaties of sponsoren mis. Terwijl je met wat aandacht voor toegankelijkheid je gebruikers juist goed kunt helpen. Denk bijvoorbeeld aan het gebruik van de juiste html5 inputvelden zodat gebruikers op mobiel het telefoonnummer-toetsenbord krijgen bij een invoerveld voor hun mobiele nummer. Heldere, logische formulieren die aangeven waar je aan toe bent en wat er van je wordt verlangd: dat is iets waar zowel de gebruiker als de site-eigenaar iets aan heeft.
Alles op een rijtje
Tot slot een kleine checklist waarmee je als als ontwikkelaar al flinke stappen kan maken bij het toegankelijk maken van een website:
Maak gebruik van HTML5 elementen (
<nav>,<footer>,<section>etc)Zorg dat alle images die belangrijk zijn voor de content een ‘alt’ tekst hebben die de afbeelding omschrijft. Deze alt-tekst is van belang voor een screenreader die deze tekst opleest voor slechtzienden, maar bijvoorbeeld ook voor de vindbaarheid in een zoekmachine.
Voorkom dubbele testen bij afbeeldingen en links, dus bijv. ‘title attribute’ is alleen van nut bij een link als deze tekst iets toevoegt (title attribuut en de link tekst zelf worden beiden opgelezen).
Alle links moeten ook een tekst hebben die opleesbaar is door een screenreader. Er komt vaak voor dat een icoon klikbaar is, bijvoorbeeld een zoekicoon in een menu. Duidelijk voor iemand die kan zien, maar voor een blinde gebruiker moet in zo’n geval ‘Zoeken’ opgelezen worden door de screenreader. Het verbergen van deze tekst moet wel goed gebeuren en niet met ‘display: none;’ want dit verbergt ook de tekst voor een screenreader. Er zijn verschillende css-technieken om deze tekst screenreader-only te maken.
Voor interacties die niet zelf een link zijn maar bijv. alleen een menu openen, is een
<button>gebruikt in plaats van een<a>, met daarin een leesbare tekst voor de screenreader. Deze hoeft niet zichtbaar te zijn aan de voorkant, je hebt styling die tekst alleen zichtbaar maakt voor screenreaders. Zie het puntje hierboven. Dit om te voorkomen dat de screenreader steeds ‘Empty link’ op leest omdat hij een interactief element interpreteert als een gewone link.De tab-volgorde moet kloppen, als je de site door ‘tabt’ ga je van boven naar beneden en skip je niet ineens stukken van de site.
Html die niet direct zichtbaar is (zoals dropdowns) is pas tab-baar na opening (bijv. met ‘enter’). Dit voorkomt dat je ineens in onzichtbare stukken van de site tabt wat erg verwarrend is.
Alle interacties zijn triggerbaar via toetsenbord, bijvoorbeeld het versturen van een formulier met de Enter toets.
Alle interacties moeten visueel zichtbaar zijn. Denk hierbij aan een andere styling van een link op hover EN op focus (belangrijk voor toetsenbord gebruiker)
De volgorde van de headings klopt. Een h3 volgt na een h2 die weer volgt op een h1. Dit is belangrijk voor screenreader die de documentstructuur aanhouden, een blinde kiest er vaak voor om bijvoorbeeld alle h1’s en h2’s op te laten lezen zodat hij of zij snel een overzicht heeft van de inhoud van een pagina. Maar ook is dit belangrijk voor SEO.
Zorg voor een duidelijke formulier structuur. Een input heeft altijd een label die de input omschrijft (al dan niet alleen ‘getoond’ voor screenreaders). Checkbox-groepen staan idealiter binnen een
<fieldset>en deze fieldset heeft weer een<legend>die de groep omschrijft. Foutmeldingen moeten duidelijk zijn zodat de gebruiker snel het formulier juist kan invoeren. Idealiter koppel je foutmeldingen dmv aria-attributen aan het juiste veld vanwege screenreaders.Voeg ‘skiplinks’ toe zodat toetsenbord gebruikers en screenreader-gebruikers het hoofdmenu kunnen skippen. Als je al een tijdje op een site bent is het niet altijd belangrijk dat je altijd weer het hoofdmenu door moet, soms wil je gelijk naar de relevante content kunnen gaan waar je naar op zoek was.
Zorg dat je site er ook nog goed uit ziet als een gebruiker de zoom op meer dan 100% heeft staan, dit hebben slechtzienden en ouderen vaak.
Zorg voor genoeg klik-oppervlakte zodat mensen met motorische beperkingen, maar ook gebruikers op touch schermen, makkelijk op knoppen en links kunnen klikken.
Doe een html-validatie, als de html structuur op orde is (gebruik van html5, alt-text bij images, gebruik van for attributen bij form-labels etc) kom je al een heel eind.
Doe een Lighthouse Audit in Chrome. Deze doet ook een simpele accessibility analyse naast andere interessante analyses.
Verder zijn er natuurlijk nog vele andere tools en mogelijkheden. Je kan nog veel verder gaan als je bijvoorbeeld je website drempelvrij wilt maken. Denk hierbij aan het gebruik van ARIA-attributen. Dit zijn attributen die je kan inzetten om nog specifieker de rol van bepaalde elementen aan te geven, bijv een tab-menu (role=“tablist”). Je kan dmv ARIA-attributen en alt-texten zelfs foto-carousels toegankelijk maken voor blinden.
Je kunt zo ver gaan als je wilt met toegankelijkheid maar kleine wijzigingen en stappen kunnen al een groot verschil maken en er voor zorgen dat jouw website voor iedereen toegankelijk is.
Interessante links
Video’s van screenreaders met vergelijkingen.
Officiële website van de UK-government laat zien hoe zij al hun code usable/accessible hebben gemaakt.
MDN docs on accessibility.