Wanneer we een website nakijken op toegankelijkheid, weten we vaak al voor we beginnen wat we gaan vinden. Grijze tekst die net te licht is. Een zoekknop die voor een schermlezer niets zegt. Een contactformulier waarvan je na het typen niet meer weet wat er in welk veld moest. Het zijn zelden grote problemen, maar ze maken een website voor een deel van je bezoekers wel onbruikbaar.
We zijn daarin niet alleen. WebAIM onderzoekt elk jaar de homepagina's van een miljoen populaire websites. Op zowat 95% daarvan vinden ze toegankelijkheidsfouten en het zijn vrijwel altijd dezelfde.
Intussen is toegankelijkheid een wettelijke verplichting. Sinds juni 2025 geldt de European Accessibility Act die zegt dat webshops, ticketshops en andere digitale diensten moeten voldoen aan WCAG 2.1 niveau AA. Tijd dus om te kijken waar het meestal fout loopt, en hoe je dat vermijdt.
Wat is WCAG?
WCAG staat voor Web Content Accessibility Guidelines. Het is de internationale standaard van het W3C (de organisatie achter de webstandaarden) die beschrijft hoe je een website bouwt die iedereen kan gebruiken. Denk aan blinde en slechtziende bezoekers, mensen die enkel met een toetsenbord navigeren, doven en slechthorenden of mensen die moeite hebben met lange teksten.
De vier principes
Achter de soms technische criteria zitten vier eenvoudige vragen.
- Kan je bezoeker de inhoud waarnemen? Kan iedereen de inhoud zien, horen of laten voorlezen. Bijvoorbeeld een alternatieve tekst bij een afbeelding.
- Kan hij alles bedienen, ook zonder muis?
- Begrijpt hij wat er staat en wat er van hem verwacht wordt? Zijn teksten, formulieren en foutmeldingen duidelijk en voorspelbaar?
- Is de code zo opgebouwd dat hulpmiddelen zoals schermlezers ermee overweg kunnen?
Drie niveaus: A, AA en AAA
WCAG kent drie niveaus:
- Niveau A is het absolute minimum.
- Niveau AA is de norm die de wet oplegt en die je dus moet halen. Dat is haalbaar voor elke website die van bij het begin goed wordt opgezet.
- Niveau AAA is het hoogste niveau en is voor de meeste websites niet haalbaar voor alle inhoud.
De Europese regels verwijzen naar WCAG 2.1. De nieuwste versie, WCAG 2.2, voegt daar nog enkele criteria aan toe. Wie vandaag een nieuwe website bouwt, mikt dus best meteen op 2.2.
Waar loopt het meestal mis?
De fouten die automatische tools het vaakst vinden, zijn opvallend klein. Het gaat zelden om ingewikkelde technologie, wel om details die tijdens het ontwerp of bij het invoeren van inhoud over het hoofd worden gezien.
Daarnaast zijn er fouten die geen enkele tool opmerkt. Die vind je pas als je de website zelf probeert te gebruiken zoals een bezoeker met een beperking dat doet. Hieronder bespreken we ze allemaal.
1. Mooi ontwerp, maar slecht leesbaar
Lichtgrijs op wit, wit op een pastelkleur, tekst over een drukke foto: in een ontwerp ziet het er rustig en verfijnd uit. Op een smartphone in de zon of voor iemand met minder goede ogen, valt de tekst gewoon weg. Daarom staat te weinig contrast elk jaar met voorsprong bovenaan.
WCAG legt een minimum vast: een contrastverhouding van 4,5:1 voor gewone tekst en 3:1 voor grote titels, knoppen en invoervelden.
Onze tip: test je huisstijlkleuren al bij de start van het ontwerp, niet pas als de website klaar is. Een kleur die net niet voldoet, is dan nog eenvoudig bij te stellen. Zet je tekst op een foto? Voorzie dan een donkere laag tussen beeld en tekst.
2. Afbeeldingen zonder alternatieve tekst
Een schermlezer kan een foto niet bekijken. Hij leest voor wat er in de alt-tekst staat. Is die leeg, dan mist de bezoeker de informatie. In het slechtste geval hoort hij de bestandsnaam, iets als ‘IMG_4821-final.jpg’.
Een goede alt-tekst vertelt in één zin wat het beeld toont of waarvoor het dient. Is de afbeelding een link, beschrijf dan waar die naartoe gaat. Indien het beeld puur decoratief is, laat de alt-tekst dan bewust leeg. Zo slaat de schermlezer het over in plaats van de bezoeker te vervelen.
3. Formuliervelden zonder label
Veel formulieren tonen enkel een grijze voorbeeldtekst in het veld (= placeholder), zoals ‘Je e-mailadres’. Ziet er strak uit, tot je begint te typen. De voorbeeldtekst verdwijnt en je weet niet meer wat er werd gevraagd. Een schermlezer leest die voorbeeldtekst bovendien niet altijd voor.
De oplossing is eenvoudig: geef elk veld een zichtbaar label boven of naast het veld en koppel dat label in de code aan het veld.
4. Lege links en knoppen
Een hamburgermenu, een vergrootglas of een reeks social media-iconen: visueel duidelijk, maar voor een schermlezer vaak gewoon ‘knop’ of ‘link’, zonder verdere uitleg.
Geef elke knop en link daarom een naam die wordt voorgelezen, ook al is die niet zichtbaar. Let ook op tien keer ‘Lees meer’ op één pagina. Wie de links in een lijst laat voorlezen, weet niet welke waarheen gaat. ‘Lees meer over onze zomerkampen’ is veel duidelijker.
5. Geen taal ingesteld
Dit lijkt een detail, maar je hoort het meteen. Zonder lang-attribuut weet een schermlezer niet in welke taal hij moet voorlezen. Een Nederlandse tekst met een Franse uitspraak is onverstaanbaar. Op meertalige Belgische websites zien we dit vaak fout gaan op de anderstalige versie.
Stel per pagina de juiste taal in (lang="nl-BE", lang="fr-BE"). Staat er een anderstalig citaat op de pagina, markeer dan ook dat stuk.
6. Niet bedienbaar met het toetsenbord
Niet iedereen gebruikt een muis. Sommige bezoekers navigeren enkel met de Tab-toets. Elk menu, elke knop en elk formulier moet op deze manier bereikbaar zijn. Je moet hierbij altijd kunnen zien waar je bent.
Juist dat laatste wordt vaak weggewerkt. De focusrand rond een geselecteerde knop vond iemand niet mooi en werd verwijderd. Of het geselecteerde element verdwijnt achter een vaste menubalk of een cookiebanner. Een focusstijl in je eigen huisstijl lost dat op, zonder je ontwerp te storen.
7. Titels gekozen op lettergrootte
Wie een schermlezer gebruikt, scant een pagina door van titel naar titel te springen. Dat werkt alleen als de titels logisch opgebouwd zijn. Wordt een kop gekozen omdat de lettergrootte goed uitkomt, dan raakt die structuur zoek.
Hanteer steeds een logische hiërarchie en kies niet zomaar een kop 'omdat het mooier is'. Bespreek de kopstijlen met de designer of developer indien je merkt dat de groottes niet goed zitten.
8. Foutmeldingen in het rood, en verder niets
Een rood kader rond een fout ingevuld veld zie je niet als je kleurenblind bent. Een schermlezer merkt het al helemaal niet op. Ook wie het wel ziet, heeft weinig aan ‘Ongeldige invoer’.
Zet de fout in woorden naast het veld en zeg hoe de bezoeker ze kan oplossen. ‘Vul een geldig e-mailadres in, zoals naam@voorbeeld.be’ helpt iedereen verder, ook bezoekers zonder beperking.
9. Video zonder ondertitels
Een aftermovie of promovideo zonder ondertitels sluit dove en slechthorende bezoekers uit. Maar ook iedereen die op de trein of op kantoor zonder geluid kijkt. Automatische ondertitels zijn een goed vertrekpunt, maar lees ze even na voor je publiceert.
Hoe test je of je website toegankelijk is?
Een automatische scan is een goed vertrekpunt, maar geen eindpunt. Tools geven in enkele seconden een eerste beeld waarbij naar schatting een derde van alle WCAG-problemen worden gevonden. Of een alt-tekst ook iets zinvols zegt, of je een ticket kan kopen zonder muis: dat moet je zelf uitproberen.
We raden een combinatie van drie stappen aan:
- Automatisch scannen. Gratis tools zoals WAVE, axe DevTools of Lighthouse in Chrome tonen in enkele seconden de meest voor de hand liggende fouten.
- Manueel testen. Leg je muis opzij en probeer met enkel de Tab-toets door je belangrijkste pagina's te gaan. Kan je het menu openen, een formulier invullen, tot aan de betaling geraken?
- Testen met een schermlezer, zoals NVDA op Windows of VoiceOver op een Mac of iPhone. Luister hoe je pagina klinkt voor wie haar niet kan zien.
Kijk ook verder dan je eigen pagina's. Een ingesloten ticketshop, een cookiebanner van een externe partij of een PDF met de praktische info horen er voor je bezoeker gewoon bij. Ook die moeten toegankelijk zijn.
Toegankelijkheid is geen eenmalig project
Een website die bij de oplevering toegankelijk is, blijft dat niet vanzelf. Er komt elke week nieuwe inhoud bij. Een redacteur vergeet een alt-tekst, een nieuwe campagne gebruikt een kleur die net niet genoeg contrast heeft. Daarom is een CMS dat je daarbij helpt minstens zo belangrijk als een eenmalige controle.
Zet tot slot een toegankelijkheidsverklaring op je website. Daarin vertel je eerlijk aan welke norm je voldoet, wat nog niet in orde is en hoe bezoekers een probleem kunnen melden.
Hoe wij het aanpakken
Bij Inventis nemen we toegankelijkheid mee vanaf de eerste schets, niet bij een controle achteraf. Achteraf herstellen kost altijd meer dan het meteen goed doen. Kleuren, focusstijlen en formulieren bekijken we daarom al in de ontwerpfase. In ons Architect CMS helpen vaste stijlen en verplichte velden je team om de website ook daarna toegankelijk te houden, zonder dat iedereen WCAG van buiten moet kennen.
Heb je al een website? Dan starten we met een audit van je belangrijkste pagina's en de paden die je bezoekers het meest gebruiken. Je krijgt een duidelijk overzicht van wat er misloopt, wat het eerst moet gebeuren en wat het kost om het op te lossen.
Benieuwd hoe toegankelijk jouw website is?
We kijken je website na en zeggen je eerlijk hoe ver je staat ten opzichte van WCAG 2.1 AA, en wat er nodig is om in orde te zijn.
Bronnen
- WebAIM Million 2025: cijfers over de meest voorkomende fouten. Controleer voor publicatie of er een recentere editie is.
- W3C, WCAG 2.2: de officiële richtlijnen.
- Richtlijn (EU) 2019/882, European Accessibility Act
- WebAIM Contrast Checker...