Digitale toegankelijkheid: wat de wet eist, wat uw gebruikers ervaren, waar u begint

Digitale toegankelijkheid betekent dat websites, apps, documenten en onlinediensten bruikbaar zijn voor iedereen, ook voor mensen met een handicap. In Europa is het bovendien een wettelijke verplichting, die sinds 28 juni 2025 ook voor een groot deel van de privésector geldt. Deze gids legt uit wat de wet vraagt in België, Frankrijk, Luxemburg en Zwitserland, hoe uw gebruikers uw pagina's in werkelijkheid doorlopen, en met welke aanpak u van een eerste stand van zaken naar duurzame conformiteit gaat.

Wat is digitale toegankelijkheid?

Digitale toegankelijkheid is de mate waarin een digitale dienst (website, intranet, mobiele app, software, document, kiosk) waargenomen, begrepen en gebruikt kan worden door een persoon met een handicap, met of zonder hulptechnologie. Concreet: een blinde persoon moet uw contactformulier kunnen invullen met een schermlezer. Iemand die geen muis kan vasthouden, moet zijn winkelmandje met het toetsenbord kunnen afrekenen. Een dove persoon moet uw presentatievideo kunnen volgen dankzij ondertiteling.

De internationale normen vatten die eis samen in vier principes, die terugkomen in de WCAG en in de Europese richtlijn van 2016 voor de overheidssector: inhoud moet waarneembaar, bedienbaar, begrijpelijk en robuust zijn. Waarneembaar betekent dat informatie nooit via één enkel zintuig loopt: een betekenisvolle afbeelding heeft een tekstalternatief, een video heeft ondertitels. Bedienbaar betekent dat alle functies met het toetsenbord werken, zonder tijdslimiet die onmogelijk te halen is. Begrijpelijk betekent dat labels duidelijk zijn en dat fouten worden uitgelegd. Robuust ten slotte betekent dat de code standaard genoeg is om correct geïnterpreteerd te worden door browsers en hulptechnologieën.

De term “webtoegankelijkheid” wordt vaak als synoniem gebruikt, maar is enger. Digitale toegankelijkheid omvat ook mobiele apps, kantoordocumenten en pdf's, bedrijfssoftware, zelfbedieningsterminals en, sinds de European Accessibility Act, producten zoals betaalterminals, smartphones en e-readers. Een toegankelijke website is dus maar een deel van het verhaal: het gaat om het volledige traject van de gebruiker, van het zoeken naar informatie tot de betaling, de bevestigingsmail en het downloaden van een factuur.

Wat digitale toegankelijkheid niet is

• Het is geen aparte “versie voor mensen met een handicap” van de website. U maakt de hoofddienst toegankelijk, niet een uitgeklede kopie die u parallel moet onderhouden en die altijd achterop raakt ten opzichte van het origineel.
• Het is geen sober of saai design. Een toegankelijke website kan visueel rijk, geanimeerd en hedendaags zijn, zolang contrasten, structuur en interacties aan de criteria voldoen.
• Het is geen label dat u voor altijd verwerft. Elke nieuwe release, elke nieuwe inhoud en elke gepubliceerde pdf kan de conformiteit weer doen achteruitgaan.
• Het is geen zaak van ontwikkelaars alleen. Redacteurs, designers, projectleiders, aankopers en juristen bepalen allemaal mee het eindresultaat.
• Het is geen synoniem van gebruiksvriendelijkheid. Een website kan aangenaam zijn voor de meeste bezoekers en toch volledig onbruikbaar met een schermlezer.
• Het is geen score uit een automatische tool. Testtools vinden slechts een deel van de fouten: de meeste criteria vragen een menselijk oordeel, bijvoorbeeld om te beoordelen of een tekstalternatief een afbeelding correct beschrijft.

Handicap en digitale toegankelijkheid: om welke gebruikers gaat het?

Volgens de factsheet van de Wereldgezondheidsorganisatie over handicap (in het Engels) leven ongeveer 1,3 miljard mensen met een aanzienlijke handicap, of 16% van de wereldbevolking: één op de zes mensen. In de Europese Unie tonen de Eurostat-cijfers in de infographic van de Raad van de Europese Unie “Handicaps in de EU: feiten en cijfers” dat in 2024 24% van de personen ouder dan 16 jaar een vorm van handicap had, ongeveer 90 miljoen mensen. Bij 65-plussers loopt dat aandeel op tot 47,3%.

Achter die cijfers zitten heel verschillende situaties, die voor een scherm niet dezelfde problemen opleveren. Veel handicaps zijn onzichtbaar, en veel mensen in die situatie omschrijven zichzelf niet als gehandicapt: ze zeggen dat ze slecht zien, dat ze verdwalen in formulieren of dat ze niet tegen animaties kunnen. Daarom denken de normen in functionele behoeften (zien, horen, bedienen, begrijpen) in plaats van in medische categorieën.

Visuele beperkingen

Ze gaan van volledige blindheid over slechtziendheid tot kleurenblindheid, kokerzien of lichtgevoeligheid. Een blinde persoon gebruikt een schermlezer, soms gekoppeld aan een brailleleesregel; hij heeft een logische koppenstructuur nodig, tekstalternatieven en componenten met een correcte naam. Een slechtziende persoon vergroot de weergave, soms heel sterk, en heeft voldoende contrast nodig en een lay-out die zich herschikt zonder horizontaal te scrollen. Een kleurenblinde persoon heeft er baat bij dat informatie niet alleen op kleur steunt: een foutief veld dat enkel met een rode rand wordt aangeduid, ontgaat hem.

Auditieve beperkingen

