Toegankelijkheidsaudit uitvoeren: complete gids en checklist

Een toegankelijkheidsaudit voer je uit door eerst de belangrijkste pagina’s en gebruikersflows af te bakenen, daarna automatische controles te combineren met handmatige tests en alle bevindingen vast te leggen voor herstel en hertest. Alleen een scan draaien is niet genoeg: automatische tools herkennen niet alle toegankelijkheidsproblemen. Gebruik WCAG 2.2 als beoordelingskader en test vooral wat een bezoeker daadwerkelijk moet kunnen doen.

Wat is een toegankelijkheidsaudit?

Een toegankelijkheidsaudit is een gestructureerd onderzoek naar barrières op je website. Je controleert bijvoorbeeld of iemand zonder muis kan navigeren, of formulieren begrijpelijk zijn, of tekst voldoende leesbaar is en of een screenreader de inhoud en bediening logisch kan overbrengen.

Een audit is breder dan een technische scan. W3C gebruikt de termen evaluatie, assessment, audit en testing voor het beoordelen van webtoegankelijkheid. De uitkomst is geen algemene uitspraak als “toegankelijk” of “niet toegankelijk”, maar een onderbouwd overzicht van wat je hebt getest, welke problemen je aantrof en welke verbeteringen nodig zijn.

Wanneer is een audit zinvol?

Voer in ieder geval een audit uit vóór een nieuw ontwerp of een grote livegang, na wijzigingen aan thema, formulieren of navigatie, en wanneer je merkt dat bezoekers moeite hebben met essentiële taken. Denk aan een contactaanvraag, het vinden van een dienst, inloggen of afrekenen.

Ook bij regulier websiteonderhoud is een periodieke controle verstandig. Nieuwe content, plugins, embeds en ontwerpaanpassingen kunnen onbedoeld nieuwe drempels veroorzaken. Technische fouten verdienen daarbij eveneens aandacht: kapotte links of foutieve doorverwijzingen kunnen een taak blokkeren. Controleer die apart met onze gids over 404- en soft-404-fouten.

Toegankelijkheidsaudit uitvoeren in 8 stappen

1. Bepaal scope, norm en gebruikersflows

Begin niet met alle URL’s tegelijk. Kies representatieve pagina’s en de belangrijkste routes die bezoekers afleggen. Neem verschillende templates mee, zoals de homepage, een dienstenpagina, een artikel, een formulier en eventuele zoek- of accountfunctionaliteit.

• Leg vast welke URL’s, onderdelen en apparaten je test.
• Noteer welke gebruikersflows essentieel zijn, bijvoorbeeld “dienst vinden en contact opnemen”.
• Leg het WCAG-niveau vast waarop je beoordeelt.
• Noteer datum, testomgeving, browser en eventuele hulpmiddelen.

Dit voorkomt dat bevindingen onvergelijkbaar worden of dat een audit alleen losse pagina’s beoordeelt zonder de cruciale gebruikersreis te testen.

2. Doe een automatische eerste controle

Gebruik een toegankelijkheidstool als startpunt om mogelijke problemen te signaleren. WordPress noemt onder meer axe en WAVE als hulpmiddelen bij toegankelijkheidstests. Behandel iedere melding als een controlepunt, niet als een definitief oordeel. Een tool kan bijvoorbeeld signaleren dat een afbeelding geen alternatieve tekst heeft, maar kan niet betrouwbaar bepalen of een aanwezige alt-tekst betekenisvol is.

Werk de meldingen per pagina af en controleer ze in de interface én in de onderliggende HTML waar nodig. Noteer ook problemen die een tool niet meldt maar die je tijdens gebruik tegenkomt.

3. Test de volledige bediening met alleen het toetsenbord

Gebruik Tab, Shift+Tab, Enter, Spatie en de pijltjestoetsen waar relevant. Doorloop daarmee elke gekozen gebruikersflow. Let niet alleen op óf je een element bereikt, maar ook op de logische volgorde en het resultaat van de actie.

• Is direct zichtbaar waar de toetsenbordfocus staat?
• Kun je een skiplink gebruiken om herhaalde navigatie over te slaan?
• Zijn menu’s, zoekfuncties, accordeons, tabbladen en modals te openen en sluiten?
• Raakt de focus niet vast in een onderdeel of verdwijnt deze niet uit beeld?
• Kun je een formulier verzenden zonder muis?

