WCAG 2.2, EN 301 549, RGAA, RAWeb: welke norm voor digitale toegankelijkheid volgt u?

Alle verplichtingen inzake digitale toegankelijkheid in Europa rusten op dezelfde technische basis: de WCAG van het W3C. Toch is de norm voor digitale toegankelijkheid die doorslaggevend is niet dezelfde voor een Franse gemeente, een Luxemburgs ministerie, een Belgische overheidsinstantie of een Zwitserse softwareleverancier die in de Unie verkoopt: RGAA, RAWeb, EN 301 549 of eCH-0059. Deze analyse, bijgewerkt op 27 oktober 2026, legt uit wat elk referentiekader bevat, wat versie 4.1.1 van de norm EN 301 549, gepubliceerd in september, verandert, en hoe u kiest wanneer u in meerdere landen actief bent.

Het korte antwoord: één gemeenschappelijke basis, verschillende uitwerkingen

De WCAG bepalen wat toegankelijke webcontent is. De Europese norm EN 301 549 neemt ze over en breidt ze uit naar alles wat digitaal is: documenten, software, mobiele apps, toestellen en communicatiediensten. Nationale referentiekaders, zoals de RGAA in Frankrijk of de RAWeb in Luxemburg, zetten die eisen om in precieze criteria en tests, met een beoordelingsmethode en een wettelijke grondslag.

De verschillen tussen die teksten gaan dus minder over de inhoud dan over drie elementen: de gekozen versie van de WCAG, het toepassingsgebied en de methode die is opgelegd om de conformiteit te meten. Een website die voldoet aan de WCAG 2.1 op niveau AA zit in de vier landen al dicht bij conformiteit. Juridisch is hij daarmee nog niet conform zolang de beoordeling niet volgens het toepasselijke referentiekader is uitgevoerd en de vereiste documenten, zoals de toegankelijkheidsverklaring, niet zijn gepubliceerd.

Om u snel te situeren: dit is het referentiekader dat op de datum van dit artikel geldt voor de meest voorkomende gevallen.

• Franse overheidsinstantie, of onderneming die onder artikel 47 van de Franse wet van 11 februari 2005 valt: RGAA 4.1.2, in afwachting van de RGAA 5 die voor eind 2026 is aangekondigd;
• Luxemburgse overheidsinstantie: RAWeb 1.1 voor het web, RAAM 1.1 voor mobiele apps en RAPDF 1.1 voor pdf-documenten;
• Belgische overheidsinstantie: de norm EN 301 549, dus de WCAG 2.1 op niveau AA voor het web;
• Zwitserse federale administratie: de norm eCH-0059 versie 3.0, die verwijst naar de WCAG 2.1 op niveau AA;
• onderneming die onder de European Accessibility Act valt, in welke lidstaat ook: de eisen van de richtlijn, waarvoor de norm EN 301 549 de technische referentie is.

WCAG: hoe de referentienorm voor digitale toegankelijkheid is opgebouwd

De Web Content Accessibility Guidelines worden gepubliceerd door het World Wide Web Consortium (W3C), binnen zijn initiatief voor webtoegankelijkheid (WAI). Het zijn geen wetteksten, maar technische aanbevelingen waarnaar wetten en normen verwijzen. Sinds september 2025 is versie 2.2 ook een internationale norm: ISO publiceerde de tweede editie van de norm ISO/IEC 40500, die de WCAG 2.2 overneemt. Voor de Vlaamse en Brusselse lezer is er bovendien een geautoriseerde Nederlandse vertaling, de “Richtlijnen voor Toegankelijkheid van Webcontent (WCAG) 2.2”, die het W3C zelf publiceert; bij een geschil blijft de Engelse versie gezaghebbend.

Vier principes, dertien richtlijnen, toetsbare succescriteria

De WCAG zijn opgebouwd rond vier principes. Content moet waarneembaar zijn: informatie die via een afbeelding, een geluid of een kleur wordt gegeven, moet ook bestaan in een vorm die iedereen kan waarnemen, bijvoorbeeld een tekst die een schermlezer voorleest. Content moet bedienbaar zijn: alles wat met de muis kan, moet ook met het toetsenbord kunnen, zonder onhaalbare tijdslimiet. Content moet begrijpelijk zijn: een opgegeven taal, voorspelbaar gedrag, duidelijke foutmeldingen. En content moet robuust zijn: de code moet hulptechnologieën in staat stellen de naam, de rol en de status van elk onderdeel te herkennen.

Die principes zijn uitgewerkt in 13 richtlijnen (guidelines), zoals “Toetsenbordtoegankelijk” of “Assistentie bij invoer”. Elke richtlijn is op haar beurt opgesplitst in succescriteria, die zo zijn geformuleerd dat ze kunnen worden gecontroleerd: op een bepaalde pagina is een criterium voldaan of niet. Versie 2.2 telt 86 actieve succescriteria. Het is dat niveau, het niveau van de criteria, dat auditors controleren en dat de nationale referentiekaders overnemen.

Drie conformiteitsniveaus: A, AA en AAA

Elk criterium hoort bij een niveau. Niveau A groepeert de eisen zonder welke bepaalde mensen eenvoudigweg geen toegang hebben tot de content: een video zonder ondertitels, een knop die niet met het toetsenbord bruikbaar is. Niveau AA voegt eisen toe die belangrijke hindernissen wegnemen, zoals voldoende tekstcontrast of een zichtbare focus. Niveau AAA bundelt de strengste eisen, die vaak onmogelijk voor een hele website te garanderen zijn, zoals gebarentaal bij alle video’s.

