Je website is toegankelijk als iedereen hem kan gebruiken, ongeacht beperking of hulpmiddel. Dat klinkt logisch, maar in de praktijk lopen veel websites tegen dezelfde drempels aan: slecht contrast, ontbrekende alt-teksten, geen toetsenbordnavigatie. De Web Content Accessibility Guidelines — kortweg WCAG richtlijnen — bieden een internationaal erkend raamwerk om die drempels te slechten.

Inhoudsopgave

Wat zijn WCAG richtlijnen en waarom heb je ze nodig?
De drie WCAG-niveaus: A, AA en AAA
WCAG wetgeving en verplichtingen voor Nederlandse bedrijven
WCAG richtlijnen: de vier principes als fundament van toegankelijkheid
Principe 1 – Waarneembaar (Perceivable)
Principe 2 – Bedienbaar (Operable)
Principe 3 – Begrijpelijk (Understandable)
Principe 4 – Robuust (Robust)
WCAG richtlijnen checklist: waar begin je mee?
Veelgemaakte fouten en hoe je ze voorkomt
Veelgestelde vragen over wcag richtlijnen
Conclusie

Dit artikel geeft je een compleet overzicht van alle WCAG-principes en -richtlijnen. Niet als juridisch document, maar als praktische gids waarin je per onderdeel snapt wat er bedoeld wordt, hoe je het controleert en waarom het ertoe doet. Of je nu zelf je website beheert of met een ontwikkelaar samenwerkt: na dit artikel weet je waar je op moet letten.

Wat zijn WCAG richtlijnen en waarom heb je ze nodig?

De Web Content Accessibility Guidelines zijn een set internationale standaarden die beschrijven hoe je webcontent toegankelijk maakt voor mensen met een beperking. Denk aan slechtzienden die een schermlezer gebruiken, mensen met motorische beperkingen die niet met een muis kunnen werken, of doven die ondertiteling nodig hebben bij video’s.

WCAG is ontwikkeld door het World Wide Web Consortium (W3C) en wordt wereldwijd erkend als dé standaard voor digitale toegankelijkheid. Waarom is dit belangrijk voor jou? Twee redenen. Een toegankelijke website bereikt een bredere doelgroep — vergroot je potentiële klantenbestand. Daarnaast komt er wetgeving die toegankelijkheid verplicht stelt.

Waar gaat over gebruiksgemak voor iedereen, richt toegankelijkheid zich specifiek op mensen die assistive technology gebruiken: schermlezers, brailleleesregels, spraakbesturing, toetsenbordnavigatie. Een toegankelijke website is vaak ook gebruiksvriendelijker voor iedereen, maar het omgekeerde geldt niet per se.

De kern van WCAG: zorg dat informatie waarneembaar, bedienbaar, begrijpelijk en robuust is. Die vier principes structureren alle richtlijnen en komen later uitgebreid aan bod.

De drie WCAG-niveaus: A, AA en AAA

WCAG kent drie conformiteitsniveaus: A, AA en AAA. Elk niveau bouwt voort op het vorige.

Niveau A bevat de meest basale toegankelijkheidseisen. Een website die hier niet aan voldoet, is voor grote groepen gebruikers onbruikbaar. Denk aan: afbeeldingen zonder alt-tekst, of een formulier dat je niet met een toetsenbord kunt bedienen.

Niveau AA is de standaard waar de meeste wetgeving naar verwijst, en waar je als MKB-ondernemer op moet mikken. Dit niveau omvat alle A-criteria plus aanvullende eisen zoals voldoende kleurcontrast en consistente navigatie. De Europese toegankelijkheidsrichtlijn en de Nederlandse Wet digitale toegankelijkheid hanteren AA als minimumnorm.

Niveau AAA is het hoogste niveau en bevat eisen die niet altijd haalbaar of relevant zijn voor alle content. Voorbeelden: gebarentaal-tolken bij video’s, of uitzonderlijk hoog contrast. Dit niveau is zelden verplicht en wordt meestal alleen toegepast in specifieke sectoren zoals gezondheidszorg of overheid.