Dove en slechthorende mensen hebben weinig last van een website die uit tekst en beeld bestaat. De problemen beginnen bij video's zonder ondertitels, podcasts zonder transcriptie, waarschuwingen die alleen hoorbaar zijn en klantendiensten die enkel telefonisch bereikbaar zijn. Voor een deel van de mensen die doof geboren zijn, is een gebarentaal de eerste taal, in Vlaanderen de Vlaamse Gebarentaal, en is geschreven Nederlands een tweede taal: een duidelijke, korte tekst bewijst hen een grote dienst.

Motorische beperkingen

Verlamming, tremor, amputatie, een neuromusculaire aandoening of gewoon artrose: heel wat mensen kunnen een muis of een aanraakscherm niet nauwkeurig bedienen. Ze navigeren met het toetsenbord, met een schakelaar, met oogbesturing of met spraakbesturing. Typische drempels zijn functies die alleen werken wanneer de muis erover beweegt, te kleine klikdoelen, complexe gebaren zonder alternatief (slepen en neerzetten, knijpen, vegen met twee vingers) en te korte tijdslimieten om een formulier in te vullen.

Cognitieve en psychische beperkingen, leerstoornissen

Dyslexie, aandachtsstoornissen, geheugenproblemen, autisme, een verstandelijke beperking, angststoornissen of de gevolgen van een beroerte: deze situaties komen veel voor en zijn vaak onzichtbaar. Ze vragen om een voorspelbare navigatie, duidelijke labels, instructies vóór de velden in plaats van na de fout, foutmeldingen die zeggen hoe u de fout herstelt, en geen onverwachte contextwijzigingen. WCAG 2.2 voegde criteria in die richting toe, bijvoorbeeld het verbod om voor het inloggen een geheugen- of overschrijftest op te leggen wanneer er geen alternatief is.

Tijdelijke situaties en veroudering

Een pols in het gips, een oogoperatie, een scherm in de volle zon, een lawaaierig perron of een kind op de arm brengen iedereen tijdelijk in de situatie van een persoon met een handicap. Veroudering combineert vaak meerdere matige beperkingen: minder scherp zien, minder goed horen, minder fijne motoriek en sneller vermoeid raken door drukke interfaces. Met bijna één op de twee 65-plussers in de Unie die een handicap aangeeft, is digitale toegankelijkheid in de eerste plaats een kwestie van demografie.

Hoe gebruikers een website doorlopen: hulptechnologieën en concrete drempels

Om toegankelijkheid te begrijpen, kijkt u het best hoe iemand een website werkelijk gebruikt met zijn eigen hulpmiddelen. De meeste hulptechnologieën zien het scherm niet zoals u: ze lezen de code en de toegankelijkheidsboom die de browser daaruit afleidt. Als de code niet zegt dat een element een knop, een kop of een verplicht veld is, kan het hulpmiddel dat niet raden.

Schermlezers en brailleleesregels

De belangrijkste schermlezers zijn NVDA en JAWS op Windows, VoiceOver op macOS en iOS, TalkBack op Android en Verteller in Windows. Ze zetten de inhoud om in spraak of braille. Een ervaren gebruiker leest een pagina niet van boven naar onder: hij springt van kop naar kop, vraagt de lijst met links op, gaat van zone naar zone (koptekst, navigatie, hoofdinhoud) of loopt de velden van een formulier af. Op een smartphone verkent hij het scherm met zijn vinger en gaat hij met veegbewegingen van element naar element.

De meest voorkomende drempels zijn heel concreet. Een zoekknop die alleen uit een vergrootglas bestaat, zonder toegankelijke naam, wordt voorgelezen als “knop”, zonder meer. Een vervolgkeuzemenu dat in JavaScript is gebouwd zonder de juiste rollen en statussen, meldt niet dat het open is en ook niet welke optie geselecteerd is. Een modaal venster dat de focus niet krijgt, laat de gebruiker verder lezen op de pagina erachter zonder te weten dat er een dialoogvenster is geopend. Een visuele captcha zonder alternatief sluit de toegang tot de dienst gewoonweg af.

Navigatie met het toetsenbord en met schakelaars

Met het toetsenbord gaat u van het ene interactieve element naar het volgende met Tab en Shift+Tab, activeert u met Enter of de spatiebalk en beweegt u in lijsten met de pijltjestoetsen. Drie voorwaarden zijn onmisbaar: elke functie moet bereikbaar zijn, de tabvolgorde moet de visuele logica volgen, en het element met de focus moet duidelijk zichtbaar zijn. Schakelaars, die gebruikt worden door mensen met een zeer beperkte mobiliteit, werken volgens hetzelfde principe met slechts één of twee knoppen: elke overbodige stap vermenigvuldigt de inspanning.

Een typisch voorbeeld: op een betaalpagina gaat de keuzelijst voor de vervaldatum van de kaart open met een klik, maar reageert ze niet op het toetsenbord. De gebruiker raakt tot het laatste scherm van het aankoopproces en kan niet betalen. Een ander veelvoorkomend geval is de “toetsenbordval”: een videospeler of een interactieve kaart neemt de focus over en geeft hem niet meer terug, waardoor de gebruiker de pagina opnieuw moet laden.

Vergroting, schermloepen en weergave-instellingen

Slechtziende mensen gebruiken de zoomfunctie van de browser, de loep van het besturingssysteem of gespecialiseerde vergrotingssoftware, soms met omgekeerde kleuren of een modus met hoog contrast. Bij sterke vergroting zien ze maar een klein stukje van het scherm tegelijk. Een melding die in een verre hoek verschijnt, een bevestiging die na drie seconden verdwijnt of tekst in een afbeelding die wazig wordt bij vergroting, ontgaat hen. De WCAG vragen onder meer dat de inhoud leesbaar blijft zonder horizontaal scrollen op een breedte van 320 CSS-pixels, en dat de tekstafstand vergroot kan worden zonder verlies van informatie.

