Webtoegankelijkheid: wat je eerst oplost
Toegankelijkheidswerk kent een lange checklist en een korte lijst met zaken die het merendeel van de werkelijke drempels verklaren. Met de korte lijst beginnen brengt echte gebruikers snel op je site; met een volledige audit beginnen levert meestal een document op dat niemand oppakt.
Deze gids behandelt wat je eerst oplost, hoe je het zelf in een middag test, en waarom overlay-widgets niet de snelweg zijn waarvoor ze verkocht worden.
De oplossingen met het grootste effect#
Dit zijn de drempels die mensen volledig verhinderen taken af te ronden, in plaats van ze iets lastiger te maken. Los ze op vóór alles wat op een langere lijst staat.
- Toetsenbordtoegang. Elk interactief element bereikbaar met Tab en bedienbaar met Enter of spatie, in een logische volgorde, met een zichtbare focusring. Kun je de site alleen met een muis gebruiken, dan doet niets anders op deze lijst ertoe.
- Tekstalternatieven. Zinvolle alt-tekst op afbeeldingen die informatie dragen; lege alt op decoratieve. Een ontbrekende alt is niet hetzelfde als een lege.
- Formulierlabels. Een echte <label> gekoppeld aan elk invoerveld. Voorbeeldtekst is geen label — die verdwijnt bij het typen en wordt niet betrouwbaar voorgelezen.
- Contrast. Lopende tekst op 4,5:1, grote tekst en bedieningselementen op 3:1, gecontroleerd tegen de echte achtergrond.
- Koppen. Eén H1, geen overgeslagen niveaus. Schermlezergebruikers navigeren meer op koppen dan op wat dan ook.
- Linktekst. Veertien keer «Lees meer» geeft een schermlezergebruiker veertien identieke bestemmingen. Zeg waar de link heen gaat.
- Foutmeldingen. Naast het veld, in tekst, met wat er moet gebeuren — niet alleen kleur, niet alleen een rode rand.
Test het zelf in een middag#
Je hebt geen specialistische software nodig om de meeste problemen te vinden. Deze vijf rondes kosten op een middelgrote site één tot twee uur en vinden het merendeel van de echte drempels.
| Test | Hoe | Wat het opspoort |
|---|---|---|
| Alleen toetsenbord | Muis loskoppelen, met Tab door elke pagina | Vallen, onzichtbare focus, onbereikbare bedieningselementen |
| Zoom naar 200 % | Tekstgrootte van de browser, geen paginazoom | Afgeknipte tekst, horizontaal scrollen, gebroken opmaak |
| Schermlezer | VoiceOver of NVDA op de hoofdsjablonen | Ontbrekende labels, betekenisloze links, niet aangekondigde wijzigingen |
| Geautomatiseerde scan | axe of Lighthouse in de browser | Contrast, ontbrekende alt, verkeerd ARIA-gebruik — zo'n 30 % van de problemen |
| Grijstinten | Browserfilter of systeeminstelling | Alles wat alleen via kleur wordt overgebracht |
Geautomatiseerde hulpmiddelen vinden ongeveer een derde van de toegankelijkheidsproblemen. Ze zijn een startpunt, geen voldoende: een site met 100 in Lighthouse kan met een toetsenbord nog steeds onbruikbaar zijn.
De patronen die de meeste problemen geven#
Zelfgebouwde componenten zijn waar toegankelijkheid meestal breekt, omdat native elementen gedrag meebrengen dat eigen componenten opnieuw moeten bouwen.
- Zelfgebouwde keuzelijsten van div's, zonder toetsenbordondersteuning of rollen. Een native <select> is gratis en werkt overal.
- Modale vensters die de focus niet vasthouden, niet met Escape sluiten en de achtergrond laten scrollen.
- Carrousels die vanzelf doorschuiven zonder pauzeknop — ze zijn vijandig voor vrijwel iedereen, niet alleen voor mensen met een beperking.
- Knoppen met alleen een pictogram zonder toegankelijke naam. Een kruisje zonder label wordt aangekondigd als «knop».
- Oneindig scrollen zonder manier om de voettekst te bereiken.
- Div-soep: klikbare div's in plaats van knoppen en links, wat toetsenbordondersteuning en semantiek in één keer verwijdert.
- Beweging die prefers-reduced-motion negeert.
De goedkoopste toegankelijkheidsstrategie is het native HTML-element voor de taak gebruiken. Elke zelfgebouwde vervanging is een belofte om gedrag opnieuw te bouwen dat gratis meekwam.
Waarom overlay-widgets geen oplossing zijn#
Toegankelijkheidsoverlays beloven naleving vanuit één script. Dat kunnen ze niet leveren, omdat de onderliggende problemen structureel zijn: een script kan niet weten wat een afbeelding voorstelt, kan geen label schrijven dat aansluit op het doel van een veld, en kan geen toetsenbordval in een zelfgebouwde component herstellen.
Ze verstoren bovendien de hulptechnologie die mensen al gebruiken en hebben ingesteld, en daarom raden verschillende belangenorganisaties ze af. Het is vooral nuttig ze te kennen zodat je ze met een verdedigbare reden kunt afwijzen.
- Ze kunnen geen nauwkeurige alt-tekst maken, want ze weten niet wat de afbeelding in context betekent.
- Ze kunnen geen toetsenbordvallen herstellen in componenten die ze niet gebouwd hebben.
- Ze botsen vaak met de eigen schermlezerinstellingen van de gebruiker.
- Ze nemen geen juridisch risico weg — de onderliggende drempels staan er nog.
- Het geld besteed je beter aan de zeven oplossingen bovenaan deze pagina.
Veelgestelde vragen
Is toegankelijkheid wettelijk verplicht?
In veel rechtsgebieden wel, voor overheidsorganisaties en steeds vaker voor private bedrijven — de European Accessibility Act, de ADA in de Verenigde Staten zoals toegepast op websites, en equivalenten elders. De verplichtingen verschillen per land en per sector, dus check het lokaal. Praktisch gezien is WCAG 2.2 AA de norm waar vrijwel elke regeling naar verwijst.
Hoeveel voegt toegankelijkheid toe aan een project?
Vanaf het begin meeontworpen heel weinig — vooral discipline rond semantiek, contrast en focustoestanden. Achteraf aangebracht op een afgeronde maatwerksite kan het een aanzienlijk project zijn, omdat de oplossingen structureel zijn en niet cosmetisch. Dat verschil is het hele argument om het in de opdracht ter sprake te brengen in plaats van na de lancering.
Wat is het verschil tussen WCAG A, AA en AAA?
Het zijn nalevingsniveaus. A is het minimum en laat echte drempels staan; AA is wat regelgeving doorgaans eist en waar de meeste organisaties op mikken; AAA bevat criteria die niet voor alle content haalbaar zijn — bijvoorbeeld een contrasteis van 7:1 die sommige merkpaletten niet halen. Mik op AA en behandel AAA als een verbetering per criterium in plaats van als doel.
Helpt toegankelijkheid de SEO?
Indirect en werkelijk. Een correcte koppenstructuur, beschrijvende linktekst, alt-attributen, echte semantiek en snelle, stabiele pagina's helpen beide. Maar de overlap is gedeeltelijk: een site kan goed scoren en met een toetsenbord onbruikbaar zijn. Doe toegankelijkheidswerk omdat mensen de site anders niet kunnen gebruiken, en neem het SEO-voordeel als bijeffect.
webtoegankelijkheidwcagtoegankelijk webdesignschermlezertoetsenbordnavigatietoegankelijkheid testen
