Website toegankelijk maken: zo zorg je dat iedereen je site kan gebruiken

Een website kan er op jouw laptop prima uitzien en toch voor iemand anders bijna onbruikbaar zijn. Denk aan een bezoeker die geen muis gebruikt, tekst sterk vergroot, met een schermlezer surft, geen geluid kan afspelen of tijdelijk maar één hand kan gebruiken. Website toegankelijk maken betekent dat je met zulke situaties rekening houdt in je ontwerp, content en code.

Dat hoeft niet te beginnen met een juridisch dossier of een lange lijst technische termen. De beste eerste stap is veel eenvoudiger: probeer je eigen website eens op een andere manier te gebruiken dan je gewend bent. Waar raak je vast? Welke informatie verdwijnt? Welke knop is alleen met een muis te bedienen? Zulke kleine tests maken snel duidelijk waar echte drempels zitten.

Wat betekent een website toegankelijk maken?

Digitale toegankelijkheid gaat niet over een aparte, vereenvoudigde versie van je website. Het doel is juist dat dezelfde website door meer mensen gebruikt kan worden, met verschillende toestellen en hulpmiddelen.

Voor iemand die blind of slechtziend is, kan dat betekenen dat een schermlezer de pagina in een logische volgorde kan voorlezen. Voor iemand met een motorische beperking moet de site zonder muis bruikbaar zijn. Ondertiteling helpt doven en slechthorenden, maar ook iemand die een video in een trein zonder geluid bekijkt. Goed contrast helpt mensen met verminderd zicht én iedereen die buiten op een fel scherm kijkt.

De internationale WCAG-richtlijnen brengen zulke eisen samen in vier principes: content moet waarneembaar, bedienbaar, begrijpelijk en robuust zijn. WCAG 2.2 is de actuele W3C-versie en voegt onder meer extra criteria toe rond focus, aanraakdoelen, slepen en toegankelijke authenticatie.

Doe eerst deze snelle toegankelijkheidscheck

Je hoeft geen ontwikkelaar te zijn om de eerste problemen te vinden. Open je website en probeer de volgende controles:

• Leg je muis weg. Kun je met Tab, Shift+Tab, Enter en Escape door menu’s, knoppen, formulieren en pop-ups bewegen?
• Vergroot de pagina tot 200%. Blijft de tekst leesbaar en blijft belangrijke inhoud bruikbaar zonder dat delen over elkaar heen schuiven of verdwijnen?
• Bekijk de pagina op je telefoon en vergroot daar ook de tekst. Kun je nog bij het menu, de cookieknoppen en de belangrijkste acties?
• Open een formulier en maak bewust een fout. Is duidelijk welk veld fout is, waarom en hoe je het herstelt?
• Zet het geluid uit bij een video. Blijft de boodschap begrijpelijk door ondertiteling of een tekstalternatief?
• Kijk naar links en knoppen. Begrijp je hun functie nog als je alleen de linktekst of knoptekst zou horen?

Wil je een neutrale eerste controle volgen, dan biedt W3C Easy Checks een reeks eenvoudige handmatige tests. Zie dit als een eerste screening, niet als een volledige audit.

1. Zorg dat de hele website met een toetsenbord werkt

Een van de nuttigste tests is verrassend simpel: gebruik je website zonder muis. Met de Tab-toets moet je van interactief element naar interactief element kunnen gaan. Met Enter of Spatie moet je acties kunnen uitvoeren en met Escape moet je bijvoorbeeld een open menu of dialoogvenster kunnen sluiten wanneer dat logisch is.

Let vooral op navigatiemenu’s, cookie-banners, filters, formulieren, sliders en pop-ups. Dat zijn vaak de plekken waar een website er visueel goed uitziet, maar waar toetsenbordgebruikers vastlopen.

Wie een website toegankelijk wil maken voor blinde en slechtziende bezoekers, heeft hier ook baat bij: schermlezers werken veel beter wanneer de onderliggende bediening en volgorde logisch zijn.

2. Laat altijd zien waar de toetsenbordfocus staat

Als je door een pagina tabt, moet je kunnen zien welk element actief is. Een duidelijke focusrand rond een link, knop of invoerveld voorkomt dat de gebruiker moet raden waar hij zich op de pagina bevindt.

Verwijder de standaard focusstijl dus niet alleen omdat een designer de rand niet mooi vindt. Je kunt de focus vormgeven in je huisstijl, zolang hij zichtbaar blijft en voldoende contrasteert met de omgeving.

WCAG 2.2 besteedt extra aandacht aan focus: een actief element mag niet volledig achter andere content verdwijnen. Dat is bijvoorbeeld relevant bij sticky headers, cookiepanelen en vaste chatknoppen.