De meest gebruikte versie is momenteel WCAG 2.1, uit 2018. In 2023 verscheen WCAG 2.2 met enkele aanvullende criteria, vooral gericht op mobiel gebruik en mensen met cognitieve beperkingen. Het verschil tussen 2.1 en 2.2 is beperkt: 2.2 voegt negen nieuwe succescriteria toe maar haalt er niets uit. Als je vandaag start met toegankelijkheid, richt je dan op WCAG 2.1 niveau AA — dat dekt de wettelijke basis en de meest impactvolle verbeteringen.

WCAG wetgeving en verplichtingen voor Nederlandse bedrijven

Vanaf 28 juni 2025 treedt de European Accessibility Act (EAA) in werking. Deze Europese wet verplicht bedrijven in bepaalde sectoren om hun digitale diensten toegankelijk te maken volgens WCAG 2.1 niveau AA. Denk aan webshops, online banken, telecomaanbieders en vervoersbedrijven.

Ben je als MKB-ondernemer verplicht? Dat hangt af van je sector en omvang. Microondernemingen (minder dan 10 medewerkers én minder dan 2 miljoen omzet) zijn in veel gevallen vrijgesteld van de EAA, maar grotere bedrijven in de genoemde sectoren vallen er wel onder. Bovendien kunnen klanten of partners alsnog toegankelijkheid eisen, bijvoorbeeld in aanbestedingen of contracten.

De Wet digitale toegankelijkheid geldt al langer voor overheidsinstellingen, maar wordt geleidelijk breder toegepast. Publieke organisaties moeten sinds 2020 voldoen aan WCAG 2.1 niveau AA en een toegankelijkheidsverklaring publiceren.

Wat gebeurt er als je niet voldoet? De EAA introduceert boetes bij niet-naleving, uitgevoerd door nationale toezichthouders. De precieze sancties variëren per land, maar kunnen oplopen tot tienduizenden euro’s. Belangrijker dan boetes is het reputatierisico: een klacht over toegankelijkheid kan negatieve publiciteit opleveren en klanten wegsturen.

Moet je morgen alles compliant hebben? Nee. Begin met de quick wins (alt-teksten, contrast, toetsenbord) en werk gefaseerd aan verbetering. Een toegankelijkheidsverklaring waarin je erkent waar de knelpunten zitten en wat je eraan doet, toont goede wil en vermindert juridisch risico.

WCAG richtlijnen: de vier principes als fundament van toegankelijkheid

vier wcag richtlijnen principes waarneembaar bedienbaar begrijpelijk robuust

Alle WCAG-richtlijnen zijn opgebouwd rond vier kernprincipes. Ze vormen een geheugensteuntje: POUR (Perceivable, Operable, Understandable, Robust). In het Nederlands:

Waarneembaar — Informatie en interface moeten waarneembaar zijn voor alle zintuigen. Als iemand niet kan zien, moet de content ook via geluid of aanraking (braille) beschikbaar zijn.
Bedienbaar — Alle functies moeten bedienbaar zijn, ongeacht invoerapparaat. Wie geen muis kan gebruiken, moet met toetsenbord of spraak door de site kunnen navigeren.
Begrijpelijk — Content en bediening moeten logisch en voorspelbaar zijn. Geen plotselinge context-wijzigingen, duidelijke foutmeldingen, leesbare taal.
Robuust — De site moet goed werken met verschillende browsers en assistive technology, nu en in de toekomst. Dat vraagt om valide, semantische code.

Deze vier principes splitsen zich op in richtlijnen, die vervolgens uitmonden in concrete succescriteria. In de volgende secties doorlopen we elk principe met de belangrijkste richtlijnen en praktische voorbeelden.

Principe 1 – Waarneembaar (Perceivable)

Een website is waarneembaar als gebruikers de informatie kunnen opnemen, ongeacht hun zintuigen. Wie niets ziet moet de content kunnen horen (schermlezer) of voelen (braille). Wie niets hoort moet ondertiteling of transcripties krijgen. Het principe ‘waarneembaar’ bevat vier richtlijnen, elk met concrete criteria.

Tekstalternatieven voor niet-tekstuele content

Elke afbeelding, grafiek of icoon die informatie overbrengt, moet een tekstalternatief hebben: een alt-tekst. Schermlezers lezen die alt-tekst voor, zodat blinde gebruikers weten wat er staat.

