WCAG en webtoegankelijkheid: eisen voor websites

WCAG helpt websites bruikbaar te maken voor mensen die bijvoorbeeld slecht zien, niet met een muis werken of informatie anders verwerken. Je leest welke eisen en ontwerpkeuzes daarbij een rol spelen, van toetsenbordbediening en contrast tot formulieren en alternatieve teksten.

Wat WCAG zegt over de toegankelijkheid van websites

WCAG staat voor Web Content Accessibility Guidelines: internationale richtlijnen voor digitale toegankelijkheid. Ze beschrijven hoe webpagina’s bruikbaar kunnen zijn voor mensen met uiteenlopende beperkingen, zoals blindheid, kleurenblindheid, doofheid, beperkte motoriek of cognitieve problemen. De richtlijnen zijn opgebouwd rond vier principes: informatie moet waarneembaar, bedienbaar, begrijpelijk en robuust zijn. Dat laatste betekent onder meer dat hulptechnologie, zoals een schermlezer, de inhoud goed kan interpreteren.

De criteria zijn verdeeld over conformiteitsniveaus A, AA en AAA. Niveau AA omvat de criteria van A en AA en is voor veel organisaties het praktische richtpunt. WCAG 2.2 voegt onder meer aandacht toe voor zichtbare focus, bediening met aanraakdoelen en toegankelijk inloggen. Welke versie juridisch van toepassing is, hangt af van de wet en norm waarnaar wordt verwezen; de Europese norm EN 301 549 speelt daarbij een belangrijke rol. Controleer dus niet alleen of een site een WCAG-label heeft, maar ook welke versie en scope zijn beoordeeld.

De wettelijke plicht verschilt per organisatie en dienst. Overheidsinstanties vallen onder specifieke toegankelijkheidsregels. Voor bepaalde producten en diensten, waaronder veel e-commercediensten, gelden sinds 28 juni 2025 Europese toegankelijkheidseisen, met uitzonderingen en voorwaarden. Een technische beoordeling is daarom geen juridisch advies, maar geeft wel inzicht in concrete barrières op de website.

Een website bedienen met alleen het toetsenbord

Niet iedere bezoeker kan een muis gebruiken. Sommige mensen navigeren met Tab, Shift+Tab, Enter en de pijltjestoetsen; anderen gebruiken een schakelaar of spraakbediening die op toetsenbordfuncties leunt. Alle interactieve onderdelen moeten daarom bereikbaar en bedienbaar zijn zonder muis. Dat geldt voor links, knoppen, menu’s, dialoogvensters, filters en bedieningselementen in een videospeler.

De focusvolgorde hoort de visuele en inhoudelijke volgorde te volgen. Een bezoeker moet met Tab logisch door de pagina gaan en met Shift+Tab terug kunnen. Maak de toetsenbordfocus bovendien duidelijk zichtbaar, bijvoorbeeld met een contrastrijke rand. Verwijder de standaard focusstijl niet zonder een even goed zichtbaar alternatief. Een veelvoorkomende fout is een menu dat alleen verschijnt bij hover: toetsenbordgebruikers kunnen het dan niet openen. Een andere is een dialoogvenster dat wel opent, maar waar de focus achter blijft liggen of na sluiten op een onlogische plek terechtkomt.

Test dit handmatig: laad een pagina, raak de muis niet aan en gebruik alleen het toetsenbord. Controleer of je alle onderdelen kunt bereiken, begrijpt waar de focus staat en nergens vastloopt. Een ‘skip naar hoofdinhoud’-link kan lange navigatiemenu’s overbruggen. Zorg daarbij dat die link zichtbaar wordt wanneer hij focus krijgt. Gebruik voor bediening waar mogelijk gewone HTML-knoppen en links; zelfgebouwde interactieve componenten vragen extra werk om toetsenbordgedrag correct na te bootsen.

Kleurcontrast en informatie die niet alleen van kleur afhangt

Tekst moet voldoende contrast hebben met de achtergrond om leesbaar te blijven voor bezoekers met verminderd zicht of kleurenblindheid. WCAG 2.2 AA vraagt doorgaans een contrastverhouding van minimaal 4,5:1 voor gewone tekst en 3:1 voor grote tekst. Voor grote tekst gaat het in deze context meestal om tekst vanaf 18 punt, of vanaf 14 punt als die vet is. Voor belangrijke grafische onderdelen en de grenzen van invoervelden geldt vaak een minimum van 3:1 ten opzichte van aangrenzende kleuren.

Een kleurcombinatie die op een goed gekalibreerd scherm prima oogt, kan op een telefoon in zonlicht nauwelijks leesbaar zijn. Controleer daarom de concrete kleurwaarden met een contrasttool, niet alleen op gevoel. Meet ook tekst over afbeeldingen, verlopen en transparante lagen: het contrast kan per deel van de achtergrond verschillen. Een oplossing is een effen achtergrondvlak achter tekst of een sterkere overlay. Dat kan de uitstraling veranderen, maar is betrouwbaarder dan hopen dat elke uitsnede voldoende contrast oplevert.