Conform zijn op niveau AA betekent dat u voldoet aan alle criteria van niveau A en aan alle criteria van niveau AA. Dat is het niveau dat de norm EN 301 549 hanteert en, via die norm, ook de Europese regelgeving. Conformiteit wordt per pagina beoordeeld, maar ook over volledige processen: als één stap van een bestelproces of van een onlineaanvraag niet conform is, kan geen enkele pagina van dat proces conform worden verklaard.

Versies 2.0, 2.1 en 2.2: drie versies die onderling compatibel zijn

Elke nieuwe versie van de WCAG 2 voegt criteria toe zonder de vorige in vraag te stellen. Het W3C stelt dat de WCAG 2.2 voortbouwen op de WCAG 2.1 en ermee compatibel blijven: content die voldoet aan de WCAG 2.2, voldoet ook aan de eerdere versies, met één uitzondering, die verderop aan bod komt.

De negen criteria die de WCAG 2.2 toevoegen, en het criterium dat verdwijnt

Het onderdeel “Nieuwe kenmerken in WCAG 2.2” van de geautoriseerde Nederlandse vertaling van de WCAG 2.2 somt negen nieuwe criteria op. Zes daarvan behoren tot de niveaus A en AA en vallen dus binnen een AA-conformiteit:

• 2.4.11 Focus niet bedekt (minimum), niveau AA: het element dat de focus krijgt, mag niet volledig verborgen zijn door content van de pagina, zoals een vaste balk;
• 2.4.12 Focus niet bedekt (uitgebreid), niveau AAA: geen enkel deel van het element mag verborgen zijn;
• 2.4.13 Focusweergave, niveau AAA: de focusindicator moet een minimale grootte en een minimaal contrast hebben;
• 2.5.7 Sleepbewegingen, niveau AA: elke handeling die u uitvoert door te slepen, moet ook mogelijk zijn met een gewone klik of tik;
• 2.5.8 Grootte van het aanwijsgebied (minimum), niveau AA: klikbare zones moeten minstens 24 CSS-pixels in het vierkant meten, behoudens uitzonderingen;
• 3.2.6 Consistente hulp, niveau A: de manieren om hulp te krijgen, moeten van pagina tot pagina op dezelfde plaats staan;
• 3.3.7 Overbodige invoer, niveau A: informatie die al in een proces is gegeven, mag niet opnieuw worden gevraagd of moet automatisch worden voorgesteld;
• 3.3.8 Toegankelijke authenticatie (minimum), niveau AA: inloggen mag geen cognitieve test vereisen zonder alternatief of hulp;
• 3.3.9 Toegankelijke authenticatie (uitgebreid), niveau AAA: dezelfde eis, zonder de uitzondering voor objectherkenning.

Succescriterium 4.1.1 Parsen staat in de WCAG 2.2 vermeld als “verouderd en verwijderd”: browsers en hulptechnologieën zijn niet langer afhankelijk van het ontleden van de ruwe broncode. Het is de enige uitzondering op de achterwaartse compatibiliteit. Het W3C verduidelijkt dat organisaties die beleidsmatig verplicht zijn te voldoen aan de WCAG 2.0 of 2.1, dit criterium mogelijk moeten blijven testen en erover rapporteren. Dat is het geval in Frankrijk, waar criterium 8.2 van de RGAA 4.1.2 (geldigheid van de gegenereerde broncode) nog moet worden gecontroleerd.

WCAG 3: een werf voor de lange termijn, geen deadline

Het W3C werkt al enkele jaren aan een nieuwe generatie regels, de W3C Accessibility Guidelines 3.0. Het meest recente werkdocument (Working Draft, Engelstalig) dateert van 10 september 2026. Het stelt een andere architectuur voor: verwachte resultaten, gegroepeerd per thema (afbeeldingen en media, controle door de gebruiker enzovoort), fijnmaziger eisen die worden ingedeeld in essentiële en aanvullende eisen, en “assertions” waarmee een organisatie verklaart dat ze bepaalde praktijken toepast, zoals het uitvoeren van gebruikerstests. Ook de manier waarop conformiteit wordt berekend, verschilt van die in de WCAG 2.

Het W3C is duidelijk over het tijdpad: volgens zijn introductiepagina over de WCAG 3 (Engelstalig) zal de norm pas over enkele jaren af zijn, zal ze de WCAG 2 niet vervangen en zullen de WCAG 2 pas verscheidene jaren na de afronding van de WCAG 3 worden afgeschaft. Het werkdocument zelf vermeldt dat de definitieve lijst met eisen zal verschillen van de gepubliceerde lijst.

Geen enkele Europese wet en geen enkele geharmoniseerde norm verwijst vandaag naar de WCAG 3. Voor een IT-directeur of een compliance officer is de conclusie eenvoudig: de nuttige investering ligt bij de WCAG 2.2 op niveau AA. Het werkdocument van september 2026 merkt overigens op dat wie de WCAG 2 op niveau AA naleeft, dicht bij conformiteit met de WCAG 3 komt, al kunnen er verschillen blijven.

EN 301 549: de Europese norm die veel verder gaat dan het web

