Van de naleving van de Europese Toegankelijkheidswet (EAA) naar duurzame digitale toegankelijkheid

Blog

28 juni 2025: de deadline voor de Europese Toegankelijkheidswet (EAA) ligt achter ons. Veel organisaties hebben hard gewerkt om op tijd te voldoen aan de toegankelijkheidsrichtlijnen. Maar dit moment is geen eindpunt. Sterker nog, het is het startschot voor het échte werk.

Ik merk gelukkig al verbeteringen. Steeds meer websites werken goed samen met schermlezers. Maar nog steeds zijn er obstakels. Zo kon laatst een groep slechtziende gebruikers online aankopen niet afronden vanwege een ontoegankelijke CAPTCHA. Dit laat zien dat technische naleving niet automatisch betekent dat de gebruikerservaring goed is.

De boodschap is helder: het gaat niet alleen om het voldoen aan regels. Het gaat om digitale ervaringen creëren die écht toegankelijk zijn. Voor iedereen.


Waar voldoe je eigenlijk aan met de EAA?

De EAA verplicht organisaties in de EU om digitale producten en diensten toegankelijk te maken volgens WCAG (Web Content Accessibility Guidelines) 2.1 niveau AA. Deze richtlijn is onderverdeeld in drie niveaus:

  • Niveau A: het minimum; basisvoorwaarden om toegang überhaupt mogelijk te maken.
  • Niveau AA: pakt de belangrijkste belemmeringen aan. Dit is de wettelijke standaard binnen de EU.
  • Niveau AAA: het hoogste niveau, vooral geschikt voor specifieke doelgroepen, maar moeilijk volledig toepasbaar op alle soorten content.

Door aan niveau AA te voldoen, zorg je ervoor dat je digitale diensten bruikbaar zijn voor een brede groep mensen met een beperking. Maar het echte verschil maak je door toegankelijkheid niet als vinkje te zien, maar als ontwerpprincipe.


De vier pijlers van toegankelijkheid (POUR)

De WCAG-richtlijnen zijn gebaseerd op vier principes, samengevat in het acroniem POUR. Elk principe vraagt aandacht in ontwerp, content en techniek.


1. Waarneembaar (perceivable)

Informatie moet voor iedereen zintuiglijk toegankelijk zijn. Dit gaat verder dan alt-teksten bij afbeeldingen. Denk aan ondertitels en transcripties bij video’s voor slechthorenden, of kleurcontrast dat teksten leesbaar maakt voor mensen met een visuele beperking. Gebruik nooit alleen kleur om iets duidelijk te maken. Een foutmelding in rood zonder tekst of icoon? Dat is voor sommige mensen onzichtbaar.

Twee foutmeldingen: boven zonder icoon, enkel een rode kleur; onder met duidelijke tekst en waarschuwingsicoon. De onderste variant is gemarkeerd als correct.

Figuur 1: Een foutmelding moet meer zijn dan alleen kleur. Voeg altijd tekst en een icoon toe zodat de melding voor iedereen waarneembaar is.


2. Bedienbaar (operable)

Iedere gebruiker moet de interface kunnen gebruiken. Ook zonder muis. Alles moet met een toetsenbord bedienbaar zijn. Zorg daarbij dat de ‘focus’ goed zichtbaar is, bijvoorbeeld met een rand om de actieve knop. Denk ook aan voldoende tijd om acties uit te voeren en vermijd visuele effecten die flikkeren of flitsen: die kunnen gevaarlijk zijn voor mensen met epilepsie.

Twee formulieren naast elkaar. Links is een knop geselecteerd, maar zonder zichtbare focus. Gemarkeerd met een rood kruis. Rechts is een knop geselecteerd met een duidelijke blauwe rand eromheen. Gemarkeerd met een groen vinkje. Beide formulieren bevatten invoervelden en knoppen.

Figuur 2: Maak de toetsenbordfocus altijd zichtbaar, zodat gebruikers weten waar ze zijn tijdens het navigeren zonder muis.


3. Begrijpelijk (understandable)

Taal en navigatie moeten helder en voorspelbaar zijn. Vermijd vakjargon waar mogelijk en gebruik duidelijke foutmeldingen: “Voer een geldig e-mailadres in” werkt beter dan “Fout”. Zorg dat het menu op elke pagina op dezelfde plek zit en dat formulieren intuïtief werken.

Twee invoervelden voor e-mailadressen naast elkaar. Links staat een foutmelding “Fout!” onder het veld — zonder verdere uitleg. Rechts staat dezelfde invoer met een foutmelding in rood: “Voer een geldig e-mailadres in.” De rechter is gemarkeerd als correct.

Figuur 3: Gebruik duidelijke, begrijpelijke foutmeldingen. Zo weten gebruikers precies wat ze moeten aanpassen.


4. Robuust (robust)