Doe dit: Schrijf een beschrijving die de functie of inhoud van de afbeelding samenvat. Voorbeeld: voor een foto van je productie-afdeling schrijf je alt="Medewerkers assembleren printplaten in de productiehal". Voor een logo: alt="Redfactory logo".

Vermijd dit: Lege alt-teksten bij informatieve afbeeldingen, of generieke teksten als alt="afbeelding123.jpg". Ook overbodig: woorden als “afbeelding van” — de schermlezer weet al dat het om een afbeelding gaat.

Decoratieve afbeeldingen die geen informatie toevoegen (achtergrondpatronen, scheidingslijnen) krijgen een lege alt-tekst: alt="". Zo slaat de schermlezer ze over.

Controle: Inspecteer je site met een browser-extensie zoals WAVE of gebruik de ingebouwde accessibility-checker in je CMS. Ontbrekende alt-attributen lichten op als fout.

Tijdgebonden media (video en audio)

Video’s en audio-opnamen vragen om alternatieven: ondertiteling voor doven, transcripties voor wie liever leest, en audiodescriptie voor blinden (een gesproken beschrijving van wat visueel gebeurt).

Ondertiteling is verplicht voor vooropgenomen video’s met geluid (WCAG 2.1 AA). Dat geldt dus ook voor die productvideo op je homepage of de instructievideo in je klantenportaal. Geautomatiseerde ondertiteling (YouTube, Vimeo) is een begin, maar controleer altijd de kwaliteit — automatische herkenning maakt fouten, vooral bij vakjargon of namen.

Transcripties zijn tekstversies van de gesproken inhoud. Ze helpen niet alleen dove gebruikers, maar ook mensen die liever lezen of in een omgeving zonder geluid zitten. Een transcriptie plaats je onder de video of als downloadbare bijlage.

Audiodescriptie beschrijft visuele elementen die niet uit het geluidsspoor blijken (bijvoorbeeld: “Jan opent de deur en loopt de kamer in”). Dit is vooral relevant bij complexe content of instructievideo’s. Voor niveau AA is audiodescriptie vereist bij vooropgenomen media.

Praktische tools: Otter.ai of Descript voor transcripties, Rev.com voor professionele ondertiteling. YouTube biedt automatische ondertiteling die je kunt bewerken en downloaden.

Aanpasbare content en structuur

Content moet logisch gestructureerd zijn, zodat schermlezers de hiërarchie begrijpen. Dat begint bij : gebruik de juiste HTML-elementen voor hun bedoelde doel.

Headings (H1, H2, H3) structureren je pagina. Een H1 is de hoofdtitel, H2’s zijn hoofdstukken, H3’s zijn subsecties binnen H2’s. Sla geen niveaus over: spring niet van H2 naar H4. Schermlezers gebruiken headings om door de pagina te navigeren — gebruikers kunnen naar de volgende H2 springen zonder alles te hoeven beluisteren.

Doe dit: Begin elke pagina met één H1 (de paginatitel), gebruik H2’s voor de belangrijkste secties, en H3’s voor subsecties. Controleer de heading-hierarchie met een tool als HeadingsMap (browser-extensie).

Vermijd dit: Headings opmaken met CSS (groot, vet lettertype) zonder de juiste HTML-tag te gebruiken. Ook fout: meerdere H1’s op één pagina, of H3 gebruiken omdat het lettertype toevallig goed oogt.

Lijsten (<ul>, <ol>) en tabellen (<table> met <th> voor koppen) moeten semantisch correct worden gecodeerd. Schermlezers herkennen deze structuren en kondigen aan: “lijst met 5 items” of “tabel met 3 kolommen”.

Onderscheidbare content

Informatie moet visueel goed onderscheidbaar zijn. Dat betekent vooral: voldoende contrast tussen tekst en achtergrond, en geen informatie die alleen via kleur wordt overgebracht.

De WCAG contrast-eisen voor niveau AA: – Normale tekst: minimaal 4,5:1 contrast tussen tekst en achtergrond – Grote tekst (18pt of groter, of 14pt vet): minimaal 3:1

Doe dit: Test je kleurenschema met een contrastchecker zoals WebAIM Contrast Checker of Coolors. Voldoet je huisstijl niet? Pas de tint aan of gebruik een donkerdere/lichtere variant.