De norm EN 301 549, met als titel “Toegankelijkheidseisen voor ICT-producten en -diensten”, wordt gezamenlijk opgesteld door ETSI, CEN en CENELEC, de Europese normalisatie-instellingen. Waar de WCAG enkel webcontent viseren, bestrijkt deze norm het geheel van de informatie- en communicatietechnologie: een geldautomaat, bedrijfssoftware, een videoconferentiedienst, een e-reader of een gedownloade pdf vallen allemaal binnen het toepassingsgebied.

Voor het web vindt de norm niets nieuws uit: hoofdstuk 9 neemt de succescriteria van de WCAG op de niveaus A en AA over. De hoofdstukken 10 en 11 passen diezelfde criteria, aangepast, toe op documenten en software die geen webpagina’s zijn, met inbegrip van native mobiele apps. De rest van de norm voegt eisen toe die de WCAG niet behandelen.

Versie 3.2.1 van kracht, versie 4.1.1 gepubliceerd in september 2026

De versie die momenteel in het Publicatieblad van de Europese Unie is vermeld, is V3.2.1, gepubliceerd in 2021. Ze werd aangewezen als geharmoniseerde norm voor websites en mobiele apps van de publieke sector door het Uitvoeringsbesluit (EU) 2021/1339 van de Commissie van 11 augustus 2021, genomen op grond van Richtlijn (EU) 2016/2102. De hoofdstukken over web, documenten en software verwijzen naar de WCAG 2.1 op niveau AA.

Versie 4.1.1 werd goedgekeurd op 24 augustus 2026 en gepubliceerd op 2 september 2026. Volgens het voorwoord en de inleiding werd ze voorbereid in het kader van normalisatieverzoek M/587 van de Commissie, met referentie C(2022) 6456, om een middel te bieden waarmee de conformiteit met Richtlijn (EU) 2019/882, de European Accessibility Act, kan worden aangetoond. De hoofdstukken 9, 10 en 11 zijn afgestemd op de WCAG 2.2, die de norm citeert in de versie van 12 december 2024 en onder de referentie ISO/IEC 40500:2025. De bijlagen ZA en ZB leggen het verband tussen de eisen van de norm en die van de twee richtlijnen. De tekst is gratis te raadplegen op de website van ETSI: EN 301 549 V4.1.1 (2026-09), Engelstalig.

Eén juridisch punt is belangrijk: een norm geeft pas een vermoeden van conformiteit zodra de referentie ervan in het Publicatieblad van de Europese Unie is bekendgemaakt. Op de datum van dit artikel is V4.1.1 daar nog niet vermeld; nationale instanties die de werkzaamheden hebben gevolgd, zoals die van Luxemburg, verwachten die vermelding tegen eind 2026. Tot dan blijft V3.2.1 de geharmoniseerde referentienorm voor de publieke sector.

Wat de norm bovenop de WCAG vereist

Bij een audit volgens de norm EN 301 549 vallen verschillende eisen buiten een zuiver WCAG-raster. Software of een app moet de toegankelijkheidsinstellingen van het systeem respecteren, bijvoorbeeld de tekstgrootte die in de instellingen van de telefoon is gekozen. Een contentbeheersysteem moet het mogelijk maken toegankelijke content te produceren. De productdocumentatie moet de toegankelijkheidsfuncties beschrijven, en de helpdesk moet een dove of blinde persoon kunnen helpen. Voor een videoconferentiedienst of een bankapp met videogesprek legt hoofdstuk 6 eisen op inzake realtime tekst en videokwaliteit voor liplezen of gebarentaal.

RGAA 4.1.2: het verschil tussen RGAA en WCAG uitgelegd

Het Référentiel général d’amélioration de l’accessibilité (RGAA) wordt gepubliceerd door de Franse interministeriële directie voor digitale zaken (DINUM). Het dient om de conformiteit te beoordelen van diensten die onder artikel 47 van de Franse wet nr. 2005-102 van 11 februari 2005 vallen; de verplichtingen worden toegelicht in ons artikel over digitale toegankelijkheid in Frankrijk. Versie 4 werd goedgekeurd in september 2019; versie 4.1.2, die van kracht is, komt voort uit de update van 18 april 2023.

De RGAA 4.1.2 telt 106 criteria, verdeeld over 13 thema’s. Elk criterium heeft de vorm van een gesloten vraag, bijvoorbeeld: “Heeft elke informatieve afbeelding een tekstalternatief?”. Elk criterium is opgesplitst in tests, in totaal 258 volgens het officiële bestand met de criteria en tests van de RGAA (Franstalig). Een criterium is conform als al zijn tests slagen, niet conform als één ervan faalt, of niet van toepassing als de betrokken content niet op de pagina voorkomt.

RGAA of WCAG: wat echt verschilt

Inhoudelijk zeggen de RGAA 4.1.2 en de WCAG 2.1 op niveau AA hetzelfde: elk RGAA-criterium verwijst naar een of meer WCAG-criteria. Een analyse van het officiële bestand toont dat de RGAA de criteria van de niveaus A en AA van de WCAG 2.1 dekt, met één uitzondering: voor live-ondertiteling (WCAG-criterium 1.2.4) bestaat er geen RGAA-criterium.