Spraakbesturing

Met Dragon, Spraakbediening van Apple of Voice Access op Android zegt de gebruiker “klik op Verzenden” of “tik op Volgende”. Dat werkt alleen als de technische naam van de knop overeenkomt met wat op het scherm staat. Een knop met het opschrift “Verzenden” die in de code “submit-form-2” heet, reageert niet op het commando: dat is het WCAG-succescriterium “label in naam”, eenvoudig na te leven en vaak vergeten. In een tweetalige Brusselse context speelt dit dubbel: het zichtbare label en de toegankelijke naam moeten in dezelfde taal staan.

Ondertiteling, transcripties en audiodescriptie

Gesynchroniseerde ondertitels helpen dove en slechthorende mensen, maar ook iedereen die een video zonder geluid bekijkt, op de trein of in een landschapskantoor. Een teksttranscriptie maakt het mogelijk een audiofragment snel te doorlopen en is nuttig voor doofblinde mensen met een brailleleesregel. Audiodescriptie ten slotte beschrijft de visuele informatie die nodig is om een video te begrijpen, bijvoorbeeld een grafiek die een spreker toelicht met alleen de woorden “zoals u hier ziet”.

Digitale toegankelijkheid en de wet: wat is verplicht in Europa?

Het recht op digitale toegankelijkheid rust in Europa op twee pijlers. De eerste betreft de overheidssector: richtlijn (EU) 2016/2102 verplicht al jaren de toegankelijkheid van websites en mobiele apps van overheidsinstanties, volgens een tijdpad dat voor apps afliep op 23 juni 2021. De tweede betreft de markt: richtlijn (EU) 2019/882, de European Accessibility Act, geldt sinds 28 juni 2025 voor een lijst van producten en diensten die aan consumenten worden aangeboden. Elke lidstaat zet die teksten op zijn eigen manier om, wat de verschillen in aanpak en controle tussen landen verklaart.

De European Accessibility Act voor producten en diensten van de privésector

De Nederlandstalige tekst van richtlijn (EU) 2019/882 op EUR-Lex omvat onder meer elektronische-communicatiediensten, de toegang tot audiovisuele mediadiensten, bepaalde onderdelen van personenvervoer (door de lucht, per spoor, per bus en over water), bankdiensten voor consumenten, e-books en e-commerce. Aan de productkant gaat het onder meer om computers en hun besturingssystemen, smartphones, betaalterminals, bepaalde zelfbedieningsautomaten en e-readers. Een webshop, een bankapp of een ticketverkoop voor openbaar vervoer valt er dus rechtstreeks onder.

Micro-ondernemingen die diensten aanbieden, dat wil zeggen minder dan 10 werknemers en een jaaromzet of balanstotaal van maximaal 2 miljoen euro, zijn door de richtlijn vrijgesteld. Er bestaan overgangsmaatregelen: dienstencontracten die vóór 28 juni 2025 zijn gesloten, mogen ongewijzigd doorlopen tot uiterlijk 28 juni 2030, en zelfbedieningsterminals die al in gebruik zijn, mogen gebruikt worden tot het einde van hun economische levensduur, met een maximum dat de richtlijn op twintig jaar legt en dat Frankrijk tot vijftien jaar heeft ingekort. Let op: een website of app is geen “product” in de zin van die maatregelen en geniet die termijn niet. Meer details vindt u in onze volledige analyse van de European Accessibility Act.

België: wet van 2018, regionale regelgeving en EAA

In België verplicht de wet van 19 juli 2018 de toegankelijkheid van websites en apps van de federale overheidsinstanties; de gewesten en gemeenschappen hebben hun eigen teksten aangenomen, elk met een eigen toezichthouder. De technische referentie is de Europese norm EN 301 549: er bestaat geen eigen nationaal referentiekader. Op federaal niveau volgt de dienst digitale toegankelijkheid van de FOD BOSA de naleving op, en een gebruiker die geen bevredigend antwoord krijgt, kan zich wenden tot de federale Ombudsman.

Voor de privésector is de European Accessibility Act omgezet via verschillende teksten en zijn meerdere autoriteiten bevoegd. Volgens de pagina van Inter over de EU-richtlijn 2019/882 voor B2C staan de regels voor bankdiensten en e-commerce voor consumenten in het Wetboek van economisch recht, voert de FOD Economie ze uit en kan de Economische Inspectie optreden bij overtredingen. Micro-ondernemingen krijgen in België extra tijd, tot 28 juni 2030, om in orde te komen: een andere benadering dan de vrijstelling die Frankrijk koos. Zie onze pagina digitale toegankelijkheid in België en ons artikel over het Belgische kader.

Frankrijk: wet van 2005, Arcom en DGCCRF

In Frankrijk verplichten artikel 47 van de wet van 11 februari 2005 en decreet nr. 2019-768 van 24 juli 2019 de toegankelijkheid van onlinediensten voor publiekrechtelijke rechtspersonen, private organisaties met een opdracht van openbare dienst en ondernemingen waarvan de omzet in Frankrijk gemiddeld meer dan 250 miljoen euro bedraagt over de laatste drie boekjaren. Die organisaties moeten een toegankelijkheidsverklaring publiceren, op de homepage een conformiteitsvermelding tonen (niet, gedeeltelijk of volledig conform), een meerjarenschema en een jaarlijks actieplan aannemen, en een manier aanbieden om een probleem te melden. De referentiemethode is de RGAA, die verderop aan bod komt.

