EU Accessibility Act 2025 — wat MKB moet doen

Wat is de EAA precies?

De European Accessibility Act (richtlijn 2019/882) is in 2019 aangenomen, in nationale wet omgezet in 2022, en sinds 28 juni 2025 daadwerkelijk afdwingbaar. In Nederland heet de implementatie WTOEU — Wet toegankelijkheid producten en diensten EU. Doel: digitale producten en diensten moeten bruikbaar zijn voor mensen met een beperking — visueel, motorisch, auditief, cognitief.

Concreet betekent dat: WCAG 2.2 AA-conformiteit voor websites en apps die onder de scope vallen. WCAG is een internationale standaard met 50+ criteria — alt-tekst voor afbeeldingen, voldoende contrast (4.5:1 voor normale tekst), volledig bedienbaar met toetsenbord, foutmeldingen die door schermlezers gelezen worden, et cetera.

Voor wie geldt het — en voor wie niet?

De wet richt zich op B2C-aanbieders van consumentenproducten en -diensten. Onder de scope vallen:

• E-commerce — alle webshops die aan consumenten verkopen
• Online banking en betaaldiensten
• Ticketverkoop (bioscoop, OV, evenementen, concerten)
• E-readers en hun ecosystemen
• Computers, smartphones, betaalterminals
• Telecomdiensten (consumentenabonnementen)
• Audiovisuele media-diensten (websites van streaming-platforms)

Uitzondering: micro-bedrijven (minder dan 10 fte én minder dan €2M omzet of balanstotaal) zijn vrijgesteld voor diensten — niet voor producten. Dus een MKB-webshop met 8 medewerkers en €1.5M omzet hoeft formeel niet. Maar: vrijwillige naleving wordt sterk aanbevolen, en grotere klanten (B2B-keten) gaan het inkoopvoorwaarde maken.

Voor pure info-sites (één-pagina visitekaartjes, lokale dienstverleners zonder online transactie) is de juridische status grijs. De geest van de wet is duidelijk: WCAG 2.2 AA wordt de norm.

Wat zijn de boetes?

In Nederland handhaaft de Autoriteit Consument & Markt (ACM) plus de Inspectie Leefomgeving en Transport. Boetes lopen op tot €100.000 per overtreding via de WTOEU. Per lidstaat verschilt het:

• Duitsland: tot €100.000 + consumentenorganisaties kunnen civielrechtelijk vorderen
• Frankrijk: tot 4% van omzet (vergelijkbaar met AVG)
• België: tot €80.000 per overtreding

Daarnaast — vaak schadelijker dan de boete zelf — reputatieschade. Een Duitse rechtszaak die in NL wordt overgenomen door media. Een Tweakers-artikel over jouw onvindbare webshop. Voor MKB met goede naam in de regio is dat niet acceptabel.

WCAG 2.2 AA — wat houdt dat in voor MKB?

50+ criteria; de meeste komen neer op deze kerncategorieën:

Visueel

• Alt-tekst voor alle inhoudelijke afbeeldingen
• Contrast tekst/achtergrond minimaal 4.5:1 (normale tekst), 3:1 (grote tekst 18pt+)
• Geen informatie alleen via kleur (niet "klik op de groene knop" — geef ook tekst)
• Tekst herschaalbaar tot 200% zonder layout-breuk

Motorisch / toetsenbord

• Hele site bedienbaar met alleen toetsenbord (Tab, Enter, Pijltjes)
• Zichtbare focus-indicator op alle interactieve elementen
• Klikbare elementen minimaal 24x24px (WCAG 2.2-novum)
• Geen muis-only drag/hover-acties

Cognitief

• Foutmeldingen specifiek ("E-mailadres ontbreekt @-teken" — niet "ongeldige invoer")
• Geen sessie-timeouts onder 20 minuten zonder waarschuwing
• Heldere link-tekst ("Algemene voorwaarden" — niet "klik hier")
• Consistente navigatie tussen pagina's

Auditief

• Ondertiteling bij video's met spraak
• Geen automatisch afspelende audio langer dan 3 seconden

