WCAG 2.1 quickscan voor een kleine website: wat je zelf kunt controleren

Komt elk klikbaar element aan de beurt? Loopt de volgorde logisch?

Een WCAG 2.1 quickscan voor een kleine website hoeft geen audit-traject van duizenden euro’s te zijn. Voor de meeste sites kun je de grootste tekortkomingen in een uurtje vinden, met tools die gratis zijn en checks die je zonder ontwikkelaar kunt doen. Dit artikel laat zien hoe.

Waarom toegankelijkheid ook voor kleine sites telt

WCAG staat voor Web Content Accessibility Guidelines, opgesteld door de W3C. Versie 2.1 is de huidige praktijkstandaard. Niveau AA is wat overheden en grote organisaties moeten halen, en wat voor MKB-sites een redelijk haalbaar streven is.

Voor kleine ondernemers met een rustige site is volledige AA-compliance niet altijd haalbaar binnen het budget. Maar de basis wel. Een site die slecht toegankelijk is, sluit een deel van je bezoekers uit. Mensen met een visuele beperking, mensen die geen muis kunnen gebruiken, mensen die slecht zien door leeftijd of licht.

Een toegankelijke site is bovendien meestal een betere site. Voor iedereen. Heldere koppen, goed contrast, duidelijke knoppen, een logische volgorde. Dat helpt ook een gehaaste bezoeker op een telefoon in fel zonlicht.

Wat je in een uur zelf kunt controleren

De checks hieronder dekken niet de hele standaard, maar wel de fouten die ik het vaakst zie. Voor een echte WCAG 2.1 quickscan voor een kleine website is dit een goede eerste laag.

1. Kleurcontrast

Tekst die te licht is op een lichte achtergrond is een van de meest voorkomende problemen. WCAG eist een contrastratio van minimaal 4,5:1 voor normale tekst, en 3:1 voor grote tekst (vanaf 18pt of 14pt bold).

Hoe te checken:

• Open de WebAIM Contrast Checker.
• Vul je tekstkleur en achtergrondkleur in als hex-code.
• Lees of je AA haalt voor normale en grote tekst.

Veelvoorkomende fouten: grijze placeholder-tekst in formulieren, grijze datums onder blogposts, lichtgele buttons op witte achtergrond. Loop je site door en let op alles wat “stijlvol licht” oogt.

2. Koppenstructuur

Schermlezers gebruiken koppen om door een pagina te navigeren. Je homepage hoort één H1 te hebben, met daaronder H2’s voor de hoofdsecties en H3’s voor onderverdelingen. Geen H1 binnen een H1, geen H3 zonder H2 erboven.

Hoe te checken:

• Installeer de browserextensie HeadingsMap (gratis voor Chrome en Firefox).
• Open je pagina en klik de extensie aan.
• Kijk of de boomstructuur logisch loopt.

Slecht voorbeeld: een pagina waar de H1 alleen op een knop staat, en de paginatitel een H3 is. Dat komt vaker voor dan je denkt, vooral bij sites die met visuele page builders zijn gebouwd waar koppen op grootte zijn gekozen in plaats van op semantiek.

3. Alt-teksten op afbeeldingen

Iedere informatieve afbeelding hoort een alt-tekst te hebben. Decoratieve afbeeldingen krijgen een lege alt (alt=""), zodat schermlezers ze overslaan.

Hoe te checken:

• Klik met de rechtermuisknop op een afbeelding en kies “Inspecteren” of “Bekijk paginabron”.
• Zoek de -tag en kijk of er een alt-attribuut is.
• Lees de alt-tekst hardop. Beschrijft hij wat er staat? Of is het “afbeelding 1234.jpg”?

Goede alt-tekst is functioneel, niet keyword-stuffed. Voor een productfoto: “Houten bureau met zwarte poten, vooraanzicht”. Niet: “bureau bureaus thuiskantoor MKB Zeeland kopen”.

4. Toetsenbordnavigatie

Druk op Tab vanuit je adresbalk en doorloop de hele pagina. Je hoort drie dingen te zien:

• Elke knop, link en form-veld komt aan de beurt.
• Er is een zichtbare focus-ring rond het actieve element.
• De volgorde is logisch (linksboven naar rechtsonder, niet kris kras).

Als de focus-ring verdwenen is via CSS (outline: none; zonder vervanging), is je site niet bruikbaar voor mensen die geen muis hanteren. Dat zie ik vaak in de praktijk.