Sinds de ordonnantie van 6 september 2023 controleert de Arcom die verplichtingen. Volgens haar pagina over de toegankelijkheid van websites en digitale diensten (in het Frans) kan ze, na een ingebrekestelling, een geldboete opleggen van maximaal 50.000 euro voor het niet naleven van de toegankelijkheidseisen en 25.000 euro voor de andere verplichtingen, aangepast aan de aard, de ernst en de duur van de tekortkoming. Bij ondernemingen boven de omzetdrempel controleert de Arcom de vermeldingsplichten, niet de conformiteit met de RGAA zelf. Haar beslissingen zijn openbaar: in juni 2026 stelde ze een ministerie in gebreke over zijn online belastingdienst, met als vaststellingen een ontoegankelijk aanslagbiljet in pdf, een berichtenfunctie die niet met het toetsenbord werkte, een tabel waarvan de cellen niet aan hun koppen gekoppeld waren en een toegankelijkheidsverklaring die volledige conformiteit aankondigde, terwijl ze zelf een conformiteitsgraad van 42,11 % vermeldde.

De European Accessibility Act is in Frankrijk omgezet in het consumentenwetboek (artikel L. 412-13) en uitgewerkt in decreet nr. 2023-931 en een besluit van 9 oktober 2023. Volgens de praktische fiche van de DGCCRF voor professionals (in het Frans) controleert de DGCCRF, de Franse dienst voor consumentenbescherming, de producten en de e-commerce, in samenwerking met de Arcom voor audiovisuele media, de Arcep voor elektronische communicatie, en de Banque de France, de ACPR en de AMF voor financiële diensten. Overtredingen zijn overtredingen van de vijfde klasse, met boetes van 7.500 euro die per inbreuk cumuleerbaar zijn, naast bevelen tot conformiteit. Een eerste balans die de DGCCRF op 25 juni 2026 publiceerde, maakt melding van informatie- en controleacties, onder meer bij onlinehandelsplatforms. Alle details staan op onze pagina digitale toegankelijkheid in Frankrijk en in ons artikel over de Franse verplichtingen.

Luxemburg: RAWeb, RAAM en twee wetten

In Luxemburg verplicht de wet van 28 mei 2019 de toegankelijkheid van websites en apps van de overheidssector. De Service information et presse van de regering (SIP) controleert de naleving en publiceert de nationale referentiekaders: de RAWeb voor het web, waarvan versie 1.1 in februari 2026 verscheen, en de RAAM voor mobiele apps, beide gebaseerd op de norm EN 301 549. De privésector valt onder de wet van 8 maart 2023, die de European Accessibility Act omzet en waarvan het toezicht bij het Office de la surveillance de l'accessibilité des produits et services (OSAPS) ligt. Onze pagina digitale toegankelijkheid in Luxemburg en ons artikel over het Luxemburgse kader gaan dieper in op die verplichtingen.

Zwitserland: LHand, eCH-0059 en de doorwerking van de EAA

In Zwitserland verplichten de wet op de gelijkstelling van personen met een handicap (LHand, in het Duits BehiG), van kracht sinds 2004, en de bijbehorende verordening de toegankelijkheid van de dienstverlening van de Bondsstaat, ook online. De federale wet over het gebruik van elektronische middelen voor de uitvoering van overheidstaken (LMETA, in het Duits EMBAG) vraagt eveneens dat die dienstverlening toegankelijk is voor de hele bevolking. De referentienorm is eCH-0059, waarvan de derde versie het niveau AA van WCAG 2.1 eist voor de websites en apps van de federale administratie. Kantons en gemeenten passen hun eigen regels toe.

Twee ontwikkelingen verdienen uw aandacht. Ten eerste heeft de Bondsraad eind 2024 een gedeeltelijke herziening van de LHand aan het Parlement voorgelegd, die nog in behandeling is. Ten tweede maakt Zwitserland geen deel uit van de Europese Unie, maar een Zwitserse onderneming die producten of diensten uit de European Accessibility Act aan consumenten in de Unie verkoopt, moet er voor die markten aan voldoen. Zie onze pagina digitale toegankelijkheid in Zwitserland en ons artikel over Zwitserland.

Wie, welke wet, welke norm, welke controle: het overzicht per land

De tabel hieronder vat de verplichtingen rond digitale toegankelijkheid samen in de vier landen waar Belgische en Franstalige organisaties het vaakst actief zijn. Ze geeft een overzicht: de juiste kwalificatie van uw situatie hangt af van uw statuut, uw diensten en de landen waarin u ze aanbiedt.

Een groep die in meerdere van die landen actief is, hoeft geen vier afzonderlijke trajecten te lopen. Alle referentiekaders steunen op WCAG niveau AA: een goed opgebouwde audit volgens de WCAG en de norm EN 301 549 vormt een gemeenschappelijke basis, die u aanvult met de vormvereisten van elk land (formaat van de verklaring, conformiteitsvermelding, berekeningsmethode van het percentage). Onze pagina referentiekaders en verplichtingen per land legt die samenhang uit.

Digitale toegankelijkheid in Vlaanderen en Brussel: welke regels voor welke overheid?

Voor een Belgische overheidsinstantie is de eerste vraag niet technisch maar institutioneel: van welke overheid hangt u af? Niet de taal van uw website of het adres van uw hoofdzetel beslist, wel de overheid waaronder u valt. Een Vlaamse gemeente, een Brusselse gemeente en een federale overheidsdienst publiceren misschien gelijkaardige formulieren, maar ze vallen onder drie verschillende teksten en drie verschillende toezichthouders. De FOD BOSA houdt de officiële lijst van die teksten en toezichthouders bij op zijn pagina missies en klachten van het Belgian Web Accessibility Office.