Kleur mag bovendien niet de enige manier zijn om betekenis over te brengen. Een formulier dat fouten uitsluitend met rode randen aanduidt, is voor sommige gebruikers niet duidelijk. Voeg bijvoorbeeld een tekstmelding of pictogram toe. Hetzelfde geldt voor grafieken: onderscheid reeksen niet alleen met verschillende kleuren, maar ook met labels, patronen of lijnstijlen. Test kleurencombinaties waar mogelijk met simulaties, maar onthoud dat zulke hulpmiddelen echte gebruikerstests niet vervangen.

Alternatieve teksten voor afbeeldingen en iconen schrijven

Een schermlezer kan een afbeelding niet vanzelf beschrijven. De alternatieve tekst, meestal vastgelegd als alt-tekst, geeft de bezoeker de informatie die nodig is om de afbeelding in de context van de pagina te begrijpen. Dat is niet altijd een letterlijke beschrijving van wat erop staat. Bij een foto van een product kan bijvoorbeeld de productnaam en relevante uitvoering belangrijker zijn dan de kleur van de achtergrond. Bij een infographic moet de tekst de informatie uit de grafiek beschikbaar maken, eventueel met een uitgebreide toelichting in de pagina.

Decoratieve afbeeldingen horen doorgaans een lege alt-tekst te hebben, zodat hulptechnologie ze kan overslaan. Laat het attribuut niet zomaar weg: sommige schermlezers kunnen dan de bestandsnaam voorlezen, wat ruis oplevert. Een icoon dat een knop betekenis geeft, vraagt juist om een toegankelijke naam. Als een winkelwagenknop alleen een pictogram toont, moet de knop bijvoorbeeld een naam hebben als ‘Winkelwagen bekijken’. De alt-tekst van een afbeelding in een link hangt af van de bestemming of functie van die link.

Vermijd teksten als ‘afbeelding van’ wanneer dat niets toevoegt, en prop geen zoekwoorden in alt-teksten. Een praktische redactieregel is: vraag welke informatie verloren gaat als de afbeelding niet zichtbaar is. Als het antwoord ‘geen’ is, is de afbeelding waarschijnlijk decoratief. Als de afbeelding inhoud draagt, schrijf dan kort en doelgericht. Maak afspraken voor productfotografie, banners en iconen in het contentbeheer; anders ontstaan per pagina verschillende keuzes en blijven nieuwe afbeeldingen ongemerkt zonder passende tekst achter.

Toegankelijke formulieren met duidelijke labels en foutmeldingen

Formulieren vormen vaak de plek waar een toegankelijkheidsprobleem direct gevolgen heeft: iemand kan geen account aanmaken, een bestelling plaatsen of een aanvraag versturen. Elk invoerveld heeft een zichtbaar en programmatisch gekoppeld label nodig. Een placeholder in het veld is geen volwaardig label: die verdwijnt zodra iemand begint te typen en heeft vaak te weinig contrast. Zet instructies zoals een datumformaat buiten het veld en koppel ze technisch aan de invoer, zodat een schermlezer ze kan vinden.

Maak duidelijk welke velden verplicht zijn en welke invoer wordt verwacht. Alleen een rood sterretje is niet voor iedereen begrijpelijk; leg de betekenis uit en communiceer die ook aan hulptechnologie. Als een invoer ongeldig is, benoem dan welk veld een probleem heeft en hoe iemand het kan oplossen. ‘Er ging iets mis’ is onvoldoende. Een bruikbare foutmelding zegt bijvoorbeeld dat een e-mailadres geen geldig formaat heeft. Plaats de melding bij het veld en zorg dat die niet uitsluitend door kleur herkenbaar is.

Bij een formulier met meerdere fouten helpt een samenvatting bovenaan, met links naar de betreffende velden. Laat na verzenden de focus naar die samenvatting of het eerste foutieve veld gaan, zodat de gebruiker niet zelf de pagina hoeft af te zoeken. Test ook of ingevoerde gegevens behouden blijven na een fout. Dat voorkomt herhaalwerk, zeker bij lange formulieren. Automatische validatie kan behulpzaam zijn, maar geef mensen genoeg tijd om hun antwoord aan te passen en blokkeer de invoer niet met onverwachte foutmeldingen tijdens het typen.

Koppen, HTML en schermlezers: maak de structuur herkenbaar

Een webpagina bestaat niet alleen uit zichtbare tekst, maar ook uit een structuur die hulptechnologie kan uitlezen. Koppen geven aan hoe onderwerpen zich tot elkaar verhouden. Gebruik daarom echte HTML-koppen in een logische volgorde: een hoofdkop, gevolgd door tussenkoppen en eventuele subkoppen. Kies een kopniveau niet omdat de standaardopmaak toevallig de gewenste grootte heeft. De vormgeving kun je aanpassen met CSS; de semantische functie van de kop blijft dan intact.