De verschillen zitten in de methode. De RGAA legt precieze tests vast, waar de WCAG de auditor zijn techniek laten kiezen; hij schrijft een testomgeving voor, dat wil zeggen combinaties van schermlezers en browsers (NVDA, JAWS, VoiceOver op de computer, TalkBack en VoiceOver op mobiel); hij bepaalt hoe de steekproef van pagina’s wordt samengesteld en hoe een conformiteitspercentage wordt berekend. Daarnaast gaan er publicatieverplichtingen mee gepaard die eigen zijn aan het Franse recht, zoals de toegankelijkheidsverklaring en het meerjarenplan. De criteria die de WCAG 2.2 hebben toegevoegd, zoals de grootte van het aanwijsgebied of toegankelijke authenticatie, staan er nog niet in.

Een RGAA-audit is dus geen WCAG 2.2-audit, en omgekeerd. Moet u in Frankrijk een verklaring publiceren, dan is de RGAA-audit de enige die een tegenstelbaar conformiteitspercentage oplevert. Mikt u op de European Accessibility Act of op een Europese markt, dan moet de beoordeling bovendien de WCAG 2.2-criteria en de relevante hoofdstukken van de norm EN 301 549 omvatten.

De RGAA 5 in voorbereiding

De DINUM heeft aangekondigd dat versie 5 van de RGAA wordt opgesteld, samen met publieke, verenigings- en private actoren, met een publicatie gepland voor eind 2026. Volgens de officiële aankondiging van de RGAA 5 (Franstalig) zal deze versie de WCAG 2.2 integreren, de criteria herformuleren en vereenvoudigen, en eigen criteria en tests vastleggen voor mobiele apps en kantoordocumenten. Tegelijk wordt de Arcom aangewezen als toezichthouder en komt er een onlinedienst om toegankelijkheidsverklaringen in te dienen en te publiceren.

De DINUM verduidelijkt twee praktische punten. De criteria van de RGAA 5 zullen die van de RGAA 4.1.2 verfijnen of aanvullen zonder ze tegen te spreken: het werk dat vandaag wordt geleverd, gaat niet verloren. En verklaringen die vóór de publicatie van de RGAA 5 zijn opgesteld, blijven 18 maanden geldig, met een maximum van drie jaar na hun publicatiedatum. Lopende werkzaamheden hoeven dus niet te worden stilgelegd in afwachting van de nieuwe versie.

RAWeb, RAAM en RAPDF: de referentiekaders van Luxemburg

Luxemburg heeft gekozen voor nationale referentiekaders, gepubliceerd door de Service information et presse van de regering (SIP) op het portaal accessibilite.public.lu. Ze dienen om de websites en apps te beoordelen van de organisaties van de publieke sector, die onder de wet van 28 mei 2019 vallen. Hun bijzonderheid is dat ze zijn opgebouwd vanuit de norm EN 301 549, en niet enkel vanuit de WCAG, terwijl ze de methode van de RGAA overnemen.

De RAWeb 1.1, voor het web, telt 136 criteria. Hij neemt de 13 thema’s van de RGAA 4.1.2 over en voegt er vier aan toe die uit de Europese norm komen: documentatie en toegankelijkheidsfuncties, auteurstools, ondersteunende diensten en realtime communicatie. De update van 6 februari 2026 heeft onder meer de European Accessibility Act opgenomen, waardoor de RAWeb ook buiten de Luxemburgse publieke sector bruikbaar is, en heeft verouderde technieken geschrapt.

De RAAM 1.1, voor mobiele apps, telt 108 criteria. Hij beoordeelt een app aan de hand van de norm EN 301 549 V3.2.1 en dekt daarbij de hoofdstukken 5, 6, 7, 10, 11 en 12. De RAPDF 1.1, voor pdf-documenten, werd in februari 2026 vereenvoudigd: de methode steunt niet langer op een schermlezer maar op Acrobat Reader en de tool PDF Accessibility Checker (PAC), en hij bevat een concordantie met de norm PDF/UA-2.

Er staat een grote verandering op stapel. De SIP heeft op 15 september 2026 aangekondigd dat de RAWeb en de RAAM overgaan naar versie 2 (Franstalig), in de loop van februari 2027, compatibel met de norm EN 301 549 V4.1.1 en dus met de WCAG 2.2. Luxemburgse organisaties die in het najaar van 2026 een audit starten, laten die uitvoeren volgens RAWeb 1.1 of RAAM 1.1; het is nuttig om tegelijk de WCAG 2.2-criteria te laten controleren, zodat een tweede correctieronde wordt vermeden. Ons artikel over digitale toegankelijkheid in Luxemburg beschrijft de verplichtingen, en de pagina RAAM-audit de methode voor iOS- en Android-apps.

België en Zwitserland: geen eigen nationaal referentiekader

In België rechtstreeks de norm EN 301 549

In België zet de wet van 19 juli 2018 inzake de toegankelijkheid van de websites en mobiele applicaties van overheidsinstanties Richtlijn (EU) 2016/2102 om op federaal niveau, aangevuld met decreten en ordonnanties van de Gewesten en de Gemeenschappen. Er bestaat geen nationaal raster dat vergelijkbaar is met de RGAA: de referentie is de norm EN 301 549, dus de WCAG 2.1 op niveau AA voor het web, en diezelfde criteria geïnterpreteerd voor documenten en software.