Vlaanderen: het Bestuursdecreet en Inter

Vlaanderen heeft de Europese richtlijn voor de overheidssector omgezet in het Bestuursdecreet van 7 december 2018. Het decreet geldt voor de Vlaamse administratie, de provincies, de steden en gemeenten, en voor organisaties die nauw met de overheid verbonden zijn, omdat ze grotendeels door de overheid gefinancierd of gecontroleerd worden. Vzw's vallen er alleen onder als ze essentiële diensten verlenen, zoals sociale hulp, zorg of onderwijs, of diensten voor personen met een handicap. Voor scholen gaat het enkel om de essentiële administratieve onlinefuncties: homepage, navigatie, contactgegevens, lesprogramma, reglement en inschrijvingsinformatie.

Het toezicht ligt bij Inter, het Vlaamse expertisecentrum voor toegankelijkheid, dat als ondersteunings- en controleorgaan audits uitvoert, met advies van het NOOZO, de Vlaamse adviesraad van personen met een handicap. Inter rapporteert jaarlijks aan de FOD BOSA, die de Belgische rapportering aan Europa coördineert. Belangrijk voor Vlaamse ondernemingen: Inter controleert niet of websites aan de European Accessibility Act voldoen. Een webshop in Gent of een boekingsplatform in Leuven valt voor de EAA onder de federale regels en de FOD Economie, niet onder Inter.

Brussel: gewest, gemeenten en gemeenschapsinstellingen

Het Brussels Hoofdstedelijk Gewest regelde de toegankelijkheid van de websites en apps van zijn gewestelijke overheidsinstanties en van de gemeenten in de ordonnantie van 4 oktober 2018. De officiële lijst van de FOD BOSA wijst equal.brussels aan als toezichthouder. De Brusselse situatie wordt ingewikkelder door de gemeenschappen: instellingen van de gemeenschappen die in Brussel gevestigd zijn, volgen hun gemeenschap. Een Vlaamse instelling in Brussel valt in principe onder het Vlaamse Bestuursdecreet, terwijl de Franse Gemeenschapscommissie (COCOF) een eigen decreet van 9 mei 2019 heeft. Voor de Gemeenschappelijke Gemeenschapscommissie bevat de lijst van de FOD BOSA geen eigen tekst.

Meertalige websites: een Brussels aandachtspunt

Veel federale en Brusselse websites, en heel wat bedrijfswebsites, bestaan in twee, drie of vier talen. Meertaligheid schept geen bijkomende juridische verplichting, maar vermenigvuldigt de mogelijke fouten. De WCAG eisen dat de taal van elke pagina in de code is aangeduid (criterium 3.1.1) en dat passages in een andere taal ook zo gemarkeerd zijn (criterium 3.1.2). Zonder die aanduiding leest een schermlezer die op Nederlands staat een Franstalige pagina met een Nederlandse uitspraak voor, en wordt de tekst onverstaanbaar. Vergeet ook niet dat elke taalversie haar eigen toegankelijkheidsverklaring en contactpunt nodig heeft, in de taal van de bezoeker.

Voor belangrijke video's voor het grote publiek verbetert een vertolking in Vlaamse Gebarentaal (VGT) of in Frans-Belgische Gebarentaal (LSFB) de toegang aanzienlijk, bovenop de ondertiteling die de norm vraagt. Gebruikerstesten leveren het meest op wanneer ze in de werkelijke talen van de dienst gebeuren. Ons artikel over digitale toegankelijkheid in België beschrijft per entiteit de klachtenprocedure en de bemiddelaars.

Normen voor digitale toegankelijkheid op een rij: WCAG, EN 301 549, RGAA

De WCAG (Web Content Accessibility Guidelines), gepubliceerd door het W3C, vormen de basis van alle andere normen. Volgens de officiële WCAG-overzichtspagina van het W3C (in het Engels) verscheen versie 2.2 op 5 oktober 2023 en werd ze bijgewerkt op 12 december 2024; ze voegt negen succescriteria toe aan WCAG 2.1 en laat het verouderde criterium 4.1.1 over parsing vallen. Ze is ook de internationale norm ISO/IEC 40500:2025 geworden. De criteria zijn ingedeeld in drie niveaus, A, AA en AAA: de Europese wetgeving mikt op niveau AA. WCAG 3 is nog een ontwerp en is geen afdwingbare referentie.

EN 301 549 is de geharmoniseerde Europese norm met toegankelijkheidseisen voor digitale producten en diensten. Ze neemt de WCAG over voor web, documenten en software, en voegt eisen toe voor hardware, diensten voor tweerichtingscommunicatie, documentatie en ondersteuningsdiensten. Versie V3.2.1 uit 2021 steunt op WCAG 2.1. Versie V4.1.1, in september 2026 gepubliceerd door ETSI, CEN en Cenelec, sluit aan bij WCAG 2.2 en presenteert zich als een middel om aan de European Accessibility Act te voldoen; haar volledige juridische draagwijdte hangt af van de bekendmaking van de verwijzing in het Publicatieblad van de Europese Unie, die er op de datum van deze update nog niet was.

De Franse RGAA (Référentiel général d'amélioration de l'accessibilité), gepubliceerd door de interministeriële directie voor digitale zaken, vertaalt die eisen in 106 criteria met precieze tests en een steekproefmethode. De geldende versie is 4.1.2. De officiële website van de RGAA (in het Frans) kondigt een versie 5 aan die in voorbereiding is en eind 2026 zou verschijnen, en vermeldt uitdrukkelijk dat lopende toegankelijkheidswerken in afwachting daarvan niet opgeschort of uitgesteld mogen worden. Zie ook onze dienst RGAA-audit voor organisaties met Franse verplichtingen.

