Toegankelijkheid van uw website testen: gratis tools en handmatige controles

Dit verhaal horen we vaak. Iemand draait Lighthouse, krijgt een groene 100 voor toegankelijkheid en gaat verder. Een week later mailt een klant dat ze niet kon betalen, omdat het kaartformulier niet met het toetsenbord te bereiken is. Allebei waar. De automatische controle slaagde, en de site liet toch een echt mens in de steek.

Deze gids laat zien hoe u met een klein budget goed test: welke gratis tools u gebruikt, een handmatige routine van 15 minuten, een eerste poging met een schermlezer en wanneer het loont om voor een audit te betalen.

Kan een automatische checker zeggen of mijn website toegankelijk is?

Nee. Automatische checkers vinden sommige problemen snel, maar veel vragen over toegankelijkheid kan alleen een mens beantwoorden. Toen de Government Digital Service van de Britse overheid 10 tools testte op een pagina met 143 bekende fouten, vond de beste 41%. Het W3C zegt het duidelijk: evaluatietools “kunnen toegankelijkheid niet vaststellen, ze kunnen daar alleen bij helpen”.

De test van GDS (opent in een nieuw tabblad) dateert van februari 2017, en die 41% (van Asqatasun) omvatte de aanwijzingen van de tool voor handmatige controles. Tools zijn sindsdien beter geworden, maar het gat heeft dezelfde oorzaak. Software ziet dat een afbeelding geen alt-tekst heeft. Ze ziet niet dat “rode jurk” de verkeerde beschrijving is voor een foto van een blauw pak, en ook niet of uw focusvolgorde logisch is.

Zie een checker dus als rookmelder, niet als bouwkundige keuring. Draaien is wel de moeite waard: de scan WebAIM Million 2026 (opent in een nieuw tabblad) vond gedetecteerde fouten op 95,9% van de 1 miljoen meestbezochte homepages, dus op de meeste sites valt met weinig moeite al veel te verbeteren. Of zoals de gids van het W3C voor het kiezen van tools (opent in een nieuw tabblad) zegt: “Menselijk oordeel is nodig.”

Welke gratis tools voor toegankelijkheidstests moet ik gebruiken?

Gebruik een of twee automatische checkers, een contrastchecker en een schermlezer. Tools passen verschillende regels toe en rapporteren op verschillende manieren, dus twee checkers vangen meestal meer dan één. Elke tool hieronder heeft een gratis versie. Controleer de actuele voorwaarden voordat u erop vertrouwt, want namen, functies en prijzen veranderen.

Wat kan ik in 15 minuten handmatig controleren?

Heel wat. De Easy Checks (opent in een nieuw tabblad) van het W3C gaan over paginatitels, alt-tekst, koppen, contrast, skiplinks, zichtbare toetsenbordfocus, paginataal, zoom, ondertiteling en formulierlabels. Kies één belangrijke pagina, zoals een productpagina of uw boekingsformulier, en geef elke controle een minuut of twee. U vindt dingen die geen checker meldt.

Volgens het W3C “behandelen deze controles maar een paar toegankelijkheidsproblemen”, dus ze zijn geen volledige evaluatie. Het blijft het best bestede kwartier dat er is:

1. Paginatitel (1 minuut). Zegt het tabblad van de browser welke pagina het is, zoals “Tafel reserveren | Rosa's Keuken”, in plaats van overal “Home”?
2. Afbeeldingen (2 minuten). Laat de alt-tekst zien met WAVE of een vergelijkbare tool. Klopt die? Wordt decoratie overgeslagen?
3. Koppen (2 minuten). Zet de koppen op een rij en lees ze los. Werken ze als inhoudsopgave?
4. Contrast (2 minuten). Controleer broodtekst, kleine grijze tekst, knoptekst en tekst over afbeeldingen.
5. Toetsenbord (4 minuten). Leg de muis weg en ga met Tab door de pagina (zie het volgende deel).
6. Zoom (2 minuten). Kunt u bij 200% en daarna bij 400% nog alles lezen en het menu gebruiken zonder zijwaarts te scrollen?
7. Formulieren en taal (2 minuten). Klik op het label van elk veld; in een goed gebouwd formulier komt de cursor dan in het veld. Kijk in het rapport van de tool of de paginataal ontbreekt.

Hoe test ik met een toetsenbord?

Leg de muis weg. Met Tab gaat u vooruit, met Shift+Tab terug, met Enter volgt u links, met de spatiebalk of Enter drukt u op knoppen, en met de pijltjestoetsen beweegt u in menu's en keuzerondjes. Elk interactief element moet bereikbaar zijn, u moet altijd zien waar u bent en u mag nergens vast komen te zitten.