Je content moet werken met allerlei browsers, schermlezers en ondersteunende technologieën. Dat vraagt om schone, semantische code die voldoet aan webstandaarden. Alleen dan kunnen hulpmiddelen zoals spraaksoftware goed interpreteren wat er op het scherm staat. Nu én in de toekomst.

Twee vensters naast elkaar. Links bevat visuele content met een “Verzenden”-knop, maar een schermlezer geeft een vraagteken weer: de structuur is onduidelijk. Rechts toont dezelfde interface, maar met semantische HTML-code en schermlezeruitvoer: “kop 1: contactformulier” en “Verzenden”. De rechterzijde is gemarkeerd als toegankelijk.

Figuur 4: Door semantische HTML te gebruiken, kunnen schermlezers en andere technologieën je content correct interpreteren.


En nu? Wat verandert er na 28 juni 2025?

De deadline is een tussenstation. Toegankelijkheid blijft in ontwikkeling, net als de WCAG-richtlijnen. De volgende WCAG-versies zijn op het moment het relevantst:


WCAG 2.2: de logische volgende stap

Naast de onderdelen die verplicht zijn, zijn er ook extra criteria waar je aan kunt voldoen om zo beter toegankelijk te zijn. Zo werden eind 2023 de richtlijnen van WCAG 2.2 opgesteld. Deze uitbreiding van versie 2.1 voegt criteria toe die vooral nuttig zijn voor mensen met cognitieve beperkingen, slechtere motoriek of beperkingen op mobiele apparaten. Deze aanpassingen zijn dus niet verplicht, maar wel goed voor de toegankelijkheid van je website. Als je nu al voldoet aan 2.1, is 2.2 relatief eenvoudig toe te passen. En maakt je site weer een stuk gebruiksvriendelijker. Enkele voorbeelden van de nieuwe richtlijnen zijn:

  • Voor elke actie waarbij je moet slepen, moet je een eenvoudig alternatief in de vorm van een aanwijzer aanbieden.
  • Zorg ervoor dat de doelen een minimale afmeting hebben en dat er voldoende afstand tussen de doelen zit.
  • Vraag niet twee keer om dezelfde informatie tijdens hetzelfde sessie.

WCAG 3.0: een blik op de toekomst

De opvolger van de WCAG zoals we die nu kennen, is WCAG 3.0. Deze bevindt zich nog in conceptfase, maar laat zien waar het heen gaat. De focus verschuift van technische checks naar echte gebruikerservaring. De vraag wordt: kunnen gebruikers hun taken afronden? Niet: is het HTML-element correct opgebouwd? Daarnaast wordt de scope breder: WCAG 3.0 houdt meer rekening met cognitieve beperkingen en nieuwe technologieën zoals VR en AI.

Wil je alvast meelezen of inspelen op wat komen gaat? De laatste versie vind je op de W3C-site.


Meer dan regels: werk aan een duurzame toegankelijkheidsaanpak

Toegankelijkheid is geen project dat eindigt. Het vraagt om een cultuurverandering binnen je organisatie. Begin bijvoorbeeld met het integreren van toegankelijkheid in alle fases van ontwikkeling: van ontwerp tot testen. Laat het niet afhangen van één specialist, maar betrek je hele team.

De feedback van mensen met beperkingen is daarbij onmisbaar. Zij signaleren knelpunten die je met standaardtests niet snel ontdekt. Vraag actief naar hun ervaringen en gebruik die input om te verbeteren.

Ook intern is het belangrijk om het gesprek levend te houden. Deel goede voorbeelden, laat zien dat toegankelijkheid niet alleen verplicht is, maar ook loont: gebruiksvriendelijkheid stijgt, klanttevredenheid groeit en je bent voorbereid op toekomstige regelgeving.


Tot slot: van conform naar compleet

De EAA heeft ervoor gezorgd dat veel organisaties hun digitale toegankelijkheid op orde hebben gebracht. Maar wie alleen ‘voldoet’, mist kansen. Toegankelijkheid is geen vinkje. Het is een manier van denken en werken.

De eerste stappen zijn gezet. Door bewust om te gaan met het ontwerpen van applicaties, continu te blijven leren en samen te werken, kunnen we als maatschappij verder bouwen aan een toegankelijke omgeving voor iedereen.

Wil je sparren over wat dit betekent voor jouw organisatie? Of wil je WCAG 2.2 goed implementeren? Onze consultants denken graag met je mee. Neem vrijblijvend contact met ons op om de mogelijkheden te bespreken!

Deel deze pagina:
Jean-Pierre
Auteur
Jean-Pierre
Developer

Heb je vragen over dit onderwerp of zou je Jean-Pierre willen inhuren voor een vergelijkbare opdracht?

Neem contact met ons op

Kan je een Developer gebruiken in je team?

Neem contact met ons op om de mogelijkheden te bespreken

Hoe leuk is het om Developer bij ShareValue te zijn?

Onze collega's vertellen het graag!
Cookies beheren