Ook andere HTML-elementen hebben betekenis. Een link brengt iemand naar een andere locatie, een knop voert een actie uit en een lijst groepeert bij elkaar horende items. Als alles met generieke elementen wordt gebouwd en alleen visueel op knoppen of koppen lijkt, kan een schermlezer de functie niet betrouwbaar doorgeven. Dat maakt navigeren trager en vergroot de kans op fouten. Benoem links bovendien betekenisvol: ‘Bekijk openingstijden’ is informatiever dan ‘Klik hier’, vooral wanneer iemand een lijst met links opvraagt.

Gebruik herkenbare gebieden voor navigatie, hoofdinhoud en voettekst, en voorkom meerdere gebieden met dezelfde naam als hun functie verschilt. Tabellen zijn bedoeld voor gegevens in rijen en kolommen, niet om de pagina op te maken. Bij datatabellen moeten kolom- en rijheaders goed herkenbaar zijn. Test de structuur niet alleen door naar de pagina te kijken. Bekijk de koppenlijst en landmarks met een schermlezer of browserhulpmiddel. Een visueel nette pagina kan in die overzichten alsnog onlogisch of onvolledig blijken.

Leesbare websites op mobiel, bij inzoomen en met beweging

Toegankelijkheid stopt niet bij een desktopontwerp. Mensen bekijken websites op kleine schermen, vergroten tekst of gebruiken een hoge zoomfactor. De inhoud moet bij inzoomen bruikbaar blijven zonder dat tekst wordt afgesneden of bediening buiten beeld verdwijnt. Voor veel gewone webinhoud geldt dat een vergroting tot 200 procent mogelijk moet zijn zonder verlies van inhoud of functionaliteit. Bij smalle schermen moet tekst in de meeste gevallen kunnen terugvloeien zonder horizontaal scrollen; uitzonderingen bestaan bijvoorbeeld voor brede tabellen of kaarten waarbij tweedimensionale weergave essentieel is.

Controleer niet alleen of de pagina technisch schaalt, maar ook of de volgorde logisch blijft. Een vaste balk kan na inzoomen een formulierknop bedekken, terwijl een menu op mobiel misschien niet met toetsenbord of schermlezer te bedienen is. Aanraakdoelen moeten groot genoeg en voldoende uit elkaar staan om onbedoelde tikken te beperken. Kleine pictogrammen met een ruim klikgebied kunnen daarbij beter werken dan minieme knoppen, zolang de naam en functie ook toegankelijk zijn.

Beweging kan informatie verduidelijken, maar kan ook afleiden of lichamelijke klachten veroorzaken. Geef bezoekers controle over automatisch bewegende carrousels en video’s die langer dan enkele seconden doorgaan. Houd rekening met de instelling ‘minder beweging’ op het apparaat en vermijd animaties die onnodig blijven herhalen. Een stilstaande presentatie kan rustiger en toegankelijker zijn, maar zorg wel dat essentiële informatie niet uitsluitend in een animatie te zien is. Test pagina’s met verschillende schermbreedtes, zoominstellingen en systeemvoorkeuren, niet alleen in de standaardweergave.

WCAG testen en toegankelijkheid bij wijzigingen bewaken

Een automatische scan is een handige eerste controle, maar bewijst niet dat een website aan WCAG voldoet. Software kan bijvoorbeeld ontbrekende alt-attributen vinden, maar niet betrouwbaar bepalen of de beschrijving betekenisvol is. Ook ziet een scanner vaak niet of een toetsenbordvolgorde logisch is, of foutmeldingen begrijpelijk zijn en of een schermlezer de juiste informatie uit een formulier krijgt. Combineer daarom geautomatiseerde controles met handmatige tests en, waar mogelijk, tests met mensen die verschillende hulpmiddelen gebruiken.

Maak de scope concreet voordat je begint. Een onderzoek naar één homepage zegt weinig over een checkout, zoekresultaten, accountomgeving of foutpagina. Test representatieve sjablonen en complete gebruikersprocessen, inclusief externe onderdelen zoals betaalmodules en embedded video’s. Leg bevindingen vast met de betreffende pagina, het WCAG-criterium, de impact en een reproduceerbare beschrijving. Prioriteer blokkades die een taak onmogelijk maken, maar houd ook kleinere problemen bij; meerdere kleine hindernissen kunnen samen een proces onbruikbaar maken.

Toegankelijkheid is bovendien onderhoudswerk. Een nieuw thema, formulier, campagnebanner of component kan eerder opgelost gedrag opnieuw kapotmaken. Neem controles op in ontwerp, contentproductie en softwareontwikkeling, bijvoorbeeld met vaste acceptatiecriteria voor knoppen, focus, foutmeldingen en contrast. Een toegankelijkheidsverklaring beschrijft voor organisaties waarvoor dat verplicht is onder meer de toegankelijkheidsstatus, bekende tekortkomingen en een contact- of feedbackmogelijkheid. Zo’n verklaring is geen vervanging voor herstelwerk: geef bevindingen een eigenaar en controleer na aanpassingen of de oplossing ook op andere pagina’s goed werkt.