3. Bouw je pagina op met echte, logische koppen

Een H1, H2 of H3 is geen manier om tekst groter te maken. Koppen beschrijven de structuur van de pagina. Daardoor kunnen bezoekers snel scannen en kunnen schermlezers van kop naar kop springen.

Gebruik één duidelijke paginatitel en werk daarna hiërarchisch. Een H3 hoort onder een H2, niet omdat de lettergrootte mooier uitkomt, maar omdat het inhoudelijk een onderdeel van die H2 is.

Diezelfde discipline is ook goed voor zoekmachines: Google raadt beschrijvende titels, duidelijke koppen en semantische HTML aan. Dat betekent niet dat WCAG-conformiteit op zichzelf een rankingfactor is. Toegankelijkheid is in de eerste plaats voor gebruikers; sommige goede praktijken overlappen simpelweg met goede SEO.

4. Controleer contrast, tekstgrootte en inzoomen

Lichtgrijze tekst op een witte achtergrond kan elegant lijken, maar voor veel mensen is hij moeilijk leesbaar. Hetzelfde geldt voor tekst boven een foto of een knop waarvan tekst en achtergrond nauwelijks van elkaar verschillen.

WCAG gebruikt meetbare contrastcriteria. Voor gewone tekst is 4,5:1 een bekende AA-drempel; voor grote tekst geldt doorgaans 3:1. Laat kleur bovendien niet de enige manier zijn waarop je een fout, status of keuze communiceert.

Test ook wat er gebeurt wanneer iemand tekst vergroot. De bezoeker mag geen belangrijke informatie verliezen omdat onderdelen buiten beeld vallen, over elkaar schuiven of alleen met horizontaal scrollen leesbaar worden.

5. Schrijf alt-teksten die de functie van een afbeelding uitleggen

Alt-tekst is geen plek om extra zoekwoorden te stoppen. Het is een tekstalternatief voor iemand die de afbeelding niet ziet. Beschrijf daarom wat de afbeelding in deze specifieke context bijdraagt.

Een foto die alleen decoratie is, heeft meestal geen beschrijvende tekst nodig en kan een lege alt-waarde krijgen. Een grafiek met belangrijke cijfers vraagt juist meer uitleg dan één korte zin. Zet de essentie dan ook in de gewone tekst of voorzie een langere beschrijving.

Goede alt-tekst kan tegelijk nuttig zijn voor toegankelijkheid en voor Google Afbeeldingen, maar schrijf hem eerst voor de gebruiker. Een reeks keywords helpt niemand.

6. Maak link- en knopteksten begrijpelijk zonder visuele context

Een schermlezergebruiker kan een pagina laten samenvatten als lijst met links. Tien keer ‘klik hier’ zegt dan niets. Gebruik teksten die de bestemming of actie beschrijven: ‘Bekijk onze webmasterdiensten’ is bijvoorbeeld duidelijker dan ‘Meer info’.

Hetzelfde geldt voor icoonknoppen. Een vergrootglas is voor veel ziende bezoekers herkenbaar als zoeken, maar een schermlezer heeft een toegankelijke naam nodig. Gebruik waar mogelijk echte HTML-knoppen met een duidelijke tekst of naam.

7. Zorg dat formulieren ook bij fouten begrijpelijk blijven

Contact- en checkoutformulieren zijn commercieel belangrijke onderdelen van een website. Juist daar komen toegankelijkheidsproblemen vaak hard aan: onzichtbare labels, onduidelijke verplichte velden, foutmeldingen die alleen rood kleuren of een formulier dat na een fout weer bovenaan begint zonder uitleg.

Geef ieder veld een echt label, maak duidelijk welke informatie verwacht wordt en beschrijf fouten in gewone taal. ‘Ongeldige invoer’ is minder behulpzaam dan ‘Vul een geldig e-mailadres in, bijvoorbeeld naam@bedrijf.be’.

Controleer ook of de foutmelding programmatisch aan het juiste veld gekoppeld is. Dat is technisch werk, maar maakt voor schermlezers een groot verschil.

8. Voorzie alternatieven voor video en audio

Als belangrijke informatie alleen gesproken wordt, sluit je mensen uit die het geluid niet kunnen horen. Goede ondertiteling helpt doven en slechthorenden en is tegelijk handig in omgevingen waar geluid ongewenst is.

Bij audio kan een transcript een goede oplossing zijn. Bij video waarin relevante informatie alleen visueel verschijnt, kan extra beschrijving nodig zijn. Het juiste alternatief hangt af van de inhoud; één automatisch gegenereerde ondertiteling zonder controle is niet altijd voldoende.