Wat ik (Lorenzo) zelf doe bij elke MKB-bouw

Bij DesignCheck nemen we WCAG 2.2 AA als baseline mee in elke build — refresh én rebuild. Concreet:

• Contrast tijdens design-fase getoetst in Figma plugin "Stark"
• Alt-tekst voor elke contentafbeelding ingevuld in CMS
• Toetsenbord-test in elke iteratie (Tab door hele pagina, werkt alles?)
• Focus-states zichtbaar en consistent
• Forms met `aria-describedby` voor foutmeldingen
• Skip-link bovenaan ("Naar inhoud")
• axe DevTools-scan vóór elke oplevering
• Toegankelijkheidsverklaring op de site (verplicht voor scope-bedrijven)

Voor een bestaande site kunnen we een EAA-compliance-audit doen — €450 vast, binnen 5 werkdagen. Daarin staat per pagina en per criterium wat scoort en wat fix nodig heeft. Veel MKB-eigenaren denken dat ze ver verwijderd zijn van compliance; meestal is het 10-20 fixes voor onder de €1.500.

De drie meest voorkomende fouten in MKB-sites

Uit ~50 audits in de regio Mijdrecht / De Ronde Venen / Utrecht in 2024-2026 zien wij steeds dezelfde issues:

1. Contrast onder 4.5:1 — vooral grijs-op-wit en "lichtblauwe link op witte achtergrond". Komt in 80% van de gevallen voor.
2. Geen alt-tekst op productfoto's of teamfoto's. Komt in 70% voor.
3. Focus-state onzichtbaar (vaak met `outline: none` in CSS). Komt in 60% voor.

Deze drie zijn meestal binnen één werkdag te fixen.

Wat kost niet-compliance je écht?

Naast de juridische boete: gemiste markt. 1 op de 6 mensen heeft een vorm van beperking. Een ontoegankelijke webshop sluit dus 17% van je potentiële klanten uit. Reken het door in de verliescalculator en je ziet vaak meer "lekkage" door slechte toegankelijkheid dan door slechte snelheid.

FAQ — EU Accessibility Act voor MKB

WCAG 2.2 in detail: de negen nieuwe criteria die in 2026 het meest opvallen

WCAG 2.2 voegt negen nieuwe criteria toe boven op WCAG 2.1. Voor MKB zijn vier ervan in de praktijk het meest relevant. Eén: focus appearance — een zichtbare focus-ring rondom een element moet een contrastverhouding van 3:1 hebben met de niet-gefocuste staat. Twee: target size — alle klikbare elementen moeten minimaal 24 bij 24 pixels meten, met uitzonderingen voor inline links in lopende tekst. Drie: dragging movements — elke functie die met drag werkt moet ook met een enkelvoudige klik bereikbaar zijn. Vier: consistent help — als je helpknoppen of contactlinks toont, moeten ze in dezelfde volgorde op elke pagina staan.

De andere vijf criteria spelen vooral bij forms en authenticatie (redundant entry, accessible authentication, focus not obscured). Voor pure marketing-sites zijn ze minder relevant; voor MKB met klantportals of webshops met inlog zijn ze allemaal van toepassing. Onze regel: audit elk formulier apart, niet alleen de homepage.

Toegankelijkheidsverklaring: wat erin moet en hoe je hem onderhoudt

Onder de WTOEU is een publieke toegankelijkheidsverklaring verplicht voor partijen die onder de scope vallen. De verklaring bevat: de scope (welke producten/diensten gedekt zijn), de huidige conformiteitsstatus (volledig, gedeeltelijk, niet), specifieke uitzonderingen met motivering, contactgegevens voor klachten en een verwijzing naar de handhavende instantie. Voor Nederlandse MKB is dat de Inspectie Leefomgeving en Transport voor algemene klachten en de ACM voor consumentenklachten.