In de praktijk steunt een Belgische audit op de WCAG-criteria en op de hoofdstukken van de norm die op de dienst van toepassing zijn. De tests van de RGAA of de RAWeb kunnen de auditor als werkinstrument dienen, maar het rapport en de verklaring moeten naar de norm EN 301 549 verwijzen. De verplichtingen en de bevoegde instanties worden toegelicht op onze pagina België en in het artikel over digitale toegankelijkheid in België.

Wat dit betekent voor Vlaamse en Brusselse organisaties

Voor een Vlaamse gemeente, een Brusselse overheidsdienst of een federale instelling verandert de bevoegdheidsverdeling niets aan de technische lat: welke tekst ook van toepassing is, federaal, gewestelijk of gemeenschapsrecht, de beoordeling gebeurt volgens de norm EN 301 549. Het is dus niet nodig om per bestuursniveau een ander auditraster te hanteren. Wat wel kan verschillen, zijn de praktische verplichtingen die de bevoegde tekst oplegt, zoals de vorm van de toegankelijkheidsverklaring of de instantie waarbij een gebruiker een klacht kan indienen.

Voor een Vlaamse of Brusselse onderneming die online verkoopt aan consumenten in België, Nederland of Frankrijk geldt hetzelfde principe als voor elke Europese onderneming: de eisen van de European Accessibility Act, met de norm EN 301 549 als technische vertaling. Een RGAA-audit kan voor een Franse dochteronderneming nodig zijn, maar is geen bewijs van conformiteit op de Belgische markt. Wie meerdere talen aanbiedt, moet er bovendien op letten dat elke taalversie wordt gecontroleerd: een correct opgegeven taal (WCAG-criterium 3.1.1) en tekstalternatieven die echt vertaald zijn, ontbreken vaak in de tweede of derde taalversie van een website.

In Zwitserland de norm eCH-0059

In Zwitserland leggen de wet op de gelijkheid van personen met een handicap (LHand, in het Duits BehiG) en de bijbehorende verordening de toegankelijkheid van de onlinediensten van de Confederatie op. De technische referentie is de norm eCH-0059, versie 3.0 (Duitstalig), goedgekeurd door de vereniging eCH in juni 2020. Ze steunt op de WCAG 2.1, en de federale administratie eist naleving op niveau AA. Kantons en gemeenten passen hun eigen regels toe, die vaak naar dezelfde norm verwijzen.

Twee ontwikkelingen verdienen aandacht. Een gedeeltelijke herziening van de LHand, die in het federale parlement wordt besproken, wil de toegang tot de diensten van private ondernemingen versterken, ook digitaal. En Zwitserse ondernemingen die aan consumenten in de Europese Unie verkopen, vallen voor de betrokken producten en diensten onder de European Accessibility Act, dus onder de norm EN 301 549 eerder dan onder eCH-0059. De details staan in ons artikel over digitale toegankelijkheid in Zwitserland.

Welke norm voor digitale toegankelijkheid per land en per organisatie

De onderstaande tabel koppelt het land en het type organisatie aan de toepasselijke tekst, het beoordelingskader en het verwachte niveau. Ze beschrijft de situatie op 27 oktober 2026; de aangekondigde wijzigingen staan in het actieplan aan het einde van dit artikel.

Twee opmerkingen bij het lezen van deze tabel. Ten eerste zijn de RGAA en de RAWeb beoordelingsmethoden, geen bijkomende eisenniveaus: een website die conform is met de RGAA, is niet “toegankelijker” dan een website die conform is met de norm EN 301 549; hij werd alleen volgens een ander raster beoordeeld. Ten tweede is het bij de European Accessibility Act de richtlijn die de eisen vastlegt, en de geharmoniseerde norm die er de technische vertaling van geeft; onze analyse van de European Accessibility Act beschrijft de betrokken producten en diensten en de uitzonderingen.

Zes WCAG-criteria uitgelegd aan de hand van concrete gevallen

Normen worden begrijpelijker via enkele criteria die in elke audit terugkomen. Voor elk ervan vermelden we de WCAG-referentie en, als dat bestaat, het overeenkomstige RGAA-criterium.

Het tekstalternatief van afbeeldingen

WCAG-criterium 1.1.1 Niet-tekstuele content (niveau A), overgenomen in de criteria 1.1 tot 1.3 van de RGAA, vereist dat elke informatieve afbeelding een tekstueel equivalent heeft en dat decoratieve afbeeldingen door hulptechnologieën worden genegeerd. Op een betaalpagina moeten de logo’s van de aanvaarde kaarten worden voorgelezen (“Bancontact, Visa, Mastercard”); de sfeerfoto in de banner moet daarentegen een leeg alternatief krijgen, zodat ze het voorlezen niet verstoort.

De vaakst voorkomende fouten zijn bekend: een alternatief dat de bestandsnaam herhaalt (“IMG_2045.jpg”), een alternatief “afbeelding” of “logo” zonder nuttige inhoud, een grafiek in een jaarverslag die enkel met zijn titel wordt beschreven, terwijl de cijfers nergens anders staan. In dat laatste geval vraagt de RGAA een uitgebreide beschrijving (criterium 1.6), bijvoorbeeld de tabel met de gegevens onder de grafiek.

Het contrast van teksten en componenten