9. Vergeet menu’s, pop-ups en cookie-banners niet

Een website kan op de gewone pagina’s behoorlijk toegankelijk zijn en toch stuklopen op één overlay. Een cookiebanner die de hele pagina blokkeert maar niet met het toetsenbord te sluiten is, maakt de rest van de website praktisch onbereikbaar.

Test daarom navigatiemenu’s, modals, chatvensters, filters, cookievoorkeuren en andere lagen apart. Focus moet naar een geopend dialoogvenster gaan, de gebruiker moet begrijpen wat er geopend is en na sluiten logisch kunnen verdergaan.

Dit zijn typische punten die je niet oplost met alleen wat extra alt-teksten. Soms moet de HTML-structuur of JavaScript-interactie worden aangepast.

10. Denk op mobiel aan aanraken, draaien en vergroten

Toegankelijkheid stopt niet bij desktop. Kleine knoppen die dicht tegen elkaar staan zijn lastig voor iemand met beperkte fijne motoriek, maar ook voor iedereen die onderweg met één hand navigeert.

WCAG 2.2 bevat een AA-criterium voor de minimale grootte van veel aanraakdoelen, met uitzonderingen. In de praktijk is de boodschap eenvoudig: geef knoppen en links voldoende ruimte en voorkom dat een gebruiker op een piepklein icoon moet mikken.

Controleer ook of belangrijke functies blijven werken wanneer het scherm wordt gedraaid en wanneer tekst groter wordt ingesteld via de toegankelijkheidsopties van iOS of Android.

11. Schrijf duidelijk en voorspelbaar

Technische toegankelijkheid is belangrijk, maar begrijpelijkheid hoort er net zo goed bij. Gebruik consistente benamingen in je navigatie, zet belangrijke informatie niet verstopt in lange alinea’s en laat knoppen doen wat hun tekst belooft.

Vermijd instructies die alleen naar kleur of positie verwijzen, zoals ‘klik op de groene knop rechts’. Die aanwijzing werkt niet voor iedereen en kan op mobiel zelfs feitelijk onjuist zijn.

Een rustige structuur, duidelijke foutmeldingen en gewone taal maken een website niet alleen toegankelijker, maar verminderen ook twijfel voor bezoekers die gewoon snel iets willen vinden of bestellen.

12. Gebruik semantische HTML en zet ARIA alleen in waar het nodig is

Veel toegankelijkheid begint in de broncode. Een echte knop, een correct formulierlabel, een nav-element en een logisch headingniveau bevatten al betekenis die browsers en hulpmiddelen begrijpen.

ARIA-attributen kunnen extra informatie geven wanneer standaard HTML niet voldoende is, maar ze zijn geen pleister voor slechte markup. Een visueel element dat zich gedraagt als knop bouw je bij voorkeur als echte knop, in plaats van een generieke div met een stapel extra attributen.

Dit is ook waarom een toegankelijkheidswidget nooit automatisch alle problemen van een website kan oplossen. Als de basisstructuur, formulieren of interacties verkeerd zijn opgebouwd, moet de onderliggende website worden aangepast.

Wat betekenen WCAG 2.2 en de EAA voor Belgische bedrijven?

WCAG en de European Accessibility Act (EAA) zijn niet hetzelfde. WCAG is een internationale technische standaard voor webtoegankelijkheid. De EAA is Europese wetgeving die toegankelijkheidseisen oplegt aan bepaalde producten en diensten.

In België zijn de regels sinds 28 juni 2025 relevant voor onder meer e-handelsdiensten en bankdiensten voor consumenten. FOD Economie vermeldt daarbij dat micro-ondernemingen — minder dan tien werknemers en een jaaromzet of balanstotaal onder 2 miljoen euro — vijf jaar extra tijd krijgen om zich aan de nieuwe Belgische regelgeving aan te passen.

Dat betekent niet dat elke gewone bedrijfswebsite automatisch op exact dezelfde manier onder de EAA valt. De vraag hangt af van wat je onderneming aanbiedt, aan wie je diensten levert en welke onderdelen van de regelgeving op jouw situatie van toepassing zijn. Een webshop die aan consumenten verkoopt vraagt bijvoorbeeld een andere beoordeling dan een eenvoudige B2B-informatiesite.

Valt je onderneming onder de regels, dan gaat het niet alleen om kleurcontrast of alt-teksten. FOD Economie wijst ook op duidelijke informatie over de dienst, bruikbare digitale platformen en compatibiliteit met hulptechnologieën.