Op een Mac slaat Safari links over als u op Tab drukt, tot u in de geavanceerde instellingen de optie aanzet waarmee Tab elk onderdeel van een webpagina markeert. Controleer daarna:

• Ziet u altijd waar u bent? Verdwijnt het focuskader, dan is een toetsenbordgebruiker de weg kwijt.
• Is de volgorde logisch? De focus hoort de leesvolgorde te volgen.
• Wordt er iets bedekt? Een vaste header of cookiebanner die het element met focus verbergt, voldoet niet aan het WCAG 2.2-criterium Focus niet bedekt.
• Komt u er weer uit? Open elk menu, elke pop-up en elke datumkiezer en probeer ze daarna te verlaten. Escape moet dialoogvensters sluiten.
• Werkt de hele route? Voeg een product toe, verander het aantal, voer een kortingscode in en kom zonder muis tot de betaling.

Schrijf elke fout precies op: “De maatkiezer op de productpagina gaat niet open met Enter of de spatiebalk” wordt veel sneller opgelost dan “toetsenbord werkt niet”.

Hoe test ik voor het eerst met een schermlezer?

Begin met de schermlezer die uw apparaat al heeft, of met NVDA op Windows, en luister naar één pagina. U hoeft hem niet als een expert te gebruiken. U controleert of koppen, links, knoppen, afbeeldingen en formuliervelden met zinnige namen worden voorgelezen, en of er niets belangrijks stil blijft.

• Mac: Command+F5 zet VoiceOver aan en uit; Control+Option+U opent de rotor, een lijst met koppen, links en formulierelementen.
• Windows: in NVDA springt u met H van kop naar kop, en Insert+F7 toont een lijst met links en koppen.
• Telefoon: zet VoiceOver (iPhone) of TalkBack (Android) aan en veeg naar rechts om van onderdeel naar onderdeel te gaan. Zoek eerst uit hoe u het weer uitzet.

Let op wat het meest telt. In de schermlezerenquête van WebAIM uit 2024 (opent in een nieuw tabblad) zei 71,6% van de deelnemers dat ze een lange pagina eerst via de koppen verkennen, dus begin daar. Open daarna de lijst met links: vijf links met de naam “Lees meer” zeggen niemand iets. “In winkelwagen, marineblauwe trui” is een bruikbare knop; “knop” niet. Vul ten slotte een formulier in en controleer of elk veld en elke fout wordt voorgelezen.

Wees bescheiden in uw conclusies. Klinkt iets niet goed, dan is het dat waarschijnlijk ook niet; klinkt het prima, dan is dat nog geen bewijs. Hoe ervaren gebruikers echt werken, leest u in hoe mensen met een beperking het web gebruiken.

Hoe controleer ik zoom, reflow en tekstafstand?

Zoom uw browser in tot 200% en controleer of tekst groter wordt zonder te worden afgekapt of te overlappen. Test daarna de reflow: bij 400% zoom in een venster van 1.280 pixels breed moet de inhoud passen zonder zijwaarts te scrollen. Vergroot ten slotte de ruimte tussen letters, woorden, regels en alinea's, en controleer of er niets breekt of verdwijnt.

Dit hoort bij de WCAG-criteria Herschalen van tekst (1.4.4), Reflow (1.4.10) (opent in een nieuw tabblad) en Tekstafstand (1.4.12) (opent in een nieuw tabblad). Reflow gaat uit van een breedte van 320 CSS-pixels, wat volgens het W3C “overeenkomt met een beginbreedte van de viewport van 1280 CSS-pixels bij 400% zoom”. Tekstafstand vraagt dat er niets verloren gaat als een lezer de regelhoogte op 1,5 keer de lettergrootte zet, de alinea-afstand op 2 keer, de letterafstand op 0,12 keer en de woordafstand op 0,16 keer.

Een bookmarklet voor tekstafstand, een klein script dat u als bladwijzer bewaart, past alle vier de waarden met één klik toe. Let op tekst die uit knoppen loopt en labels die aan de rand worden afgekapt. Bij 400% zoom toont een laptop ongeveer wat een kleine telefoon toont, dus een goed gebouwde responsieve site doorstaat hiervan al veel.

Hoe controleer ik formulieren, foutmeldingen en de checkout?

Vul elk belangrijk formulier drie keer in: één keer goed, één keer met alle velden leeg en één keer met opzettelijke fouten. Elk veld moet een zichtbaar label hebben, elke fout moet in woorden naast het bijbehorende veld worden uitgelegd, en u moet kunnen plakken in velden voor wachtwoorden en verificatiecodes.