Een onzichtbare of onlogische focus is een veelvoorkomende blokkade. Leg bij elk probleem vast vanaf welk element je navigeerde, welke toets je gebruikte en wat er gebeurde.

4. Controleer structuur, links en formulieren

Een goed uitziende pagina kan toch lastig te begrijpen zijn voor bezoekers die de structuur via een hulpmiddel ervaren. Controleer daarom de semantiek en de beschikbare instructies.

• Hebben pagina’s een logische koppenstructuur?
• Beschrijven links hun bestemming of actie voldoende duidelijk?
• Heeft ieder formulierveld een zichtbaar of programmatisch gekoppeld label?
• Zijn verplichte velden en invoervereisten vóór verzending duidelijk?
• Zijn foutmeldingen begrijpelijk, gekoppeld aan het relevante veld en bruikbaar met toetsenbord?
• Blijven foutmeldingen of bevestigingen beschikbaar zolang de bezoeker ze nodig heeft?

Gebruik ARIA alleen wanneer HTML alleen niet genoeg is en controleer vervolgens altijd de daadwerkelijke bediening. ARIA kan betekenis toevoegen, maar herstelt geen onlogische interactie of gebrekkige toetsenbordbediening.

5. Beoordeel afbeeldingen, contrast, zoom en responsief gedrag

Controleer afbeeldingen in hun context. Informatieve afbeeldingen hebben een passend tekstalternatief nodig; decoratieve afbeeldingen mogen geen ruis veroorzaken voor screenreadergebruikers. Voor product- en sfeerbeelden in WordPress kun je ook de praktische keuzes uit afbeeldingen optimaliseren in WordPress meenemen, al gaat optimalisatie verder dan toegankelijkheid alleen.

Beoordeel daarnaast of informatie niet uitsluitend via kleur wordt overgebracht, of tekst en bediening voldoende onderscheidbaar zijn en of de pagina bruikbaar blijft bij inzoomen en op een smal scherm. Test echte taken, zoals een formulier invullen of een menu openen, in plaats van alleen naar de lay-out te kijken.

6. Test met een screenreader

Een screenreadercontrole laat zien of de structuur en statusinformatie begrijpelijk worden aangekondigd. Doorloop ten minste de kernflows en luister of koppen, links, knoppen, velden, foutmeldingen en dynamische wijzigingen logisch worden gepresenteerd.

Let extra op menu’s die uitklappen, meldingen na een formulieractie en dialoogvensters. De gebruiker moet kunnen begrijpen wat er veranderde en de bediening moet voorspelbaar blijven. WordPress benadrukt toetsenbord- en screenreadercontroles als onderdelen van toegankelijkheidstesten.

7. Leg bevindingen eenduidig vast

Een bruikbaar auditrapport maakt een probleem reproduceerbaar voor degene die het oplost. Beschrijf dus niet alleen “formulier is niet toegankelijk”, maar leg precies vast waar en hoe het misgaat. De rapportagetemplate van W3C biedt hiervoor een bruikbare structuur met scope, proces, gebruikte tools, resultaten en vervolgacties.

8. Prioriteer, herstel en hertest

Prioriteer eerst problemen die een essentiële taak blokkeren, meerdere pagina’s raken of veel bezoekers kunnen treffen. Pak daarna structurele fouten in componenten en templates aan, omdat één verbetering dan op veel plaatsen effect kan hebben. Hertest na iedere wijziging de oorspronkelijke fout én de volledige gebruikersflow. Een oplossing die technisch correct lijkt, kan in de praktijk een nieuw bedieningsprobleem introduceren.

Praktische audit-scorecard

Gebruik onderstaande scorecard tijdens je eerste audit. Vul per rij de status in als “in orde”, “probleem gevonden” of “niet van toepassing” en voeg bij een probleem een URL, bewijs en eigenaar toe in je rapport.