Deze paragraaf is algemene informatie en geen juridisch advies. Bij twijfel over de wettelijke verplichtingen van jouw onderneming is het verstandig om de actuele richtlijnen van FOD Economie te controleren of gespecialiseerd advies in te winnen.

Kan een automatische WCAG-checker zeggen of je site toegankelijk is?

Nee. Een automatische scan is handig om bepaalde technische fouten snel te vinden, maar een groen scorebord is geen bewijs dat echte mensen je website zonder barrières kunnen gebruiken.

Een tool kan bijvoorbeeld ontbrekende alt-attributen of sommige contrastproblemen signaleren. Maar hij begrijpt niet automatisch of een alt-tekst inhoudelijk goed is, of een foutmelding begrijpelijk is, of de focusvolgorde logisch voelt en of een complexe checkout met een schermlezer echt werkbaar is.

W3C raadt daarom een bredere evaluatie aan. Combineer automatische controles met handmatige toetsenbordtests, inzoomen, controle van formulieren, tests met schermlezers en — waar mogelijk — feedback van mensen die zelf hulpmiddelen gebruiken.

Wanneer heb je technische hulp nodig?

Contentbeheerders kunnen zelf veel verbeteren: duidelijke koppen, betere linkteksten, bruikbare alt-teksten, ondertitels en begrijpelijke formulierteksten. Maar sommige problemen zitten dieper in het thema, de pagebuilder, plug-ins of maatwerkcode.

Schakel technische hulp in wanneer toetsenbordbediening niet werkt, focus verdwijnt, menu’s of modals vastlopen, formulierlabels ontbreken in de HTML, de leesvolgorde fout is of de website bij vergroten uit elkaar valt. Ook een checkout of klantenportaal verdient extra aandacht omdat één blokkade daar rechtstreeks een aanvraag of verkoop kan kosten.

Soms blijkt uit een toegankelijkheidscontrole dat de bestaande site technisch moeilijk te herstellen is. Dan kan website laten vernieuwen verstandiger zijn dan losse patches blijven stapelen. Voor gerichte aanpassingen en opvolging kun je ook kijken naar de webmasterdiensten van Moonbeetle.

Veelgestelde vragen over een toegankelijke website

Hoe weet ik of mijn website toegankelijk is?

Begin met handmatige controles: gebruik de site zonder muis, vergroot tekst, controleer formulieren en probeer belangrijke onderdelen met een schermlezer. Een automatische scanner kan extra fouten vinden, maar voor een betrouwbare beoordeling is een bredere audit nodig.

Moet elke Belgische website aan de EAA voldoen?

Niet automatisch op dezelfde manier. De EAA en Belgische omzetting richten zich op bepaalde producten en diensten. Voor e-commerce en consumentgerichte bankdiensten gelden specifieke regels. De exacte verplichtingen hangen af van je activiteit en onderneming.

Is WCAG 2.2 verplicht voor mijn website?

WCAG 2.2 is de actuele W3C-standaard en een sterk praktisch doel voor nieuwe of aangepaste websites. Welke versie of norm juridisch van toepassing is, hangt af van het relevante wettelijke kader. Gebruik WCAG dus als technische basis, maar controleer wettelijke verplichtingen apart.

Helpt toegankelijkheid om hoger te scoren in Google?

Toegankelijkheid is geen algemene rankingfactor waarop je een positie kunt voorspellen. Er is wel overlap met goede SEO: Google gebruikt bijvoorbeeld alt-tekst om afbeeldingen beter te begrijpen en raadt semantische HTML, duidelijke titels en beschrijvende links aan. De belangrijkste reden om toegankelijk te bouwen blijft dat meer mensen je website kunnen gebruiken.

Kan een toegankelijkheidsplugin mijn website WCAG-proof maken?

Een plugin of widget kan bepaalde functies verbeteren, maar kan structurele problemen in HTML, formulieren, toetsenbordbediening of interactieve componenten niet automatisch oplossen. Zie zo’n tool als mogelijke ondersteuning, niet als vervanging voor goed ontwerp, ontwikkeling en testen.

Moet ik mijn hele website in één keer aanpassen?

Niet altijd. Begin bij de belangrijkste gebruikersroutes: navigatie, contactformulier, offerteaanvraag, login en — bij een webshop — productpagina, winkelmand en checkout. Los blokkades eerst op en werk daarna systematisch verder.

Bronnen voor verdere controle

• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• W3C — Easy Checks: A First Review of Web Accessibility
• FOD Economie — Richtlijn over toegankelijkheid: een stap dichter naar een inclusieve samenleving
• Belgian Web Accessibility — informatie en hulpmiddelen rond digitale toegankelijkheid