• Fouten. “Ongeldige invoer” in rood is niet genoeg. “Vul de vervaldatum in als MM/JJ”, naast het veld, wel. Na het versturen moet de focus naar het overzicht van fouten of naar het eerste foute veld gaan.
• Inloggen en codes. Volgens het WCAG 2.2-criterium Toegankelijke authenticatie (opent in een nieuw tabblad) zakt u als u plakken of wachtwoordmanagers blokkeert, tenzij er een andere manier is om in te loggen.
• CAPTCHA's en tijdslimieten. Schermlezergebruikers noemden de CAPTCHA in de enquête van WebAIM het lastigste onderdeel van het web. Controleer of er een toegankelijk alternatief is en of tijdslimieten te verlengen zijn.

Onze checklist voor websitetoegankelijkheid heeft een uitgebreidere lijst voor webshops, inclusief cookiebanners en pop-ups.

Wat houdt een professionele toegankelijkheidsaudit in, en wanneer heb ik er een nodig?

Een toegankelijkheidsaudit is een gestructureerde beoordeling door een specialist aan de hand van een benoemde norm, meestal WCAG 2.1 of 2.2 niveau AA. Die combineert automatische scans met handmatige tests en tests met hulptechnologie op uw belangrijkste templates en routes, en eindigt met een rapport met prioriteiten. U hebt er een nodig als de wet voor u geldt, vóór een grote lancering of als klanten om bewijs vragen.

Vraag dit voordat u met een prijs akkoord gaat:

• Aan welke norm, versie en welk niveau wordt getoetst?
• Welke templates en routes vallen erbinnen? Voor een webshop: home, categorie, product, winkelwagen, checkout, accountpagina's en formulieren.
• Test u handmatig met schermlezers, toetsenbord en zoom, en op welke browsers en apparaten?
• Rangschikt het rapport problemen op ernst, geeft het aan waar ze zitten en stelt het oplossingen voor?
• Zit er een hertest bij?

Prijzen lopen sterk uiteen per aanbieder, land en omvang, dus vergelijk wat er is inbegrepen. Valt u onder de European Accessibility Act, dan onderbouwt een audit ook uw openbare verklaring; voor wie de wet geldt, leest u in onze gids over de EAA.

Waarom testen met mensen met een beperking?

Omdat aan een norm voldoen en makkelijk te gebruiken zijn niet hetzelfde is. Een checkout kan aan elk WCAG-criterium voldoen en een schermlezergebruiker toch twintig minuten kosten. Het W3C zegt dat evalueren met gebruikers met een beperking “bruikbaarheidsproblemen aan het licht brengt die een conformiteitsbeoordeling alleen niet vindt”, en het laat uw team zien hoe mensen de site echt gebruiken.

U hebt geen lab nodig. Een handvol sessies over uw belangrijkste taak, zoals een product vinden en betalen, leert u meer dan nog een ronde scans. Werf deelnemers via belangenorganisaties van mensen met een beperking, onderzoeksbureaus of uw eigen klanten, en betaal mensen voor hun tijd. Laat ze hun eigen apparaten en instellingen gebruiken. De gids van het W3C over gebruikers betrekken bij evaluatie (opent in een nieuw tabblad) behandelt de praktische kant.

Wat doe ik met de resultaten?

Sorteer de problemen op hoe erg ze mensen blokkeren en waar ze zich voordoen, los ze op in de eigen code en inhoud van de site, test opnieuw en leg vast wat nog openstaat. Een veld zonder label in de checkout weegt zwaarder dan een contrastfoutje in de footer, en een oplossing in een gedeelde template repareert elke pagina die die template gebruikt.

1. Prioriteer. Eerst blokkades op belangrijke routes (afrekenen, boeken, aanmelden), dan gedeelde templates, dan losse pagina's.
2. Los het bij de bron op. Pas het thema, de component of de inhoud aan, niet alleen het symptoom.
3. Test opnieuw. Herhaal dezelfde controles, handmatig en met tools.
4. Leg vast. Vermeld bekende problemen met datum in uw toegankelijkheidsverklaring. Onze gids over WCAG 2.2 legt de nieuwere criteria uit.
5. Herhaal. Maak een toetsenbordcontrole en een scan onderdeel van elke release.

Gebruikt u een toegankelijkheidswidget, ook de onze, test dan met het paneel dicht. Een paneel zoals SiteAccessible geeft bezoekers extra manieren om de pagina aan te passen, maar WCAG kijkt of de pagina in de standaardstand werkt. Sommige keurmerken beoordelen geen pagina's waarop een overlayscript draait, dus overleg eerst met uw auditor.