WCAG-criterium 1.4.3 Contrast (minimum), niveau AA, criterium 3.2 van de RGAA, vereist een contrastverhouding van minstens 4,5:1 tussen de tekst en de achtergrond, verlaagd tot 3:1 voor grote tekst, dat wil zeggen minstens 18 punt, of 14 punt vet. De lichtgrijze voorbeeldtekst in een formulierveld, witte tekst op een lichte foto of de kleine lettertjes in een cookiebanner schieten vaak tekort.

Criterium 1.4.11 Contrast van niet-tekstuele content (niveau AA), criterium 3.3 van de RGAA, breidt de eis uit naar interfacecomponenten en informatieve grafische elementen: de rand van een invoerveld, het pictogram van een vergrootglas zonder label of de curve van een grafiek moeten een contrast van 3:1 halen met de aangrenzende kleuren.

Een zichtbare focus, en voortaan een focus die niet bedekt is

Wie met het toetsenbord navigeert, moet altijd zien waar hij zich bevindt. WCAG-criterium 2.4.7 Focus zichtbaar (niveau AA), criterium 10.7 van de RGAA, vereist dat het element dat de focus krijgt, zichtbaar is. De klassieke fout is een CSS-regel “outline: none” die om esthetische redenen op de hele website wordt toegepast, zonder vervangende indicator.

De WCAG 2.2 voegen criterium 2.4.11 toe (niveau AA): het element met de focus mag niet volledig verborgen zijn door content die de auteur heeft toegevoegd. Een vaste kop die de link bedekt waarop de gebruiker net is aangekomen, of een toestemmingsbanner die de onderkant van de pagina verbergt terwijl de gebruiker door de footer tabt, maakt de pagina niet conform.

De grootte van het aanwijsgebied

Criterium 2.5.8 Grootte van het aanwijsgebied (minimum), nieuw in de WCAG 2.2 (niveau AA), vraagt dat de doelen van aanwijshandelingen minstens 24 bij 24 CSS-pixels meten. Er bestaan uitzonderingen: een kleiner doel blijft aanvaardbaar als er voldoende ruimte is tot de naburige doelen, als dezelfde functie via een ander conform bedieningselement op de pagina beschikbaar is, als de link in een zin staat, of als de grootte door de browser en niet door de auteur wordt bepaald.

Typische gevallen van falen zijn dicht op elkaar staande paginanummers, het sluitkruisje van een modaal venster op mobiel of deelknoppen die zonder marge naast elkaar staan. Dit criterium bestaat niet in de RGAA 4.1.2; het staat wel in de norm EN 301 549 V4.1.1. Het corrigeren komt meestal neer op het bijsturen van enkele componenten van het design system, wat ook mensen met trillende handen en alle smartphonegebruikers ten goede komt.

Toegankelijke authenticatie

WCAG-criterium 3.3.8 Toegankelijke authenticatie (minimum), niveau AA, verbiedt om voor het inloggen een cognitieve functietest op te leggen, zoals een wachtwoord onthouden, tekens overtypen of een raadsel oplossen, tenzij een alternatief of hulp wordt geboden. Volgens de toelichtende documentatie van het W3C zijn een wachtwoordbeheerder en kopiëren-plakken geldige hulpmiddelen: een website die het plakken van het wachtwoord blokkeert of het automatisch invullen van velden verhindert, faalt op dit criterium.

Twee voorbeelden komen vaak terug in klantenzones. Het virtuele toetsenbord waarvan de cijfers bij elke aanmelding van plaats veranderen, vergt een zoekinspanning zonder alternatief; en de sms-code die in zes afzonderlijke vakjes moet worden ingevuld die plakken weigeren, dwingt tot overtypen. Een captcha met objectherkenning (“selecteer de afbeeldingen met een fiets”) wordt op niveau AA aanvaard, maar niet een captcha die vraagt een vervormde tekst over te typen zonder andere aanmeldmethode.

Ondertitels

WCAG-criterium 1.2.2 Ondertitels voor doven en slechthorenden (vooraf opgenomen), niveau A, vereist gesynchroniseerde ondertitels bij vooraf opgenomen video’s met geluid; de RGAA neemt het over in de criteria 4.3 (aanwezigheid) en 4.4 (relevantie). De opname van een gemeenteraad die achteraf online wordt gezet, een productvideo of een opleidingstutorial vallen eronder. Automatisch gegenereerde ondertitels die nooit zijn nagelezen, falen vaak op het relevantiecriterium.

Voor live content, zoals een webinar of een rechtstreekse uitzending van een openbare zitting, vereist WCAG-criterium 1.2.4 Ondertitels voor doven en slechthorenden (live), niveau AA, realtime ondertiteling. Daarvoor bestaat geen criterium in de RGAA 4.1.2, maar het geldt wel bij een audit volgens de WCAG of de norm EN 301 549. Hoofdstuk 7 van de norm voegt een eis toe aan de kant van de speler: de videospeler moet ondertitels kunnen weergeven en ze bij de doorgifte behouden.

Meerdere landen, één programma: kies een spilreferentiekader

Een groep met een webshop in Frankrijk, België en Luxemburg, een gemeenschappelijke mobiele app en een klantenzone in Zwitserland kan geen vier afzonderlijke toegankelijkheidsprogramma’s draaien. De meest efficiënte methode is één spilreferentiekader te kiezen, dat op alle gedeelde componenten wordt toegepast, en daarna de nationale beoordelingen uit te voeren waar de wet er een vereist.

