Websites van veel bedrijven en overheden moeten sinds 28 juni 2025 voldoen aan de Europese Toegankelijkheidswet en aan WCAG 2.1 niveau A en AA. Wie een consumentgerichte dienst aanbiedt en meer dan tien medewerkers of meer dan 2 miljoen euro omzet heeft, valt bijna zeker onder de verplichting. De Autoriteit Consument & Markt controleert en kan boetes opleggen; micro-ondernemingen zijn vrijgesteld, maar alleen als ze aan beide criteria voldoen.
Kort samengevat:
- Organisaties met meer dan tien medewerkers of een omzet hoger dan 2 miljoen euro moeten vanaf 28 juni 2025 voldoen aan WCAG 2.1 niveau AA en de Europese Toegankelijkheidswet.
- Een website die alleen aan WCAG voldoet, voldoet niet automatisch aan EN 301 549, die aanvullende eisen stelt voor onderdelen zoals video en chat.
- Een automatische scan detecteert ongeveer 30 tot 50 procent van de problemen; handmatige testen met gebruikers met een handicap zijn essentieel voor volledige beoordeling.
- Het opstellen van een toegankelijke verklaring en een duidelijk proces voor meldingen is wettelijk verplicht en moet zichtbaar op de website worden geplaatst.
- Toegankelijkheid achteraf repareren kost meer; bij het vanaf nul bouwen kun je veel fouten voorkomen door meteen een goede, semantische code en structuur te gebruiken.
Inhoudsopgave
- Wettelijk kader: EAA, Wet digitale overheid en EN 301 549
- Voor wie geldt de verplichting en wanneer geldt een vrijstelling?
- WCAG in de praktijk: de vier principes en concrete verplichtingen
- Toegankelijkheidsverklaring: wat erin moet en waar je die publiceert
- Praktisch stappenplan: van scan naar roadmap
- Testen en bewijs: automatische scans en handmatige audits
- Tijdslijnen en handhaving: data en sancties
- Richtlijnen voor mobiele toegankelijkheid
- De rol van gebruikers met een handicap bij het testen
- Veelvoorkomende obstakels en hoe je ze oplost
- Praktijkperspectief van Durfmakers: waarom toegankelijkheid vanaf het begin goedkoper is
- Een toegankelijke website zonder gedoe: hoe Durfmakers dat aanpakt
- Bronnen
- Veelgestelde vragen
Wettelijk kader: EAA, Wet digitale overheid en EN 301 549
De Europese Toegankelijkheidswet (European Accessibility Act, EAA) is de basis. Deze Europese richtlijn is in Nederland vertaald naar nationale regels, waaronder de Wet digitale overheid en het Tijdelijk besluit digitale toegankelijkheid overheid. Sinds 28 juni 2025 gelden deze regels voor een brede groep organisaties, niet alleen voor de overheid.
De technische invulling loopt via EN 301 549, de Europese norm voor toegankelijke ICT-producten en -diensten. Voor websites neemt deze norm grotendeels WCAG 2.1 over, maar voegt eisen toe voor onderdelen als video en chatfunctionaliteit. Daardoor is een site die alleen aan WCAG voldoet niet automatisch volledig compliant met EN 301 549.
WCAG 2.2 is inmiddels beschikbaar en bevat extra criteria voor gebruiksgemak. Toch blijft WCAG 2.1 niveau AA de wettelijke norm. Bouw je nu, dan is het slim om meteen op WCAG 2.2 te richten: dat scheelt een herbeoordeling zodra de norm wordt aangescherpt.
Voor wie geldt de verplichting en wanneer geldt een vrijstelling?
De verplichting raakt organisaties die een consumentgerichte digitale dienst aanbieden, denk aan webshops, bankdiensten, reisboekingen of overheidsloketten. Naast de aard van de dienst spelen twee drempels: het aantal medewerkers en de jaaromzet of het balanstotaal.
Micro-ondernemingen zijn vrijgesteld, maar alleen wanneer beide voorwaarden gelden: minder dan tien werknemers én een omzet of balanstotaal van maximaal 2 miljoen euro. Heb je twaalf medewerkers maar een kleine omzet, dan val je toch onder de verplichting.
Twijfel je of jouw organisatie meetelt? Documenteer de afweging schriftelijk, voer alvast een toegankelijkheidsscan uit en bewaar het resultaat. Die documentatie is je bewijs richting toezichthouders én richting klanten die vragen stellen over jouw toegankelijkheidsverklaring.
WCAG in de praktijk: de vier principes en concrete verplichtingen
WCAG 2.1 bouwt op vier principes: waarneembaar, bedienbaar, begrijpelijk en robuust. Elk principe krijgt toetsbare succescriteria op niveau A, AA en AAA, waarbij de wet niveau AA vraagt.
In de praktijk betekent dat concrete, herkenbare punten. Afbeeldingen hebben een alt-tekst nodig die de inhoud beschrijft, niet alleen de bestandsnaam. Tekst en achtergrond moeten voldoende kleurcontrast hebben, zodat ook slechtziende bezoekers de tekst kunnen lezen. Elke functie moet met het toetsenbord te bedienen zijn, want niet iedereen gebruikt een muis. Formuliervelden horen een duidelijk label te hebben, en video's moeten ondertiteling bevatten als losse laag, niet ingebakken in het beeld.
Semantische HTML is minstens zo belangrijk als deze losse punten. Een pagina die koppen, knoppen en navigatie correct markeert, is direct bruikbaar voor schermlezers. Een consistente kopstructuur (H1, H2, H3 in logische volgorde) helpt gebruikers van hulpsoftware om snel te navigeren, en scheelt achteraf veel reparatiewerk.
Toegankelijkheidsverklaring: wat erin moet en waar je die publiceert
Elke organisatie die onder de verplichting valt, publiceert een toegankelijkheidsverklaring. Die verklaring beschrijft de status van de website, benoemt bekende beperkingen en geeft contactgegevens voor meldingen.
Overheidsorganisaties publiceren hun verklaring in het register van Logius. Andere organisaties plaatsen de verklaring meestal op de eigen site, vaak in de footer of bij de contactpagina.
Naast publiceren hoort er een proces bij voor meldingen. Een bezoeker die een barrière tegenkomt, moet ergens terechtkunnen. Leg vast wie meldingen ontvangt, binnen welke termijn je reageert en hoe je opvolging documenteert. Dat proces is niet alleen een wettelijke plicht, het is ook het snelste signaal dat je iets over het hoofd hebt gezien.
Praktisch stappenplan: van scan naar roadmap
Begin altijd met een automatische scan. Die geeft binnen minuten een lijst met technische knelpunten en helpt je prioriteren voordat je tijd steekt in handmatig werk.
- Voer een gratis scan uit en noteer welke fouten het vaakst voorkomen.
- Pak de quick wins eerst aan: ontbrekende alt-teksten, te laag contrast, onduidelijke linkteksten ("klik hier") en formulieren zonder labels.
- Herstel de kopstructuur zodat H1 tot H3 een logische, navigeerbare hiërarchie vormen.
- Werk aan diepere problemen: toetsenbordnavigatie testen, semantische code herstellen en ondertiteling toevoegen aan video's. Dit vraagt meer uren en specifieke kennis dan de quick wins.
- Leg verantwoordelijkheid vast in een roadmap met eigenaren en deadlines per punt, zodat toegankelijkheid geen eenmalige actie blijft maar onderdeel van het onderhoud.
Pro-tip: Wacht niet tot de audit klaar is om te beginnen. Herstel de eerste tien fouten uit de scan zodra je ze ziet: dat kost een middag en scheelt weken wachten op de definitieve rapportage.
Testen en bewijs: automatische scans en handmatige audits
Een automatische scan is een goed startpunt, maar geen volledig bewijs. Dit type tool detecteert doorgaans 30 tot 50 procent van de werkelijke toegankelijkheidsproblemen, vooral de technisch meetbare fouten zoals ontbrekende alt-teksten of foutieve HTML.
Wat een scan mist, zijn gebruikservaringen: kan iemand die alleen het toetsenbord gebruikt daadwerkelijk door het bestelproces heen komen? Werkt de schermlezer logisch bij een ingewikkeld formulier? Dat beoordeel je alleen met handmatige toetsing en, idealiter, met testers die de hulpmiddelen dagelijks gebruiken. Voor een toegankelijkheidsverklaring die stand houdt bij een controle, combineer je dus altijd een scan met een handmatige audit.
Tijdslijnen en handhaving: data en sancties
De EAA is sinds 28 juni 2025 van kracht in Nederland. Voor bestaande diensten gelden overgangsperioden, maar nieuwe websites en digitale diensten moeten vanaf de start voldoen.
De ACM houdt toezicht en kan bij overtredingen boetes opleggen tot 900.000 euro, afhankelijk van de aard en omvang van de overtreding. Krijg je een handhavingsverzoek of klacht binnen, reageer dan snel en met een concreet herstelplan. Toezichthouders kijken niet alleen naar de huidige staat van je site, maar ook naar hoe serieus je de melding oppakt.
Richtlijnen voor mobiele toegankelijkheid
WCAG maakt geen onderscheid tussen desktop en mobiel: dezelfde succescriteria gelden voor beide. In de praktijk vraagt een telefoonscherm wel om extra aandacht op een aantal punten.
Klikbare elementen moeten groot genoeg zijn om met een vinger te bedienen, ook voor mensen met beperkte fijne motoriek. Een knop van acht bij acht pixels werkt op een muis, maar mist op een telefoon voortdurend zijn doel. Zoomen moet mogelijk blijven zonder dat de lay-out breekt: veel mobiele sites blokkeren pinch-to-zoom, wat slechtziende bezoekers direct buitensluit.
Focusvolgorde is een ander mobiel knelpunt. Wie navigeert met een externe toetsenbord of schakelhulpmiddel, moet door menu's en formulieren kunnen bewegen in een volgorde die logisch aanvoelt, niet in de volgorde waarin elementen toevallig in de code staan. Ook responsive content mag geen tekst of knoppen verbergen die alleen met precieze vingerbewegingen bereikbaar zijn.
Test mobiele toegankelijkheid dus apart van desktop, met een echt toestel en niet alleen met de browser-simulator. Wat op een breed scherm goed werkt, faalt regelmatig op een klein scherm met een trage verbinding.
De rol van gebruikers met een handicap bij het testen
Automatische scans en handmatige checklists dekken veel, maar niet alles. De enige manier om te weten of een website écht werkt, is testen met mensen die dagelijks een schermlezer, een braille-leesregel of een schakelhulpmiddel gebruiken.
Deze testers vinden knelpunten die een checklist mist: een menu dat technisch "voldoet" aan WCAG, maar in de praktijk verwarrend navigeert, of een foutmelding die wel voorleesbaar is maar niet duidelijk maakt welk veld fout is ingevuld. Betrek deze gebruikers vroeg in het proces, niet pas als laatste controle vlak voor livegang. Zo kost herstel minder tijd en geld dan wanneer je pas na oplevering ontdekt dat een kernfunctie onbruikbaar is.
Werk je met een extern bureau of testpanel, leg dan vooraf vast wie welke verantwoordelijkheid draagt. Onduidelijke afspraken over wie welke test uitvoert en wie eventuele fouten herstelt, leiden achteraf vaak tot discussie over scope en kosten. Een goed gedocumenteerde testfase met echte gebruikers is ook precies het soort bewijs dat een toezichthouder wil zien bij een controle van je toegankelijkheidsverklaring.
Veelvoorkomende obstakels en hoe je ze oplost
De meeste toegankelijkheidsproblemen komen terug in elk auditrapport. Een paar voorbeelden, en de directe oplossing:
- Afbeeldingen zonder alt-tekst. Een schermlezer slaat de afbeelding dan gewoon over of leest de bestandsnaam voor. Oplossing: voeg een korte, beschrijvende alt-tekst toe die de functie of inhoud van de afbeelding weergeeft.
- Laag kleurcontrast. Grijze tekst op een witte achtergrond ziet er rustig uit, maar is voor veel bezoekers onleesbaar. Oplossing: gebruik een contrastchecker en houd je aan de minimale ratio's uit WCAG.
- Formulieren zonder labels. Een invoerveld met alleen een placeholder-tekst verdwijnt zodra iemand begint te typen, en een schermlezer koppelt de placeholder vaak niet aan het veld. Oplossing: geef elk veld een zichtbaar, gekoppeld label.
- Niet-beschrijvende links. "Klik hier" of "lees meer" zegt niets buiten de context. Oplossing: maak linkteksten die op zichzelf duidelijk zijn, zoals "download het jaarverslag".
- Video zonder ondertiteling als losse laag. Ingebakken tekst in het beeld is niet uitschakelbaar en niet doorzoekbaar. Oplossing: voeg een ondertitelbestand toe dat gebruikers zelf aan of uit kunnen zetten.
- Onlogische kopstructuur. Een pagina die van H1 direct naar H4 springt, verwart navigatie met hulpsoftware. Oplossing: herstel de hiërarchie zodat koppen een logische boomstructuur vormen.
Elk van deze problemen is op zichzelf klein. Samen bepalen ze wel of een website daadwerkelijk bruikbaar is voor iedereen, of alleen op papier voldoet.
Praktijkperspectief van Durfmakers: waarom toegankelijkheid vanaf het begin goedkoper is
Toegankelijkheid achteraf repareren kost meer dan hem meteen goed bouwen. Verkeerde HTML-structuur, ontbrekende labels en foute kopvolgorde zitten vaak diep in de code verweven, en dat maak je niet los met een simpele plug-in. Bouw je een site vanaf nul met de juiste structuur, dan voorkom je die rekening.
— Patrick
Een toegankelijke website zonder gedoe: hoe Durfmakers dat aanpakt
Durfmakers draait het proces om. Waar veel bureaus eerst een offerte en aanbetaling vragen, bouwt Durfmakers de website volledig af en laat hem zien op een testadres. Je beoordeelt de site zoals hij écht wordt, inclusief structuur en techniek, voordat je ook maar een euro betaalt.
Voor organisaties die onder de toegankelijkheidsverplichting vallen, is dat een praktisch voordeel: je ziet vooraf of de basis klopt, in plaats van achteraf te ontdekken dat een extern gebouwde site vol technische gebreken zit. Actuele prijsinformatie is te vinden op de website van de aanbieder. Na betaling krijg je het eigendom van broncode en ontwerp, zodat je ook zelf kunt laten toetsen op WCAG 2.1 AA. Wil je weten wat een toegankelijke, goed gebouwde website voor jouw organisatie kan doen? Bekijk de werkwijze van Durfmakers en vraag een vrijblijvende kennismaking aan.
Bronnen
Veelgestelde vragen
Hoe moet een website toegankelijk zijn volgens de wet?
Een website is wettelijk toegankelijk als hij voldoet aan WCAG 2.1 niveau A en AA, verwerkt in de norm EN 301 549. Dat betekent onder meer werkende alt-teksten, voldoende kleurcontrast, volledige toetsenbordbediening en een logische koppenstructuur.
Wat zijn de wettelijke eisen voor een website in Nederland?
De belangrijkste eis is naleving van WCAG 2.1 AA, verplicht via de Europese Toegankelijkheidswet en de Wet digitale overheid. Daarnaast moet je een toegankelijkheidsverklaring publiceren met de status van je site en contactgegevens voor meldingen.
Is toegankelijkheid wettelijk verplicht?
Ja, sinds 28 juni 2025 is dit wettelijk verplicht voor veel consumentgerichte diensten en voor overheidsorganisaties, met boetes tot 900.000 euro bij overtreding. Micro-ondernemingen met minder dan tien medewerkers én maximaal 2 miljoen euro omzet zijn vrijgesteld.
Wat zijn de vier principes van toegankelijkheid?
WCAG onderscheidt waarneembaar, bedienbaar, begrijpelijk en robuust. Elk principe krijgt concrete, toetsbare succescriteria die samen bepalen of een website daadwerkelijk voor iedereen te gebruiken is.
Kan Durfmakers een toegankelijke website bouwen?
Durfmakers bouwt websites met een schone, semantische code als basis, wat de eerste stap is richting WCAG 2.1 AA. Je bekijkt de afgeronde site eerst op een testadres via Durfmakers en betaalt alleen als je hem wilt houden.