Onderdeel	Concrete controle	Voorbeeld van een probleem	Prioriteit bij fout
Toetsenbord	Doorloop menu, content, formulier en footer zonder muis.	De focus is niet zichtbaar op een knop.	Hoog als bediening niet mogelijk is
Navigatie	Open en sluit menu’s, submenu’s en modals met toetsen.	Een submenu opent wel, maar is niet meer te sluiten.	Hoog
Koppen en landmarks	Controleer of hoofdinhoud, navigatie en koppen logisch zijn opgebouwd.	Een visuele kop is alleen opgemaakt als gewone tekst.	Middel
Links en knoppen	Beoordeel of naam en doel van ieder interactief element duidelijk zijn.	Meerdere links heten alleen “Lees meer”.	Middel
Formulieren	Vul verplichte velden fout en goed in, met toetsenbord.	Een foutmelding noemt niet welk veld moet worden aangepast.	Hoog bij een kernflow
Afbeeldingen	Controleer de functie en het tekstalternatief per afbeelding.	Een informatieve afbeelding heeft geen passend alternatief.	Middel
Kleur en contrast	Controleer tekst, iconen, foutstatussen en bedieningsstatussen.	Een fout wordt alleen met een rood randje aangegeven.	Middel
Zoom en mobiel	Vergroot de pagina en voer dezelfde kerntaak uit op een smal scherm.	De verzendknop valt buiten beeld of overlapt andere inhoud.	Hoog bij een kernflow
Screenreader	Beluister koppen, formulieren, meldingen en dynamische onderdelen.	Na verzending wordt een bevestiging niet aangekondigd.	Hoog
Herstelcontrole	Test de oorspronkelijke fout opnieuw in de volledige gebruikersflow.	De losse knop werkt, maar de focusvolgorde is nu onlogisch.	Afhankelijk van impact

Rapportage: wat moet in je audit staan?

Maak van losse notities een werkbaar verbeterdocument. Neem per bevinding minimaal het volgende op:

• URL en paginatitel;
• onderdeel of component, zoals hoofdnavigatie of contactformulier;
• het relevante WCAG-succescriterium, voor zover je dat hebt beoordeeld;
• stappen om het probleem te reproduceren;
• verwacht en feitelijk gedrag;
• bewijs, bijvoorbeeld een schermafbeelding of korte opname;
• impact op de gebruiker en prioriteit;
• concrete aanbeveling, verantwoordelijke en status na hertest.

Maak onderscheid tussen een probleem op één pagina en een probleem in een herbruikbaar WordPress-blok, themaonderdeel of plugin. Die tweede categorie verdient vaak eerdere aandacht, omdat dezelfde fout op meerdere URL’s kan terugkeren.

WordPress-aandachtspunten

In WordPress ontstaan toegankelijkheidsproblemen vaak in thema’s, pagebuilderblokken, formulieren, pop-ups, cookie- of chatwidgets en plug-ins die interactieve onderdelen toevoegen. Controleer na updates en nieuwe blokken daarom opnieuw de kernflows. Test ook content die redacteuren zelf beheren, zoals alternatieve teksten, koppen, linkteksten en tabellen.

Wil je toegankelijkheid vanaf de basis meenemen in een nieuw ontwerp of een herbouw? Bespreek dat al in de strategie en componentkeuzes met een strategisch creatief webdesign-traject. LYNX Media helpt bedrijven daarnaast met de samenhang tussen webdesign, SEO, advertenties en conversieoptimalisatie. Bekijk alle diensten van LYNX Media of bespreek je website of online groeikansen met LYNX Media.

Veelgestelde vragen

Is een automatische toegankelijkheidsscan voldoende?

Nee. Automatische tools zijn nuttig om mogelijke fouten te vinden, maar kunnen niet alle toegankelijkheidsaspecten beoordelen. Vul scans altijd aan met handmatige toetsenbordtests, beoordeling van content en screenreadercontroles.

Welke pagina’s test ik als ik niet de hele website kan auditen?

Kies representatieve templates en de belangrijkste gebruikersflows. Neem in ieder geval pagina’s op waarmee bezoekers je belangrijkste doel kunnen bereiken, zoals informatie vinden, contact opnemen, een aanvraag doen of een aankoop afronden.

Bewijst een audit dat mijn website volledig WCAG-conform is?

Nee. Een audit geeft een onderbouwde beoordeling binnen een vastgelegde scope, testmethode en momentopname. Nieuwe content en wijzigingen kunnen nieuwe problemen veroorzaken. Plan daarom hertests en periodieke controles.