Website toegankelijkheid: EAA en WCAG uitgelegd

Sinds 28 juni 2025 verplicht de European Accessibility Act (EAA) dat elke zakelijke website en app in de EU voldoet aan WCAG 2.1 AA-normen. Niet naleven betekent boetes, juridische claims en uitsluiting van overheidsaanbestedingen. Toch weet het merendeel van de MKB-ondernemers niet precies wat er moet gebeuren — of wat het kost om hun site op orde te brengen.

Dit artikel legt uit wat de EAA vereist, hoe WCAG werkt, welke fouten je als eerste moet fixen, en wat de kosten zijn om je website of app conform te maken. Geen juridisch jargon, wel concrete checklists en cijfers.

Wat vereist de EAA — en wat specificeert WCAG?

Veel ondernemers halen de twee door elkaar, maar het onderscheid is essentieel:

• EAA (European Accessibility Act) is de Europese verordening die zegt wat je moet doen. Het is de wet: je bent verplicht om je digitale producten en diensten toegankelijk te maken. De Nederlandse implementatie loopt via het Besluit Europese Toegankelijkheidseisen.
• WCAG (Web Content Accessibility Guidelines) is de technische standaard die beschrijft hoe je dat doet. WCAG is ontwikkeld door het W3C en bevat concrete criteria waaraan je website moet voldoen.

De EAA schrijft WCAG 2.1 AA voor als minimumnorm. WCAG 2.2, uitgebracht in oktober 2023, voegt verbeteringen toe rond mobiele bediening en focusindicatoren. Nieuwe websites doen er verstandig aan om direct op WCAG 2.2 AA te mikken.

Voor wie geldt de EAA?

De wet is van toepassing op elk bedrijf dat producten of diensten aan consumenten aanbiedt via websites of apps. Denk aan webshops, dienstverleningssites, boekingsplatformen, en klantportalen. Er geldt een beperkte uitzondering voor micro-ondernemingen: bedrijven met minder dan 10 medewerkers en minder dan €2 miljoen jaaromzet. Alle andere bedrijven — ook die in het MKB — vallen onder de verplichting.

Heb je een website laten bouwen zonder op toegankelijkheid te letten? Dan ben je niet automatisch vrijgesteld. De verantwoordelijkheid ligt bij de eigenaar van de website, niet bij het bureau dat hem heeft gebouwd. Meer over wat een goede website moet bevatten vind je in ons complete kostenoverzicht voor websites in 2026.

De 4 WCAG-principes — POUR

WCAG is opgebouwd rond vier principes. Elk principe bevat concrete richtlijnen en succescriteria. Dit is het kader waarmee je elke toegankelijkheidsvraag kunt benaderen.

Perceivable (Waarneembaar)

Content moet presenteerbaar zijn voor alle zintuigen. Als iemand een afbeelding niet kan zien, moet er een alternatieve tekst zijn. Als iemand een video niet kan horen, moeten er ondertitels zijn.

Voorbeelden: alt-teksten op afbeeldingen, ondertiteling bij video's, voldoende kleurcontrast (minimaal 4.5:1 voor normale tekst), content die niet alleen op kleur vertrouwt om informatie over te brengen.

Operable (Bedienbaar)

De interface moet werken met toetsenbord, muis, en hulptechnologie. Iemand die geen muis kan gebruiken, moet elk onderdeel van je site kunnen bereiken via de Tab-toets.

Voorbeelden: volledige toetsenbordnavigatie, skip-links om herhaalde navigatie over te slaan, geen content die epileptische aanvallen kan veroorzaken (knipperende elementen), voldoende tijd om content te lezen.

Understandable (Begrijpelijk)

Content en interface moeten voorspelbaar en duidelijk zijn. Een formulier dat na het invullen een vage foutmelding geeft ("Er ging iets mis"), helpt niemand.

Voorbeelden: heldere taal, consistente navigatie door de hele site, duidelijke foutmeldingen met uitleg wat je moet corrigeren, labels op alle formuliervelden.

Robust (Robuust)

Content moet werken met huidige en toekomstige hulptechnologieën. Dat betekent valide HTML, correcte ARIA-rollen, en semantische structuur.

Voorbeelden: correcte heading-hiërarchie (H1, H2, H3 — niet zomaar willekeurig), ARIA-labels op custom componenten, HTML dat valideert zonder fouten. Dit principe heeft een sterke overlap met technische website-beveiliging, waar valide code ook een rol speelt.

De 10 meest voorkomende toegankelijkheidsproblemen

Uit een analyse van meer dan 1 miljoen homepages door WebAIM (2025) blijkt dat dezelfde fouten steeds terugkomen. Hier is het overzicht:

Het goede nieuws: zes van de tien problemen zijn eenvoudig op te lossen. De meeste vergen geen herontwerp — alleen aandacht en consequentheid. Bij het bouwen van een nieuwe site kun je deze fouten volledig voorkomen door toegankelijkheid vanaf dag één mee te nemen. Dat is precies wat een headless CMS-aanpak mogelijk maakt: volledige controle over de HTML-output.