1. Breng uw diensten en regimes in kaart. Noteer voor elke website, app of elk document de landen waar het wordt verspreid, het statuut van de entiteit die het uitgeeft (publiek, privé, al dan niet onder de EAA) en de documenten die moeten worden gepubliceerd: toegankelijkheidsverklaring, informatie die de EAA vereist, meerjarenplan in Frankrijk.
2. Kies een veeleisende spil. De WCAG 2.2 op niveau AA, aangevuld met de hoofdstukken van de norm EN 301 549 die voor uw diensten relevant zijn (software, documentatie, ondersteuning, realtime communicatie), dekken per definitie de inhoudelijke eisen van de RGAA, de RAWeb, de RAAM en eCH-0059.
3. Beoordeel eerst de gedeelde componenten. Het design system, de paginasjablonen, het bestelproces en de authenticatie zijn gemeenschappelijk voor al uw markten: een correctie die één keer gebeurt, komt alle landen ten goede.
4. Voer de vereiste nationale beoordelingen uit. Waar een nationaal referentiekader is opgelegd, zoals de RGAA in Frankrijk voor een dienst onder artikel 47 of de RAWeb voor een Luxemburgse overheidsinstantie, voert u de audit volgens dat kader uit om een aanvaardbaar percentage en een aanvaardbare verklaring te verkrijgen.
5. Harmoniseer uw indicatoren. Volg een gemeenschappelijke indicator, bijvoorbeeld het aantal niet-nageleefde WCAG 2.2 AA-criteria per gebruikerstraject, en reserveer de nationale percentages voor de verklaringen.

De meest voorkomende valkuil is een RGAA-audit voorstellen als bewijs van conformiteit met de European Accessibility Act: hij dekt noch de nieuwe WCAG 2.2-criteria, noch de eisen van de norm inzake documentatie en ondersteuning. Het omgekeerde geldt ook: een WCAG 2.2-rapport volstaat niet om een RGAA-verklaring op te stellen. Een conformiteitsaudit volgens WCAG en EN 301 549 dient als spil; hij wordt gecombineerd met een nationale audit wanneer de wet dat vraagt. De specifieke uitdagingen voor groepen komen aan bod op de pagina grote ondernemingen.

Auditmethode: van steekproef tot correctieplan

Welk referentiekader ook geldt, een degelijke toegankelijkheidsaudit doorloopt dezelfde stappen. Wat verschilt, zijn het criteriaraster en de vorm van het resultaat. Onze gids voor digitale toegankelijkheid beschrijft de volledige aanpak; hieronder ziet u het verloop van een conformiteitsaudit.

1. Afbakening. Keuze van het referentiekader en de versie ervan, afbakening van de scope (website, subdomeinen, beveiligde zone, app), testomgeving en toegang tot demo-accounts.
2. Samenstelling van de steekproef. De RGAA-methode vraagt een representatieve steekproef: standaardpagina’s als die bestaan (startpagina, contact, juridische vermeldingen, toegankelijkheidsverklaring, sitemap, hulp, aanmelding), de meest geraadpleegde pagina’s, pagina’s die representatief zijn voor elk sjabloon en alle stappen van de belangrijkste processen, zoals de aanvraag van een akte van de burgerlijke stand of een aankoop.
3. Manuele tests per criterium. De auditor controleert elk criterium op elke pagina van de steekproef, met het toetsenbord, met de code-inspector en met meetinstrumenten (contrast, structuur van de koppen). Deze stap neemt de meeste tijd in beslag.
4. Controle met hulptechnologieën. Complexe componenten, zoals een uitklapmenu, een interactieve kaart of een modaal venster, worden getest met schermlezers (NVDA, JAWS, VoiceOver, TalkBack) en met zoom, om na te gaan wat er werkelijk wordt weergegeven.
5. Berekening van het resultaat en rapport. Afhankelijk van het referentiekader geeft het rapport een conformiteitspercentage (RGAA, RAWeb, RAAM) of een status per criterium (WCAG, EN 301 549). Elke non-conformiteit wordt gelokaliseerd, geïllustreerd en vergezeld van een correctieadvies.
6. Correctieplan en hercontrole. De non-conformiteiten worden gerangschikt volgens hun impact op de gebruikers en de vereiste inspanning, waarna een hercontrole de correcties verifieert vóór de verklaring wordt bijgewerkt.

Wat automatische tools niet zien

Browserextensies en scanrobots zijn nuttig om repetitieve fouten snel op te sporen: een afbeelding zonder alt-attribuut, een veld zonder label, onvoldoende contrast van tekst op een effen achtergrond, een niet opgegeven taal. Ze kunnen de relevantie niet beoordelen: een alternatief “knop” bij de afbeelding van een knop “Betalen” slaagt voor de automatische test, maar blijft niet conform. Ze detecteren evenmin een toetsenbordval in een modaal venster, een onlogische tabvolgorde, tekst op een foto of een video zonder ondertitels.

Een score van een automatische tool is dus geen conformiteitspercentage en kan geen basis vormen voor een toegankelijkheidsverklaring. In onze audits dienen tools om snel een groot aantal pagina’s te bestrijken, maar elk criterium wordt manueel gecontroleerd; een volledige audit duurt gemiddeld drie weken. Om na te gaan of de gebruikerstrajecten echt werken, is een test met mensen met een beperking een nuttige aanvulling op de audit.