De verklaring moet jaarlijks bijgewerkt worden. Een verouderde verklaring is op zichzelf een overtreding. Wij hosten bij DesignCheck-klanten een eenvoudige Markdown-pagina die per kwartaal automatisch een revisie-reminder geeft. Klein detail, maar het scheelt een handhavingsbrief bij wijzigingen aan de site die de conformiteitsstatus beïnvloeden.

Testen zonder bureau: gratis tools die je vandaag al kunt gebruiken

Drie tools zonder kosten waarmee je 80% van de WCAG-fouten zelf vindt. Eén: axe DevTools (browser-extensie van Deque). Klik op een pagina, krijg een rapport met fouten gesorteerd op ernst. Twee: WAVE (wave.webaim.org). URL invullen, visueel overzicht van fouten direct op de pagina. Drie: Lighthouse (in Chrome DevTools). Sectie "Accessibility" geeft een score van 0-100 en een lijst met verbeterpunten. De drie samen vinden de meeste duidelijke overtredingen.

Wat ze niet vinden: zaken die menselijke beoordeling vragen. Of een alt-tekst inhoudelijk klopt. Of de leesvolgorde van een complex layout-grid logisch is. Of een knop-tekst voor een blinde gebruiker begrijpelijk is. Voor die controle is een handmatige test met een schermlezer (VoiceOver op macOS, NVDA gratis op Windows) onmisbaar. Een uur per maand met een schermlezer leert meer over je site dan tien tools tegelijk.

• Houd je contrastverhouding minimaal 4.5:1 voor body-tekst en 3:1 voor grote tekst
• Zorg dat alle klikbare elementen minimaal 24 bij 24 pixels meten
• Maak focus-rings duidelijk zichtbaar met minstens 3:1 contrast met de pagina
• Geef elke afbeelding een alt-tekst — leeg als decoratief, beschrijvend als inhoudelijk
• Bedien je hele site uitsluitend met toetsenbord en check welke flows breken
• Vermijd CSS-regels die outlines uitzetten zonder vervangende focus-styling
• Gebruik semantische HTML (header, nav, main, footer) in plaats van losse divs
• Plaats een skip-link bovenaan elke pagina voor schermlezer-gebruikers
• Schrijf foutmeldingen die specifiek zijn over wat ontbreekt en hoe je het oplost
• Sluit foutmeldingen aan op formuliervelden via aria-describedby
• Test elke pagina met VoiceOver of NVDA en luister of de leesvolgorde klopt
• Onderhoud een toegankelijkheidsverklaring en update hem minstens jaarlijks
• Documenteer wijzigingen aan WCAG-relevante onderdelen in een changelog
• Train je content-redacteurs op alt-tekst-schrijven voor je ze toegang geeft tot het CMS
• Plan tweejaarlijks een externe WCAG-audit in om afdrijving te voorkomen

Toegankelijkheid en SEO: de overlap die vaak wordt onderschat

Een toegankelijke site is bijna altijd een SEO-vriendelijke site. Semantische HTML helpt Google de structuur begrijpen. Alt-teksten geven afbeeldingen vindbaarheid in Image Search en in AI-overviews. Heldere link-teksten geven crawlers context over de bestemming. Een H1-hiërarchie die werkt voor schermlezers werkt ook voor de algoritmes die je in featured snippets zetten. Wie WCAG serieus neemt, krijgt SEO als bijproduct.

Voor onze klant Keurmeesters levert dat een concreet effect. Het BAG-formulier dat we WCAG-conform hebben gebouwd scoort meetbaar hoger op long-tail-queries als "energielabel aanvragen huis [gemeente]" omdat de form-structuur correct is gemarkeerd, de error-states aria-described zijn, en de placeholders niet als labels misbruikt worden. Een conversiefunnel die voor schermlezers werkt is ook een conversiefunnel die voor Google-bots werkt.

Wat doe je vandaag?

• Run Lighthouse op je homepage en noteer de accessibility-score
• Voeg alt-tekst toe aan elke afbeelding die je in de afgelopen maand uploadde
• Tab door je hele site en check of elke focus-state zichtbaar is
• Schrijf of update je toegankelijkheidsverklaring en zet hem in de footer
• Plan een externe WCAG-audit als je site onder de EAA-scope valt en je hem niet recent hebt laten controleren