Zelfscan checklist — 15 punten

Voordat je een extern bureau inschakelt, kun je zelf een eerste scan doen. Loop deze 15 punten langs:

1. Tab door je hele website — kun je elk interactief element bereiken met alleen het toetsenbord?
2. Controleer alt-teksten — heeft elke afbeelding een beschrijvende alt-tekst (of een lege alt="" als het decoratief is)?
3. Meet contrastverhoudingen — minimaal 4.5:1 voor normale tekst, 3:1 voor grote tekst. Gebruik de gratis WebAIM Contrast Checker.
4. Test met een screenreader — VoiceOver op Mac/iOS, NVDA op Windows (gratis). Navigeer je site en controleer of alle content begrijpelijk wordt voorgelezen.
5. Controleer formulierlabels — heeft elk invoerveld een zichtbaar label (niet alleen placeholder-tekst)?
6. Verifieer heading-hiërarchie — gaat je site van H1 naar H2 naar H3 zonder niveaus over te slaan?
7. Test video-ondertiteling — als je video's hebt, zijn er ondertitels?
8. Check skip-to-content link — is er een "direct naar content"-link bovenaan de pagina voor toetsenbordgebruikers?
9. Inspecteer focusindicatoren — is er een zichtbare omlijning wanneer je door interactieve elementen tabt?
10. Test bij 200% zoom — is alle content nog leesbaar en bruikbaar als je de browser op 200% zet?
11. Controleer lang-attribuut — staat lang="nl" (of de juiste taal) in het HTML-element?
12. Verifieer foutmeldingen — zijn formulierfouten beschrijvend ("Vul een geldig e-mailadres in" in plaats van "Fout")?
13. Test alle interactieve elementen — dropdowns, modals, accordions, sliders: allemaal met toetsenbord bedienbaar?
14. Check ARIA-rollen — hebben custom componenten (geen standaard HTML) de juiste ARIA-attributen?
15. Draai een Lighthouse audit — open Chrome DevTools, ga naar "Lighthouse", en draai de Accessibility-audit. Mik op 90+.

Wat kost het — achteraf repareren vs. direct goed bouwen?

De kosten hangen sterk af van de huidige staat van je website. Hier zijn realistische ranges voor het Nederlandse MKB:

Bestaande website toegankelijk maken (retrofit)

Nieuwe website direct toegankelijk bouwen

Toegankelijkheid meenemen vanaf het begin voegt 10-15% toe aan de projectkosten. Op een gemiddeld MKB-websiteproject betekent dat:

• Brochurewebsite: +€500 – €1.000
• Zakelijke website: +€1.000 – €2.000
• Webshop: +€1.500 – €3.000

Het verschil is duidelijk: vooraf bouwen kost een fractie van achteraf repareren. Benieuwd wat een website in totaliteit kost? Ons artikel over websitekosten in 2026 geeft een volledig overzicht.

Vergelijking met het risico

Niet compliant zijn kost je meer dan de fix. De risico's:

• Boetes: De EAA voorziet in sancties die per lidstaat worden vastgesteld. In Nederland worden de bedragen nog definitief bepaald, maar de Europese richtlijn schrijft voor dat boetes "doeltreffend, evenredig en afschrikwekkend" moeten zijn.
• Juridische claims: Consumenten kunnen je aanspreken als je site niet toegankelijk is.
• Gemiste omzet: 15-20% van je potentiële klanten heeft een beperking die invloed heeft op webgebruik.

Testtools die je vandaag kunt gebruiken

Automatische tools vangen 30-40% van alle toegankelijkheidsproblemen op. De rest vereist handmatige controle. Gebruik deze combinatie:

Gratis tools

• axe DevTools — browserextensie voor Chrome en Firefox. Scant de huidige pagina en toont WCAG-overtredingen met uitleg en fix-suggesties. De beste gratis tool.
• WAVE — web-based tool van WebAIM. Visuele overlay die problemen direct op de pagina markeert. Goed voor een snelle eerste scan.
• Lighthouse — ingebouwd in Chrome DevTools. De accessibility-audit geeft een score van 0-100 met specifieke verbeterpunten.

Screenreaders (handmatige test)

• VoiceOver — ingebouwd in macOS en iOS. Activeer met Cmd + F5 op Mac.
• NVDA — gratis, open-source screenreader voor Windows. De standaard voor professioneel testen.
• TalkBack — ingebouwd in Android. Activeer via Instellingen > Toegankelijkheid.

De 30/70-regel

Automatische tools zijn essentieel maar niet voldoende. Ze detecteren objectieve problemen (contrast, ontbrekende alt-tekst, ontbrekende labels), maar missen subjectieve kwesties (is de alt-tekst beschrijvend genoeg? Is de tabvolgorde logisch? Is de content begrijpelijk?).