5. Formulieren met labels

Elk invoerveld hoort een zichtbaar label te hebben. Placeholder-tekst die verdwijnt als je begint te typen, is geen label. Dat is verwarrend voor iedereen, en onleesbaar voor schermlezers.

Hoe te checken: kijk of bij elk veld in je formulier een tekst boven of naast het veld staat die zichtbaar blijft tijdens het typen. Voor invalide invoer hoort er een duidelijke foutmelding te komen, met uitleg, niet alleen rode rand.

6. Reduced motion

Sommige bezoekers krijgen migraine van bewegende animaties, parallax-effecten en automatisch afspelende video. WCAG vraagt dat je prefers-reduced-motion respecteert: een instelling in het besturingssysteem die zegt “geen onnodige beweging alstublieft”.

Snel testen kan via je systeem-instellingen (Mac: Toegankelijkheid > Beweging beperken, Windows: Toegankelijkheid > Visuele effecten). Daarna terug naar je site. Stoppen de animaties? Zo niet, dan staat de CSS-mediaquery niet aan.

Geautomatiseerde tools die helpen

Naast handmatige checks zijn er een paar gratis tools die in een minuut een eerste laag van problemen vinden.

• WAVE van WebAIM: plak je URL erin en je krijgt een rapport met fouten, waarschuwingen en structuurinformatie.
• Lighthouse (in Chrome DevTools): open DevTools, ga naar het tabblad Lighthouse, vink Accessibility aan en draai de scan.
• axe DevTools (browserextensie): vergelijkbaar met Lighthouse, vaak preciezer in de uitleg.

Belangrijk: geautomatiseerde tools vinden ongeveer 30 tot 40 procent van de echte problemen. Voor een volledige audit blijft handmatig testen en testen met echte gebruikers nodig. Maar voor een quickscan zijn ze prima.

Wat een echte audit anders maakt

Een formele WCAG 2.1 quickscan voor een kleine website door een specialist gaat verder dan dit lijstje. Echte audits omvatten ook:

• Testen met schermlezers (NVDA, JAWS, VoiceOver) op meerdere browsers.
• Beoordelen van complexe componenten zoals modals, sliders en menu’s.
• Cognitieve toegankelijkheid (begrijpelijke taal, voorspelbaar gedrag).
• Compliance-rapportage voor wettelijke vereisten.

Voor sommige sectoren is dat verplicht, denk aan overheid en zorg. Voor een typische MKB-site is een goede zelfscan plus een audit-uur door iemand die ervaring heeft meestal voldoende om de grootste risico’s af te dekken.

Wat ik zelf doe op klantsites

Bij sites die ik in onderhoud heb, neem ik WCAG 2.1 AA als uitgangspunt. Niet als checkbox, wel als richting. Dat betekent in de praktijk:

• Contrast checken bij nieuwe huisstijl-toepassingen.
• Koppenstructuur nalopen bij grotere paginawijzigingen.
• Alt-teksten controleren bij nieuwe afbeeldingen.
• Focus-stijlen behouden of verbeteren, niet wegcommenten.
• Reduced motion respecteren bij animaties.

Volledige WCAG-AA-compliance is een apart audit-traject voor projecten waar dat nodig is. Voor de meeste klanten doe ik een quickscan bij oplevering en jaarlijks tijdens onderhoud.

Veelvoorkomende valkuilen

Een paar dingen die ik consequent fout zie gaan, ook bij sites die er verzorgd uitzien.

Visueel mooi, semantisch leeg. Page builders maken het makkelijk om iets eruit te laten zien als een kop zonder dat het een H-tag is. Dat ziet er goed uit, en is voor schermlezers onzichtbaar.

Iconen zonder tekst of label. Een hamburger-icoon zonder aria-label is voor een schermlezer een lege knop. Dat geldt ook voor sociale-media-iconen in de footer.

Modals die de focus niet vasthouden. Een popup hoort de toetsenbordfocus binnenin te houden. Als je met Tab uit de modal kunt vallen naar de pagina erachter, klopt iets niet.

Filmpjes zonder ondertiteling. Een video op de homepage zonder captions sluit horenden in stilte uit (lees: iedereen op kantoor zonder koptelefoon) en doven helemaal.

Meer over hoe ik werk lees je in de categorie lokaal en menselijk. Voor concrete diensten en onderhoud kun je terecht op de pagina diensten.