Schermlezers in 2026: VoiceOver, NVDA, JAWS — wat ze elk anders doen

Drie schermlezers domineren in 2026. VoiceOver komt standaard mee op macOS en iOS — ongeveer 70% van blinde Apple-gebruikers gebruikt het. NVDA is gratis voor Windows en heeft ongeveer 65% marktaandeel in de Windows-blind-community. JAWS is professioneel betaald (300-1500 euro) en wordt vooral in zakelijke en overheidscontexten gebruikt. Voor MKB-sites in productie testen we op alle drie omdat ze subtiel andere voor- en nadelen hebben. VoiceOver leest aria-attributen letterlijk, NVDA interpreteert ze contextueel, JAWS is het meest tolerant met onsemantische HTML.

Een element dat in VoiceOver correct werkt, kan in NVDA verwarrend overkomen als je rol-attributen ontbreken. Een gangbare fout: een knop die als div gestyled is met onclick-handler. VoiceOver kan hem klikken via "click", maar leest hem niet voor als knop. NVDA negeert hem volledig. JAWS leest hem als "groep" zonder klik-aanwijzing. De fix is simpel: gebruik een echte button-tag, of voeg role="button" en tabindex="0" toe aan de div. Semantische HTML is altijd beter dan ARIA-pleisters.

Forms en formulier-flows: de meest-overtreden plek voor WCAG

Een formulier is de meest interactieve plek op een MKB-site en daarmee de meest kwetsbare voor WCAG-overtredingen. Vijf veelvoorkomende issues. Eén: placeholder-tekst als labels gebruiken. Placeholders verdwijnen zodra je typt en zijn voor schermlezers vaak onzichtbaar. Twee: foutmeldingen die alleen in rode tekst staan zonder programmaticaal aan het veld gekoppeld zijn. Drie: required-velden die niet als verplicht zijn gemarkeerd via aria-required of via een visueel sterretje. Vier: select-dropdowns die niet met toetsenbord-pijltjes te navigeren zijn omdat ze custom JavaScript-componenten zijn. Vijf: datepickers die alleen via muis-klik werken.

De fix voor elk hiervan is documenteerbaar. Gebruik echte label-tags gekoppeld aan elk input via for/id. Koppel foutmeldingen via aria-describedby en aria-invalid. Markeer required-velden visueel én via aria-required. Vermijd custom-select-componenten — native select werkt vaak beter. En gebruik input type="date" of een gerenommeerde toegankelijke datepicker zoals Pikaday of Flatpickr (mits goed geconfigureerd).

Wat er ná WCAG 2.2 komt: een blik vooruit

WCAG 3.0 is in conceptfase sinds 2021 en wordt naar verwachting in 2027-2028 publiekelijk uitgebracht. De grote verschuiving: van pass/fail per criterium naar een score-gebaseerd model met outcomes per gebruikersgroep. In plaats van "compliant of niet" krijg je een score van 0-100 per gebruikerstype (visueel beperkt, motorisch beperkt, cognitief beperkt). Voor MKB-bedrijven betekent dat in de toekomst: meer nuance, hogere lat, en meer documentatie-verplichtingen.

Voor de korte termijn is WCAG 2.2 AA echter de norm en blijft dat tot minstens 2028. Wie nu compliant wordt, heeft daar tot dan rust op. WCAG 3.0 zal compatibel zijn — niemand bouwt zonder migratiepad. Investeer dus zonder zorg in de huidige standaard; hij geldt nog jaren.

Verder lezen

Wij bouwen MKB-sites WCAG 2.2 AA-conform als baseline. Voor Keurmeesters levert dat naast wettelijke compliance ook meetbare SEO-winst op long-tail-queries. Bekijk de prijzen of vraag een gratis audit aan.

Door Lorenzo Ruisi — DesignCheck Mijdrecht. Laatst bijgewerkt 16 mei 2026.