In Luxemburg nemen de RAWeb 1.1 en de RAAM 1.1 de methode van de RGAA over en passen ze die aan de norm EN 301 549 aan; de SIP publiceert ook een referentiekader voor de evaluatie van pdf-documenten, de RAPDF. In Zwitserland verwijst de norm eCH-0059, gepubliceerd door de vereniging eCH, naar WCAG niveau AA. In België gebruiken alle overheden rechtstreeks de norm EN 301 549. Onze gedetailleerde vergelijking van de toegankelijkheidsnormen zet de verschillen criterium per criterium op een rij.

Digitale toegankelijkheid invoeren: de aanpak in acht stappen

Stabiele conformiteit bereikt u niet door na een audit zo snel mogelijk te corrigeren, maar door een proces op te zetten. Hieronder de acht stappen van een volledige aanpak, van de eerste stand van zaken tot de opvolging. Ze gelden voor een FOD net zo goed als voor een webshop, met een verschillende intensiteit.

1. Stand van zaken. Begin met een inventaris: websites, subdomeinen, intranetten, extranetten, mobiele apps, klantenzones, downloadbare documenten en geïntegreerde tools van derden (betaling, afsprakenplanning, chat, kaarten). Bepaal voor elk onderdeel de toepasselijke tekst, de verantwoordelijke leverancier, de datum van de laatste vernieuwing en of er al een toegankelijkheidsverklaring bestaat. Zo vermijdt u dat u eerst een weinig bezochte informatiesite laat auditen, terwijl de klantenzone, waar de meeste aanvragen gebeuren, buiten beeld blijft.
2. Conformiteitsaudit. De audit meet de conformiteit van een representatieve steekproef van pagina's of schermen met het passende referentiekader: EN 301 549 en WCAG in België en voor de European Accessibility Act, RGAA in Frankrijk, RAWeb of RAAM in Luxemburg. Een degelijke audit combineert automatische tools, een manuele inspectie van de code en tests met echte hulptechnologieën. Hij levert een conformiteitspercentage op, een rooster per criterium en een beschrijving van elke non-conformiteit. Afhankelijk van uw situatie: een audit volgens WCAG en EN 301 549, een RGAA-audit of een RAAM-audit van mobiele apps.
3. Actieplan met prioriteiten. Rangschik de correcties volgens drie criteria: de impact op de essentiële trajecten (een account aanmaken, betalen, een aanvraag indienen, de dienst contacteren), de frequentie van de fout (een foutieve component die op alle pagina's voorkomt, weegt zwaarder dan een losse afwijking) en de inspanning om ze te herstellen. In Frankrijk voedt dat plan het meerjarenschema en het jaarlijkse actieplan die de wet oplegt. Een goed actieplan wijst voor elk pakket een verantwoordelijke en een deadline aan.
4. Correcties. Corrigeer aan de bron: in de componentenbibliotheek of het designsysteem, in de sjablonen van het CMS, in de gemeenschappelijke stijlen. Een correctie in de component “knop” werkt door op duizenden pagina's; dezelfde correctie pagina per pagina houdt geen stand tot de volgende release. Vraag uw leveranciers voor componenten van derden hun eigen conformiteitsverklaring en voorzie contractuele clausules. Begeleiding bij toegankelijke ontwikkeling helpt uw teams om vanaf de eerste sprints aan de bron te corrigeren.
5. Opleiding van de teams. Toegankelijkheid gaat achteruit zodra de mensen die de dienst maken de regels niet kennen. Ontwikkelaars moeten de semantiek van HTML en ARIA beheersen, designers de contrasten en focusstatussen, redacteurs de koppenstructuur, duidelijke links en tekstalternatieven, aankopers de clausules die in overheidsopdrachten thuishoren. Groepsopleidingen en e-learning vullen elkaar goed aan, afhankelijk van de omvang van de teams.
6. Toegankelijkheidsacceptatie. Neem een toegankelijkheidscontrole op in elke oplevering, net als functionele of beveiligingstests. Schrijf de toegankelijkheidscriteria in de definition of done van uw user stories en laat nieuwe functies controleren voor ze online gaan. Een regelmatige toegankelijkheidsacceptatietest kost veel minder dan om de drie jaar een grote correctiecampagne.
7. Toegankelijkheidsverklaring. Publiceer een verklaring die de waarheid zegt: datum en referentiekader van de audit, conformiteitspercentage, niet-toegankelijke inhoud en ingeroepen uitzonderingen, een contactmogelijkheid om een probleem te melden en de beroepsmogelijkheden. In Frankrijk komt daar de conformiteitsvermelding op de homepage bij. Een verklaring die volledige conformiteit aankondigt zonder onderbouwende audit, stelt u meer bloot dan een eerlijke verklaring van gedeeltelijke conformiteit. Onze gids over de toegankelijkheidsverklaring beschrijft de inhoud land per land.
8. Opvolging op lange termijn. Behandel meldingen van gebruikers binnen een redelijke termijn, laat na elke grote vernieuwing en op een vast ritme een nieuwe audit uitvoeren, volg de evolutie van de normen (RGAA 5, nieuwe versie van EN 301 549) en stel een toegankelijkheidscoördinator aan met een duidelijk mandaat van de directie. Vul de audits ten slotte aan met gebruikerstesten met mensen met een handicap op uw belangrijkste trajecten: ze brengen moeilijkheden aan het licht die geen enkel rooster meet.

Budget en doorlooptijd: wat kost een toegankelijkheidsaudit?

Er bestaat geen publiek referentietarief, en een prijs die wordt genoemd zonder de scope te kennen, zegt weinig. De kostprijs van een audit digitale toegankelijkheid hangt vooral af van het volume en de complexiteit van wat geëvalueerd wordt. Vraag om offertes te kunnen vergelijken dat ze over dezelfde steekproef, hetzelfde referentiekader en dezelfde opleveringen gaan.

• Het aantal pagina's of schermen in de steekproef, en vooral het aantal verschillende sjablonen erin;
• de complexiteit van de trajecten: een aankoopproces, een simulator of een formulier in meerdere stappen vraagt veel meer tests dan een nieuwspagina;
• het aantal platformen: dezelfde dienst op het web, op iOS en op Android betekent drie evaluaties;
• het verwachte referentiekader en rapportformaat (WCAG en EN 301 549, RGAA met officieel rooster, RAWeb, eventueel meerdere tegelijk voor een groep die in verschillende landen actief is);
• het aantal pdf- of kantoordocumenten dat geëvalueerd moet worden;
• de talen van de audit en van het rapport, wat in België al snel Nederlands en Frans betekent;
• de bijbehorende diensten: gebruikerstesten, begeleiding van de teams tijdens de correcties, een controle-audit, het opstellen van de verklaring;
• de timing, bijvoorbeeld een audit die klaar moet zijn voor een lancering of een controledatum.

Wat de doorlooptijd betreft: de audit van een website van gemiddelde complexiteit telt u eerder in weken dan in maanden; bij ons bedraagt de gemiddelde doorlooptijd van een audit drie weken. De correcties duren meestal langer dan de audit, van enkele weken voor fouten die in een paar componenten zitten tot meerdere maanden wanneer de front-endarchitectuur herzien moet worden. Een vernieuwing van de website is het beste moment om toegankelijkheid in te bouwen: als u er vanaf de wireframes rekening mee houdt, kost het een fractie van correcties na de lancering.

Houd er ten slotte rekening mee dat de audit maar één lijn in het budget is. De zwaarste posten zijn vaak de correcties, het toegankelijk maken van bestaande documenten en de opleiding. Wees op uw hoede voor een heel lage offerte die zich beperkt tot het draaien van een automatische tool: daarmee kunt u geen afdwingbaar conformiteitspercentage berekenen en geen betrouwbare verklaring opstellen.

Pdf's, mobiele apps en video's: de blinde vlekken van conformiteit

Pdf- en kantoordocumenten

Gemeenteraadsbesluiten, jaarverslagen, formulieren om af te drukken, aanslagbiljetten, algemene voorwaarden, facturen: downloadbare documenten zijn vaak het minst toegankelijke deel van een dienst. Een gescande pdf is niet meer dan een afbeelding, onleesbaar voor een schermlezer. Een pdf die zonder zorg is geëxporteerd, bevat misschien tekst maar geen structuur: geen koppen, een willekeurige leesvolgorde, tabellen die niet te doorlopen zijn, formuliervelden zonder label.

De goede praktijk is om informatie waar mogelijk in HTML te publiceren en pdf voor te behouden aan documenten die afgedrukt of ondertekend moeten worden. Als een pdf nodig is, maak hem dan vanuit een goed gestructureerd brondocument (kopstijlen, tekstalternatieven bij afbeeldingen, eenvoudige tabellen) en controleer daarna de tags. Voor de overheidssector sluit de richtlijn van 2016 kantoorbestanden uit die vóór 23 september 2018 zijn gepubliceerd, tenzij ze nodig zijn voor lopende administratieve procedures. In Luxemburg stelt het controleverslag 2022-2024 van de SIP overigens vast dat ontoegankelijke pdf's de vaakst ingeroepen rechtvaardiging van onevenredige last zijn; een uitzondering ontslaat u niet van de plicht om op verzoek een toegankelijk alternatief te bieden.

Mobiele apps

Een native iOS- of Android-app evalueert u op een echt toestel, met VoiceOver en TalkBack, vergrote tekst, liggende weergave en, waar nodig, een extern toetsenbord. Typische fouten zijn pictogrammen zonder label, complexe gebaren zonder alternatief, een vergrendelde schermoriëntatie, tekst die niet meegroeit met de systeeminstellingen en ingebedde webweergaven die nooit getest zijn. De RAAM in Luxemburg, de RGAA in Frankrijk en de hoofdstukken over software in de norm EN 301 549 leveren het rooster; een RAAM-audit volgt die aanpak op echte toestellen.

Video, audio en livestreams

Een toegankelijke video combineert gesynchroniseerde en getrouwe ondertitels, een transcriptie, audiodescriptie wanneer het beeld informatie bevat die niet wordt uitgesproken, en een speler waarvan de bediening met het toetsenbord werkt en door schermlezers wordt voorgelezen. Vermijd automatisch afspelen met geluid, dat de stem van de schermlezer overstemt. Voor de overheidssector zijn vooraf opgenomen tijdgebaseerde media die vóór 23 september 2020 zijn gepubliceerd, uitgesloten van de richtlijn van 2016; nieuwe inhoud moet vanaf de publicatie toegankelijk zijn.

Veelgemaakte fouten bij digitale toegankelijkheid

Dezelfde fouten komen terug van organisatie tot organisatie, ongeacht de sector. Wie ze kent, vermijdt de meeste ervan al vóór de eerste audit.

• Wachten op de volgende vernieuwing om in actie te komen, terwijl veel correcties (contrasten, labels, koppenstructuur, tekstalternatieven) op de huidige website kunnen gebeuren.
• Alleen vertrouwen op de score van een automatische tool en denken dat een pagina “zonder gedetecteerde fouten” conform is.
• Een toegankelijkheidsverklaring publiceren zonder echte audit, of ze nooit bijwerken na wijzigingen aan de website.
• Pagina's een voor een corrigeren in plaats van de gemeenschappelijke componenten en sjablonen.
• Componenten van derden vergeten: betaalmodule, afsprakentool, rekruteringstool, videospeler, kaarten, chat.
• Overal ARIA-attributen toevoegen “voor de zekerheid”: verkeerd gebruikte ARIA maakt de ervaring vaak slechter in plaats van beter, terwijl native HTML in de meeste gevallen volstaat.
• Visuele captcha's of korte sessietijden plaatsen zonder alternatief of mogelijkheid tot verlenging.
• Pdf's en transactionele e-mails verwaarlozen, hoewel ze deel uitmaken van het traject.
• Geen toegankelijkheidseisen opnemen in het bestek of de lastvoorwaarden, en de fouten pas bij de oplevering van het project ontdekken.
• Het onderwerp bij één persoon leggen zonder steun van de directie en zonder budget voor correcties.

De voordelen van een toegankelijke website, verder dan de wettelijke verplichting

Het eerste voordeel is uw bereik. Met bijna een kwart van de volwassenen in de Unie die een vorm van handicap aangeeft en bijna één op de twee 65-plussers, volgens de Eurostat-cijfers hierboven, sluit een ontoegankelijk traject een groot deel van uw gebruikers of klanten uit. Voor een openbare dienst is dat een inbreuk op de gelijke behandeling; voor een webshop zijn het verlaten winkelmandjes op het moment van betalen.

Het tweede voordeel is kwaliteit. Semantische code, gedocumenteerde componenten en gestructureerde inhoud zijn makkelijker te onderhouden, te laten evolueren en te testen. Dezelfde inspanningen verbeteren het gebruik op mobiel, onderweg of met een trage verbinding, en komen alle bezoekers ten goede: duidelijke labels verminderen invoerfouten, expliciete foutmeldingen verminderen het aantal oproepen naar de klantendienst.

Het derde voordeel ligt in zichtbaarheid en markten. Een logische koppenstructuur, tekstalternatieven en transcripties maken uw inhoud leesbaarder voor zoekmachines en voor mensen, ook al is toegankelijkheid op zich geen rankingfactor. Openbare aankopers nemen toegankelijkheid steeds vaker op in hun lastenboeken, en grote ondernemingen vragen het aan hun leveranciers: een verklaring kunnen voorleggen die op een audit steunt, wordt een commercieel argument.

Het laatste voordeel is intern. Uw intranet, bedrijfssoftware en hr-tools zijn ook digitale diensten. Ze toegankelijk maken is een voorwaarde om medewerkers met een handicap aan te werven en aan het werk te houden, en maakt het dagelijkse werk makkelijker voor wie gaandeweg zijn loopbaan minder goed ziet, hoort of beweegt.

Waar begint u: uw plan voor de eerste 90 dagen

Als u van nul vertrekt, vindt u hieronder een realistische planning om met digitale toegankelijkheid aan de slag te gaan zonder op een vernieuwing te wachten. Ze past even goed bij een gemeente of een OCMW als bij een kmo of een grote onderneming die onder de European Accessibility Act valt; pas gewoon het referentiekader aan. Voor de specifieke aandachtspunten van uw sector, zie onze pagina's overheidssector, grote ondernemingen en kmo's en middelgrote bedrijven.

1. Weken 1 en 2: uw verplichtingen bepalen. Maak een lijst van uw digitale diensten, bepaal per land en, in België, per bevoegde overheid welke teksten van toepassing zijn, en stel een toegankelijkheidscoördinator aan met een sponsor in de directie. Ga na of u al een verklaring publiceert en of die op een audit steunt.
2. Weken 3 tot 6: auditen wat het zwaarst doorweegt. Laat eerst de dienst auditen waar de meeste aanvragen of de meeste omzet samenkomen, op een steekproef die de volledige trajecten omvat (inloggen, formulier, betaling, bevestiging). Laat tegelijk enkele typedocumenten evalueren en, als u er een hebt, uw mobiele app.
3. Weken 5 tot 8: een eerlijke verklaring publiceren. Publiceer of actualiseer op basis van de audit de toegankelijkheidsverklaring, met een contactpunt om problemen te melden, en in Frankrijk ook de conformiteitsvermelding. Beter een verklaarde gedeeltelijke conformiteit dan een volledige conformiteit zonder bewijs.
4. Weken 6 tot 10: de componenten met de grootste impact corrigeren. Pak eerst de blokkerende fouten aan op de essentiële trajecten en de fouten die terugkomen in gemeenschappelijke componenten: navigatie, formulieren, knoppen, modale vensters, contrasten.
5. Weken 8 tot 12: de teams opleiden en uitrusten. Leid ontwikkelaars, designers en redacteurs op, neem toegankelijkheidscriteria op in uw lastenboeken en acceptatietests, en voorzie een controle voor elke release.
6. Na 90 dagen: de kalender aanhouden. Neem de komende deadlines op in uw actieplan: de publicatie van de RGAA 5, verwacht eind 2026, de verwachte bekendmaking van de nieuwe versie van EN 301 549 in het Publicatieblad van de Unie, en het einde van de overgangsmaatregelen van de European Accessibility Act voor dienstencontracten en voor Belgische micro-ondernemingen op 28 juni 2030. Plan een nieuwe audit na elke grote wijziging en minstens eenmaal per cyclus van uw meerjarenplan.

Veelgestelde vragen