Pdf-documenten en mobiele apps: de blinde vlekken van audits

Pdf-documenten

Downloadbare documenten worden vaak vergeten, terwijl ze essentiële informatie bevatten: gemeenteraadsbesluiten, notulen, formulieren, algemene voorwaarden, jaarverslagen. De norm EN 301 549 wijdt er hoofdstuk 10 aan, dat de WCAG-criteria toepast op niet-webdocumenten. De RGAA behandelt ze in criterium 13.3, dat een toegankelijke versie vereist van elk downloadbaar kantoordocument, en Luxemburg beschikt met de RAPDF over een eigen referentiekader, afgestemd op de norm PDF/UA-2.

Een ingescande pdf van een gemeenteraadsbesluit is een gewone afbeelding: hij is onleesbaar voor een schermlezer, hoe goed de scan ook is. Een toegankelijke pdf is getagd (koppen, lijsten, tabellen), heeft een logische leesvolgorde, een documenttitel, een opgegeven taal en alternatieven voor de afbeeldingen. Voor essentiële informatie blijft het vaak de duurzaamste oplossing om de inhoud in HTML te publiceren en de pdf als aanvulling aan te bieden.

Mobiele apps

Een native app valt onder hoofdstuk 11 van de norm EN 301 549, over software, dat de WCAG-criteria vertaalt naar de context van een app. In Luxemburg levert de RAAM 1.1 het officiële raster. In Frankrijk vallen mobiele apps onder artikel 47 en worden ze vandaag met de RGAA beoordeeld; de RGAA 5 moet eigen criteria en tests voor mobiel vastleggen.

Een app-audit gebeurt op echte toestellen, met VoiceOver op iOS en TalkBack op Android. De gevoeligste controlepunten zijn de weergave van knoppen in de vorm van een pictogram, het respecteren van de tekstgrootte die in de instellingen van de telefoon is gekozen, de weergave in staande en liggende stand (WCAG-criterium 1.3.4 Weergavestand), complexe gebaren zonder alternatief (criterium 2.5.1 Aanwijzergebaren) en de grootte van de aanraakdoelen. Voor dat laatste punt leggen de WCAG 2.2 en de norm EN 301 549 V4.1.1 voortaan een minimum vast, terwijl de RAAM 1.1 en de RGAA 4.1.2 er geen voorzien.

Actieplan: twaalf maanden om het juiste niveau te halen

De teksten zullen de komende maanden evolueren, maar geen enkele ontwikkeling rechtvaardigt afwachten: de aangekondigde nieuwe versies verfijnen de huidige eisen zonder ze in vraag te stellen. Hieronder vindt u een realistische volgorde voor een organisatie die vertrekt van een onbekende uitgangssituatie.

1. Maand 1: inventaris. Maak een lijst van uw websites, apps, beveiligde zones en documentfamilies, met hun publiek, de landen waar ze worden verspreid en het toepasselijke juridische regime.
2. Maand 1 en 2: keuze van het referentiekader. Bepaal voor elke dienst het opgelegde referentiekader (RGAA, RAWeb, RAAM, EN 301 549, eCH-0059) en kies de WCAG 2.2 op niveau AA als gemeenschappelijke spil.
3. Maand 2 en 3: eerste audit. Laat bij voorrang de meest gebruikte diensten auditen, en de trajecten die voor de gebruiker iets betekenen: aanmelden, betalen, een afspraak maken, een dossier indienen.
4. Maand 3: publicatie. Publiceer of actualiseer de toegankelijkheidsverklaring en, in Frankrijk, het meerjarenplan en het jaarlijkse actieplan. De vereiste elementen worden beschreven in ons artikel over de toegankelijkheidsverklaring.
5. Maand 3 tot 9: correcties per component. Corrigeer eerst het design system en de sjablonen, daarna de content. Voer bij elke release een toegankelijkheidscontrole bij oplevering uit om regressies te vermijden.
6. Maand 4 tot 12: competentieopbouw. Leid de profielen op die content en code produceren: ontwikkelaars, designers, redacteurs, aankopers. Opleidingen per beroep voorkomen dat dezelfde fouten terugkomen.
7. Maand 12: hercontrole. Meet de vooruitgang volgens het referentiekader dat op dat moment van kracht is en werk de verklaring bij.

De kalender om in de gaten te houden

• tegen eind 2026: verwachte vermelding van de norm EN 301 549 V4.1.1 in het Publicatieblad van de Europese Unie, waardoor ze een vermoeden van conformiteit verleent;
• eind 2026: door de DINUM aangekondigde publicatie van de RGAA 5, met integratie van de WCAG 2.2; eerdere verklaringen blijven 18 maanden geldig, met een maximum van drie jaar;
• februari 2027: aangekondigde publicatie van de RAWeb 2 en de RAAM 2 in Luxemburg, compatibel met de norm EN 301 549 V4.1.1;
• zonder vastgelegde datum: gedeeltelijke herziening van de LHand in Zwitserland en afronding van de WCAG 3 door het W3C, die de WCAG 2 nog jarenlang niet zullen vervangen.

Wilt u in één oogopslag het referentiekader van elk land terugvinden, raadpleeg dan onze pagina normen en verplichtingen, en de pagina’s Frankrijk, Luxemburg en Zwitserland.

Veelgestelde vragen