Vermijd dit: Lichtgrijze tekst op wit (#CCCCCC op #FFFFFF haalt geen 4,5:1). Groene knoppen met rode foutmeldingen waarbij je alleen op kleur vertrouwt — voeg ook een icoon of tekst toe (“Fout: veld is verplicht”).

Tekst over afbeeldingen is lastig. Zorg voor een overlay of schaduw die het contrast garandeert, ongeacht de afbeelding erachter. Test dit met verschillende afbeeldingen — wat bij één foto werkt, faalt misschien bij een andere.

Kleur alleen is niet genoeg om informatie over te brengen. Als je een grafiek maakt met groene en rode balken, voeg dan labels of patronen toe. Kleurenblinden zien het verschil anders niet.

Principe 2 – Bedienbaar (Operable)

Bedienbaar betekent dat alle functies van je website bruikbaar zijn, ongeacht het invoerapparaat. De belangrijkste uitdaging: toetsenbordnavigatie.

Toetsenbordtoegankelijkheid

Alles wat je met een muis kunt doen, moet ook met een toetsenbord werken. Gebruikers met motorische beperkingen, maar ook power-users, navigeren vaak volledig met Tab, Enter en pijltjestoetsen.

Doe dit: Test je site door je muis weg te leggen. Druk op Tab om door de pagina te springen. Kom je bij alle knoppen, links en formuliervelden? Kun je dropdown-menu’s openen met Enter of Spatie? Is de focus-indicator (meestal een blauwe of gekleurde rand) altijd zichtbaar?

Vermijd dit: <div>-elementen met een onClick-event die zich gedragen als knoppen, maar niet toegankelijk zijn via toetsenbord. Gebruik <button> of <a href=""> en voeg tabindex="0" toe als je écht een andere oplossing nodig hebt. Ook fout: de focus-indicator verbergen met CSS (outline: none;) zonder alternatief te bieden.

De tab-volgorde moet logisch zijn: van links naar rechts, van boven naar beneden. Als je CSS gebruikt om de visuele volgorde te wijzigen (bijvoorbeeld met flexbox order), zorg dan dat de DOM-volgorde (de HTML-structuur) overeenkomt.

Dropdown-menu’s zijn een veelvoorkomend probleem. Zorg dat submenu’s openen met Enter of Spatie, en dat je met Escape weer terugkunt. Gebruik ARIA-attributen (aria-haspopup, aria-expanded) om de status te communiceren.

Controleer dit met de toetsenbord-only test: navigeer door je hele site zonder muis. Kom je overal? Dan zit je goed.

Voldoende tijd voor interactie

Gebruikers moeten genoeg tijd krijgen om content te lezen en interacties af te ronden. Automatische time-outs of bewegende content kan problemen opleveren.

Doe dit: Waarschuw gebruikers als er een tijdslimiet is (bijvoorbeeld bij een betaalproces) en bied de mogelijkheid om de tijd te verlengen. Bij formulieren met sessie-time-out: geef een melding voordat de tijd verloopt, met een knop om door te gaan.

Vermijd dit: Carrousels die automatisch doorschuiven zonder pauzeerknop. Gebruikers met cognitieve beperkingen of schermlezers hebben tijd nodig om de content op te nemen. Voeg play/pauze-knoppen toe, of schakel automatisch afspelen uit zodra de gebruiker met de carrousel interacteert.

Bij chat-widgets of pop-ups: geef gebruikers controle. Een chat die om de 30 seconden een nieuw bericht toont, verstoort de focus van een toetsenbord-gebruiker.

Aanvallen en fysieke reacties voorkomen

Flitsende of knipperende content kan epileptische aanvallen veroorzaken. De grens ligt bij drie flitsen per seconde of minder.

Doe dit: Vermijd flitsende animaties, stroboscoop-effecten of snelle kleurwisselingen. Als je toch bewegende content hebt (animaties, GIF’s, video’s), bied een pauze-knop of schakel ze automatisch uit na vijf seconden.

Vermijd dit: Auto-play video’s met snelle montage of flitsende overgangen. Ook parallax-effecten waarbij achtergronden snel scrollen kunnen voor sommige gebruikers onaangenaam zijn.

Dit criterium is eenvoudig: als je twijfelt of iets te veel flitst, test het of schrap het. De impact van een epileptische aanval weegt niet op tegen het visuele effect.

Navigatie en vindbaarheid

Gebruikers moeten meerdere manieren hebben om pagina’s te vinden, en de navigatie moet consistent zijn.

Skip-links zijn verborgen links bovenaan de pagina die verschijnen bij toetsenbord-focus. Ze laten gebruikers de hoofdnavigatie overslaan en direct naar de main content springen. Zonder skip-link moeten toetsenbord-gebruikers bij elke pagina eerst door 20 menu-items tabben voordat ze de echte content bereiken.

Doe dit: Voeg een skip-link toe: <a href="#main-content" class="skip-link">Spring naar inhoud</a>. Maak hem zichtbaar bij focus met CSS. Zorg dat het anker (id="main-content") bij je hoofdcontent staat.

Meerdere navigatiemethoden betekent: menu, zoekfunctie, sitemap, broodkruimels. Niet iedereen navigeert hetzelfde. Sommigen willen een overzicht (sitemap), anderen zoeken direct (zoekbalk).

Paginatitels moeten uniek en beschrijvend zijn. De <title>-tag is het eerste wat een schermlezer voorleest. “Contact — Redfactory” is beter dan “Redfactory” op elke pagina.

Focus-volgorde moet logisch zijn en overeenkomen met de visuele volgorde. Als je een modal opent, moet de focus naar de modal springen, niet eronder blijven hangen.

Principe 3 – Begrijpelijk (Understandable)

Begrijpelijk gaat over duidelijke taal, voorspelbare interacties en goede foutafhandeling.

Leesbare en begrijpelijke tekst

Stel de taalkenmerk in met het lang-attribuut in je HTML: <html lang="nl">. Schermlezers gebruiken dit om de juiste uitspraak en stemmen te kiezen. Als je een Engels citaat hebt, markeer dat: <span lang="en">Machine learning</span>.

Eenvoudige taal is geen WCAG-eis op niveau AA, maar wordt sterk aanbevolen. Vermijd jargon, of leg technische termen uit bij eerste gebruik. Lange zinnen en complexe constructies maken teksten moeilijker voor mensen met cognitieve beperkingen, dyslexie of niet-moedertaalsprekers.

Afkortingen leg je uit bij eerste gebruik, of met een <abbr>-tag: <abbr title="Web Content Accessibility Guidelines">WCAG</abbr>. Schermlezers lezen dan de volledige term voor.

Voorspelbare werking

Gebruikers verwachten dat een website consistent en voorspelbaar werkt. Plotselinge context-wijzigingen zijn desoriënterend.

Doe dit: Houd navigatie en interacties consistent over alle pagina’s. Als je hoofdmenu linksboven staat, verplaats het dan niet op een subpagina. Hetzelfde geldt voor knoppen: een primaire actie is altijd groen, een secundaire altijd grijs.

Vermijd dit: Pop-ups die openen zodra een gebruiker ergens op klikt of focus zet, zonder waarschuwing. Ook fout: formulieren die automatisch submitten zodra je een veld selecteert (bijvoorbeeld een dropdown die direct de pagina herlaadt). Geef gebruikers altijd een expliciete actie (knop) om een wijziging door te voeren.

Links en knoppen moeten duidelijk zijn. “Klik hier” zegt niets — beter: “Download het whitepaper” of “Bekijk onze pakketten”. Schermlezers kunnen een lijst van alle links op de pagina tonen; vage linkteksten zijn dan waardeloos.

Hulp bij invoer en foutafhandeling

begint bij duidelijke labels. Elk invoerveld heeft een <label> die beschrijft wat je moet invullen: <label for="email">E-mailadres</label><input id="email" type="email">. Geen placeholder-tekst als vervanger — die verdwijnt zodra je typt.

Foutmeldingen moeten specifiek en constructief zijn. Niet: “Fout in formulier”, maar: “E-mailadres ontbreekt: vul een geldig adres in (bijvoorbeeld: naam@voorbeeld.nl)”. Plaats de foutmelding direct bij het betreffende veld en markeer het visueel (rood kader + icoon + tekst).

Suggesties bij fouten: Als iemand een postcode verkeerd invult, geef dan een voorbeeld van het juiste formaat. Als een wachtwoord niet voldoet, lijst dan de eisen op (minimaal 8 tekens, één hoofdletter, etc.).

Bevestiging bij belangrijke acties: Voor onomkeerbare handelingen (betaling, account verwijderen) vraag je een bevestiging. Geef een overzicht van wat er gaat gebeuren en een mogelijkheid om terug te gaan.

Principe 4 – Robuust (Robust)

Robuust betekent dat je site compatibel is met huidige én toekomstige assistive technology. Dat vraag om schone, valide code.

Valide HTML is de basis. Fouten in de code (niet-gesloten tags, dubbele ID’s, verkeerde nesting) kunnen ervoor zorgen dat schermlezers content overslaan of verkeerd interpreteren. Valideer je HTML met de W3C Markup Validator.

ARIA-attributen (Accessible Rich Internet Applications) vullen semantische HTML aan waar nodig. Denk aan aria-label, aria-describedby, aria-live voor dynamische content. Gebruik ARIA spaarzaam: verkeerd toegepast creëert het meer problemen dan het oplost.

Doe dit: Gebruik aria-label als een visueel element geen tekstlabel heeft (bijvoorbeeld een zoek-icoon zonder tekst): <button aria-label="Zoeken"><svg>...</svg></button>. Gebruik aria-live="polite" voor statusmeldingen die moeten worden aangekondigd zonder de gebruiker te onderbreken.

Vermijd dit: div-soep met overal ARIA-rollen, terwijl je gewoon semantische HTML had kunnen gebruiken. Een <button> heeft geen role="button" nodig — dat is ingebouwd. Voeg ARIA alleen toe als HTML de functionaliteit niet dekt.

Name, Role, Value is de kern van robuustheid: elk interface-element moet een toegankelijke naam hebben (wat is het), een rol (wat doet het), en waar relevant een waarde (wat is de status). Semantische HTML regelt dit automatisch; custom components vereisen ARIA.

Compatibiliteit met schermlezers (NVDA, JAWS, VoiceOver) test je door ermee te navigeren. Het vereist oefening, maar het is de enige manier om écht te weten of je site werkt.

WCAG richtlijnen checklist: waar begin je mee?

Je hoeft niet morgen aan alle 78 WCAG-criteria te voldoen. Begin met de quick wins die de grootste impact hebben.

Prioriteit 1 – Basis (doe dit eerst): – Alt-teksten toevoegen aan alle informatieve afbeeldingen – Kleurcontrast controleren en aanpassen (tekst/achtergrond minimaal 4,5:1) – Toetsenbordnavigatie testen en repareren (Tab door hele site) – Formulieren van duidelijke labels voorzien – Heading-hierarchie controleren (H1, H2, H3 in logische volgorde)

Prioriteit 2 – Verdieping (daarna): – Skip-link toevoegen – Ondertiteling bij video’s – Foutmeldingen verbeteren (specifiek en constructief) – ARIA-attributen toevoegen waar semantische HTML tekortschiet – Valide HTML (W3C validator)

Prioriteit 3 – Optimalisatie (voor wie verder wil): – Transcripties bij audio – Audiodescriptie bij complexe video’s – Taal-attributen verfijnen – Keyboard shortcuts voor power-users – WCAG 2.2-criteria (focus-appearance, dragging movements)

Tools die helpen: – WAVE (browser-extensie) — visualiseert toegankelijkheids-issues direct op de pagina – Lighthouse (in Chrome DevTools) — geeft een accessibility-score met concrete verbeterpunten – WebAIM Contrast Checker — test kleurcontrast – HeadingsMap — toont heading-structuur – axe DevTools — uitgebreide accessibility-audit

Wanneer specialistische hulp? Als je een complexe webapplicatie hebt met custom components (datavisualisaties, interactieve dashboards, single-page apps), of als je een WCAG-audit nodig hebt voor aanbesteding of certificering. Een toegankelijkheidsspecialist voert gedetailleerde tests uit met echte schermlezers en assistive tech, en begeleid implementatie.

Veelgemaakte fouten en hoe je ze voorkomt

Deze vijf fouten zie je op bijna elke MKB-website:

1. Ontbrekende of nietszeggende alt-teksten – Fout: alt="IMG_1234.jpg" of helemaal geen alt-attribuut – Oplossing: Beschrijf wat de afbeelding toevoegt, niet hoe het bestand heet

2. Te weinig kleurcontrast – Fout: Lichtgrijze tekst op wit, pasteltinten over foto’s – Oplossing: Test met een contrastchecker, pas kleuren aan of voeg overlay toe

3. Geen toetsenbordnavigatie – Fout: Dropdown-menu’s die alleen met muis werken, ontbrekende focus-indicators – Oplossing: Test met Tab-toets, gebruik <button> en <a>, voeg keyboard-events toe

4. Onduidelijke foutmeldingen – Fout: “Er is iets misgegaan” of rode kleur zonder tekst – Oplossing: Benoem welk veld fout is en wat de gebruiker moet doen

5. Geen heading-structuur – Fout: Alle koppen zijn <div class="big-text">, of er zijn alleen maar H2’s – Oplossing: Gebruik H1 voor titel, H2 voor secties, H3 voor subsecties

CMS-specifieke issues (WordPress): Veel toegankelijkheidsproblemen zitten niet in je content, maar in je thema of plug-ins. Een page builder die <div>-soep genereert, een slider-plug-in zonder toetsenbord-support, of een contactformulier zonder labels — dit los je niet op door alt-teksten toe te voegen.

Controleer bij het kiezen van een WordPress-thema de toegankelijkheidsverklaring. Thema’s met de tag “accessibility-ready” in de WordPress repository zijn getest op basis-WCAG-criteria. Voor plug-ins: test ze altijd met toetsenbord en bekijk de HTML-output.

Veelgestelde vragen over wcag richtlijnen

Hoeveel WCAG richtlijnen zijn er in totaal?

WCAG 2.2 bevat 78 individuele succescriteria verdeeld over 13 WCAG richtlijnen en 4 principes. Niet alle WCAG richtlijnen zijn even relevant voor elke website: de meeste MKB-websites focussen op de 50 criteria van niveau A en AA.

Welke WCAG richtlijnen zijn het belangrijkst voor MKB?

De belangrijkste WCAG richtlijnen voor MKB-websites zijn: tekstalternatieven voor afbeeldingen (1.1), kleurcontrast (1.4.3), toetsenbordtoegankelijkheid (2.1) en begrijpelijke taal (3.1). Begin met deze WCAG richtlijnen voor de grootste impact.

Hoe vaak worden de WCAG richtlijnen bijgewerkt?

De WCAG richtlijnen worden door het W3C bijgewerkt. WCAG 2.0 verscheen in 2008, WCAG 2.1 in 2018 en WCAG 2.2 in 2023. Elke nieuwe versie bouwt voort op de vorige. De WCAG richtlijnen worden dus niet vaak maar wel grondig herzien.

Kan ik zelf controleren of mijn site aan WCAG richtlijnen voldoet?

Ja, je kunt zelf een eerste check doen met gratis tools die de belangrijkste WCAG richtlijnen controleren. Tools als WAVE en axe DevTools scannen automatisch op veelvoorkomende overtredingen. Voor een volledige WCAG richtlijnen-audit heb je wel een specialist nodig.

Conclusie

De WCAG richtlijnen zijn opgebouwd rond vier principes: waarneembaar, bedienbaar, begrijpelijk en robuust. Binnen die principes vind je concrete criteria voor alles van alt-teksten tot toetsenbordnavigatie, van kleurcontrast tot foutafhandeling.

Digitale toegankelijkheid is geen eenmalige klus die je afvinkt. Het is onderdeel van je workflow: elke nieuwe pagina, elke afbeelding, elk formulier vraagt om een toegankelijkheidscheck. Begin met de basis (alt-teksten, contrast, toetsenbord) en bouw van daaruit verder.

De impact gaat verder dan wettelijke verplichtingen. Een toegankelijke website is bruikbaar voor meer mensen, scoort beter in zoekmachines (Google waardeert semantische HTML en goede structuur), en voorkomt frustratie bij je bezoekers. Je investeert niet alleen in compliance, maar in een betere gebruikerservaring voor iedereen.

Start met de WCAG checklist uit dit artikel, test je belangrijkste pagina’s met de genoemde tools, en pak de quick wins aan. Elke verbetering telt.

Hulp nodig bij het toegankelijk maken van je website? Neem contact op voor ondersteuning bij digitale toegankelijkheid. We helpen je van audit tot implementatie.