Plan dus altijd een handmatige test naast de automatische scan. De keuze tussen no-code en maatwerk speelt hier ook een rol: maatwerksites geven je volledige controle over de HTML-output, terwijl no-code platforms je soms beperken in wat je kunt aanpassen voor toegankelijkheid.

Handhaving in Nederland

De toezichthouder Digitale Toegankelijkheid, ondergebracht bij het ministerie van Binnenlandse Zaken, houdt toezicht op de naleving. Dit is het handhavingslandschap:

Overheid (al verplicht sinds 2018): De publieke sector moet al sinds het Besluit digitale toegankelijkheid (2018) voldoen aan WCAG 2.1 AA. Dat geldt voor rijksoverheid, gemeenten, provincies, waterschappen en andere overheidsinstanties. Hier wordt actief op gecontroleerd.

Private sector (EAA — sinds juni 2025): Commerciële websites en apps moeten sinds 28 juni 2025 voldoen. De handhaving is in de opstartfase klachtengestuurd: er wordt vooral opgetreden na meldingen van consumenten. Verwacht dat het toezicht de komende jaren intensiveert, vergelijkbaar met hoe AVG-handhaving geleidelijk strenger werd.

Markttoezicht: De Europese Commissie coördineert de handhaving tussen lidstaten. Grote platforms die in meerdere EU-landen opereren, worden op Europees niveau gemonitord.

Dit is vergelijkbaar met hoe de AI-wetgeving in Nederland stapsgewijs wordt ingevoerd — eerst regels, dan bewustwording, dan handhaving.

De business case voorbij compliance

Toegankelijkheid is geen kostenpost — het is een investering die meetbaar rendeert:

Bereik: Wereldwijd leven 1,3 miljard mensen met een beperking. In Nederland zijn dat meer dan 2 miljoen mensen. Als je website niet toegankelijk is, sluit je 15-20% van je potentiële doelgroep uit.

SEO: Er is een directe overlap tussen toegankelijkheid en zoekmachineoptimalisatie. Heading-structuur, alt-teksten, semantische HTML, mobiel-vriendelijk ontwerp — het zijn stuk voor stuk factoren die zowel de toegankelijkheid als je vindbaarheid verbeteren. Wie de beveiliging van zijn website op orde heeft, plukt daar ook SEO-vruchten van — en hetzelfde geldt voor toegankelijkheid.

Mobiel: Toegankelijk ontwerp is inherent beter mobiel ontwerp. Grote knoppen, duidelijke labels, leesbare tekst, logische navigatie — precies wat mobiele gebruikers verwachten.

Conversie: Duidelijkere CTA's, betere formulieren, leesbare content en logische navigatie leiden tot 20-30% hogere conversieratio's. Toegankelijkheid is in feite UX-optimalisatie voor iedereen.

App-toegankelijkheid

De EAA geldt niet alleen voor websites. Mobiele apps vallen er ook onder. Hier zijn de belangrijkste aandachtspunten per platform:

iOS

• VoiceOver-ondersteuning: Elk interactief element moet een accessibility label en hint hebben.
• Dynamic Type: Tekst moet meeschalen als de gebruiker een groter lettertype instelt in iOS-instellingen.
• Aanraakdoelen: Minimaal 44x44 punten voor knoppen en links. Kleinere elementen zijn onbetrouwbaar voor gebruikers met motorische beperkingen.
• Kleurblindheid: Informatie mag niet alleen via kleur worden overgebracht. Gebruik ook iconen, patronen of tekst.

Android

• TalkBack-ondersteuning: Content descriptions op alle visuele elementen, correcte focusvolgorde.
• Font-schaling: Respecteer de systeeminstelling voor lettergrootte.
• Focusbeheer: Navigatie met de d-pad of externe toetsenbord moet logisch en compleet zijn.

Cross-platform (React Native / Flutter)

Beide frameworks bieden accessibility-API's. React Native heeft accessibilityLabel, accessibilityRole, en accessibilityState. Flutter heeft Semantics widgets. Het risico bij cross-platform: je moet op beide platformen handmatig testen, omdat de vertaling van accessibility-properties per platform verschilt.

Meer weten over app-ontwikkeling en de keuze tussen native en cross-platform? Lees onze complete gids voor het laten maken van een app.

Volgende stappen

Website-toegankelijkheid is geen eenmalig project maar een doorlopend proces. Begin met de zelfscan, prioriteer de meest impactvolle problemen (contrast, alt-teksten, toetsenbordnavigatie), en bouw toegankelijkheid in je ontwikkelworkflow in.

Als je een nieuwe website of app laat bouwen, neem toegankelijkheid dan op in je briefing. Het verschil tussen een toegankelijke en een niet-toegankelijke website is niet zichtbaar op het eerste gezicht — maar het bepaalt wel of 100% of 80% van je bezoekers je site daadwerkelijk kan gebruiken.

Wij bouwen websites en apps die standaard voldoen aan WCAG 2.1 AA. Geen meerkosten achteraf, geen retrofit. Als je twijfelt of je huidige website voldoet aan de EAA, beginnen we met een gratis toegankelijkheidsscan.