QualiBooth
Nederlands

guides

Toegankelijkheidsproblemen om te vermijden

Leer de meest voorkomende fouten in webtoegankelijkheid die gebruikers met een beperking blokkeren en hoe u ze oplost vóór ze juridische risico's worden.

12 min read QualiBooth
Een checklist met veelvoorkomende toegankelijkheidsproblemen om te vermijden, waaronder contrast, alt-tekst en toetsenbordnavigatie.

Waarom dezelfde toegankelijkheidsproblemen steeds terugkomen

De meeste toegankelijkheidsbarrières zijn niet exotisch. Jaar na jaar leggen geautomatiseerde en handmatige audits dezelfde korte lijst met fouten bloot: ontbrekende alt-tekst, laag contrast, niet-gelabelde formuliervelden, toetsenbordvallen en kapotte structuur. Ze komen terug omdat ze stilletjes worden geïntroduceerd — een ontwikkelaar lanceert een nieuwe component, een marketeer uploadt een afbeelding, een ontwerper kiest een merkkleur — en niets in de normale workflow signaleert het probleem. Het visuele resultaat ziet er prima uit voor iemand met een muis en een scherp paar ogen, dus de barrière gaat live.

Deze catalogus loopt door de meest voorkomende WCAG 2.2-fouten die we in echte audits zien. Voor elk daarvan vindt u waarom het belangrijk is, wie het treft, het relevante succescriterium en een concrete voor/na-oplossing. Samen vormen deze problemen de overgrote meerderheid van de barrières die gebruikers met een beperking blokkeren — en de overgrote meerderheid van de juridische klachten die worden ingediend onder de European Accessibility Act, de ADA en Section 508.

Eén ding moet eerst duidelijk zijn voordat we aan de lijst beginnen: geautomatiseerde tools kunnen niet al deze problemen vinden. Onafhankelijk onderzoek toont consequent aan dat zelfs de beste scanners betrouwbaar slechts 30–40% van de WCAG-problemen detecteren. Ze zijn uitstekend in het opsporen van ontbrekende alt-attributen, programmatische contrastfouten en afwezige formulierlabels, maar ze kunnen niet beoordelen of alt-tekst accuraat is, of de focusvolgorde logisch is, of dat een aangepaste widget daadwerkelijk werkt met een schermlezer. Daarom combineert elk geloofwaardig programma scannen met handmatige beoordeling. Onze software voor toegankelijkheidsscans verzorgt de automatiseerbare laag; handmatige audits en audits uitgevoerd door mensen met een beperking dekken de rest.

Een snelle manier om uw eigen startpunt te vinden voordat u verder leest: bekijk de pagina met afbeeldingen uitgeschakeld, lees elk woord als één ongestructureerde alinea en probeer elke taak uit te voeren met alleen een toetsenbord. Overal waar de ervaring instort, hebt u een barrière gevonden.

Waarneembaar: inhoud die mensen niet kunnen zien of lezen

Ontbrekende of onjuiste alt-tekst voor afbeeldingen

Wie het treft: mensen die blind zijn of slechtziend en een schermlezer gebruiken; iedereen met een trage verbinding waar afbeeldingen niet laden.

WCAG-criterium: 1.1.1 Niet-tekstuele content (niveau A).

Afbeeldingen zonder een alt-attribuut zijn onzichtbaar voor hulptechnologie — de gebruiker weet mogelijk niet eens dat de afbeelding bestaat. Erger dan een ontbrekend attribuut is een onjuist attribuut: bestandsnamen zoals IMG_4821.jpg, algemene woorden zoals “afbeelding” of met zoekwoorden volgepropte tekenreeksen misleiden de luisteraar actief.

De regel is eenvoudig maar situationeel. Informatieve afbeeldingen hebben een beknopte beschrijving van hun betekenis nodig, niet van hun uiterlijk. Decoratieve afbeeldingen die niets toevoegen moeten een leeg alt="" hebben zodat schermlezers ze overslaan. Functionele afbeeldingen — een icoon dat als knop fungeert — moeten de actie beschrijven, niet de afbeelding. Complexe visuals zoals grafieken hebben een korte alt plus een langer tekstequivalent in de buurt nodig.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

Geautomatiseerde tools detecteren de afwezigheid van alt-tekst direct. Ze kunnen u niet vertellen of de tekst correct is — daarvoor is een mens nodig die de pagina in context leest.

Onvoldoende kleurcontrast

Wie het treft: mensen met slechtziendheid, kleurenblindheid of leeftijdsgebonden gezichtsverlies; iedereen die een scherm in fel zonlicht gebruikt.

WCAG-criterium: 1.4.3 Contrast (minimum), niveau AA; plus 1.4.11 Contrast van niet-tekstuele content voor UI-componenten.

WCAG 2.2 vereist een contrastverhouding van ten minste 4.5:1 voor normale tekst en 3:1 voor grote tekst (ongeveer 18pt, of 14pt vet). Interface-componenten en betekenisvolle afbeeldingen — invoerranden, focusindicatoren, iconen die een toestand overbrengen — moeten 3:1 ten opzichte van hun omgeving halen. Contrastfouten behoren tot de meest voorkomende problemen in elke grootschalige audit, en worden vrijwel altijd in de ontwerpfase geïntroduceerd.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Test het volledige palet, niet alleen de bodytekst: tijdelijke aanduidingen (placeholder), uitgeschakelde toestanden die toch leesbaar moeten zijn, foutmeldingen en tekst over foto’s zijn veelvoorkomende overtreders. Vertrouw nooit alleen op kleur om betekenis over te brengen (1.4.1) — een rode rand op een ongeldig veld moet gecombineerd worden met tekst of een icoon.

Automatisch afspelende media en beweging

Wie het treft: mensen met vestibulaire stoornissen, aandachts- of cognitieve beperkingen, schermlezergebruikers wiens audio-uitvoer wordt overstemd, en iedereen in een rustige gedeelde ruimte.

WCAG-criteria: 1.4.2 Audiobediening (niveau A), 2.2.2 Pauzeren, stoppen, verbergen (niveau A), 2.3.1 Drie flitsen (niveau A) en 2.3.3 Animatie door interacties (niveau AAA).

Audio of video die langer dan drie seconden automatisch afspeelt, moet een duidelijke manier bieden om te pauzeren of te dempen. Bewegende, knipperende of automatisch bijwerkende inhoud die langer dan vijf seconden duurt — carrousels, geanimeerde banners, marquees — heeft een toegankelijke pauzeknop nodig. Inhoud die meer dan drie keer per seconde flitst kan epileptische aanvallen veroorzaken en moet volledig worden vermeden. Respecteer de prefers-reduced-motion-instelling van de gebruiker om niet-essentiële animatie te temperen.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Bedienbaar: dingen die mensen niet kunnen gebruiken

Toetsenbordontoegankelijkheid en toetsenbordvallen

Wie het treft: mensen met motorische beperkingen die geen muis kunnen gebruiken, schermlezergebruikers (die met het toetsenbord navigeren) en mensen die schakelaars of spraakbesturing gebruiken.

WCAG-criteria: 2.1.1 Toetsenbord (niveau A) en 2.1.2 Geen toetsenbordval (niveau A).

Elke interactie — links, knoppen, formuliervelden, menu’s, modals, datumkiezers, slepen-en-neerzetten — moet volledig bedienbaar zijn met alleen het toetsenbord. De meest schadelijke variant is de toetsenbordval: de focus komt in een component terecht (vaak een modal of een ingesloten widget) en kan er niet meer uit, waardoor de gebruiker op de pagina vastzit. Op maat gebouwde widgets zijn meestal de boosdoener omdat native elementen zoals <button> en <a> standaard met het toetsenbord bedienbaar zijn, terwijl op <div> gebaseerde imitaties dat niet zijn.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Loop uw belangrijkste trajecten door met alleen Tab, Shift+Tab, pijltjestoetsen, Enter, Spatie en Escape. Bevestig dat de focus altijd vooruit en terug uit elke component kan, dat Escape overlays sluit en dat niets een aanwijsapparaat vereist. Onze dienst voor schermlezerevaluatie test precies deze flows zoals echte gebruikers van hulptechnologie ze ervaren.

Ontbrekende of onzichtbare focusindicatoren en onlogische focusvolgorde

Wie het treft: ziende toetsenbordgebruikers, slechtziende gebruikers en iedereen die het overzicht is kwijtgeraakt van waar ze zich op de pagina bevinden.

WCAG-criteria: 2.4.7 Focus zichtbaar (niveau A) en 2.4.3 Focusvolgorde (niveau A); 2.4.11 Focus niet verborgen (niveau AA) in WCAG 2.2.

Een veelvoorkomende “nette” fout is het verwijderen van de standaard focusring van de browser met outline: none en deze nooit vervangen. Toetsenbordgebruikers hebben dan geen idee welk element actief is. Net zo schadelijk is een focusvolgorde die niet de visuele en logische leesvolgorde volgt — meestal veroorzaakt door positieve tabindex-waarden of door een DOM-volgorde die afwijkt van de weergegeven lay-out.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 voegt 2.4.11 toe: wanneer een element focus krijgt, mag het niet volledig verborgen zijn achter plakkerige headers, cookiebanners of chatwidgets. Open een modal, tab er doorheen en bevestig dat het gefocuste element nooit verstopt zit.

Wie het treft: schermlezergebruikers die een lijst van alle links oproepen om een pagina te scannen, en mensen met cognitieve beperkingen.

WCAG-criteria: 2.4.4 Linkdoel (in context), niveau A; 2.5.3 Label in naam, niveau A.

Schermlezergebruikers navigeren vaak door tussen links te springen buiten hun context. Een pagina vol “klik hier”-, “lees meer”- en “meer informatie”-links wordt betekenisloos wanneer deze als lijst wordt voorgelezen. Linktekst moet op zichzelf de bestemming beschrijven. Hetzelfde geldt voor knoppen met alleen een icoon, die een toegankelijke naam nodig hebben.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Overladen navigatie en geen manier om die over te slaan

Wie het treft: schermlezergebruikers, toetsenbordgebruikers en mensen met cognitieve beperkingen.

WCAG-criterium: 2.4.1 Blokken omzeilen (niveau A).

Een megamenu met tientallen links dwingt schermlezer- en toetsenbordgebruikers om op elke pagina door de hele lijst te ploeteren voordat ze de inhoud bereiken. Een “Spring naar hoofdinhoud”-link als eerste focusbare element laat ze direct voorbij herhaalde blokken springen. Groepeer gerelateerde items, houd menu’s slank en zorg ervoor dat de skiplink zichtbaar wordt bij focus.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Begrijpelijk: inhoud die verwarrend is

Niet-gelabelde of onjuist gekoppelde formuliervelden

Wie het treft: schermlezergebruikers, mensen met cognitieve beperkingen en spraakbesturingsgebruikers die velden bij naam aanspreken.

WCAG-criteria: 1.3.1 Info en relaties, 3.3.2 Labels of instructies en 4.1.2 Naam, rol, waarde (allemaal niveau A).

Invoervelden zonder een programmatisch gekoppeld <label> worden aangekondigd als “tekst bewerken, leeg” — de gebruiker heeft geen idee wat hij moet typen. Tijdelijke aanduidingen (placeholder) zijn geen vervanging: ze verdwijnen bij invoer en falen meestal op contrast. Verplichte velden, opmaakregels en validatiefouten moeten ook in tekst worden overgebracht, niet alleen door kleur of positie.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Koppel foutmeldingen aan hun veld met aria-describedby, markeer ongeldige velden met aria-invalid en zorg ervoor dat het verzenden van een onvolledig formulier de focus naar de eerste fout verplaatst.

Ontbrekende paginataal

Wie het treft: schermlezergebruikers — de verkeerde taal zorgt ervoor dat de synthesizer alles verkeerd uitspreekt.

WCAG-criteria: 3.1.1 Taal van de pagina (niveau A) en 3.1.2 Taal van onderdelen (niveau AA).

Eén ontbrekend attribuut verstoort de uitspraak voor een hele pagina. Declareer de primaire taal op het root-element en markeer inline passages in een andere taal met hun eigen lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Onjuiste koppenhiërarchie en ontbrekende landmarks

Wie het treft: schermlezergebruikers die navigeren op koppen en regio’s, en iedereen die op de documentstructuur vertrouwt.

WCAG-criterium: 1.3.1 Info en relaties (niveau A).

Koppen vormen het overzicht van de pagina. Schermlezergebruikers springen van kop naar kop om snel inhoud te vinden; wanneer niveaus worden overgeslagen, puur voor lettergrootte worden gebruikt of ontbreken, stort die navigatie in. Elke pagina moet één <h1> hebben en een logische, ononderbroken reeks van <h2>, <h3> enzovoort. Even belangrijk zijn landmark-regio’s — <header>, <nav>, <main>, <footer> — waarmee gebruikers tussen de belangrijkste gebieden kunnen springen. Een pagina die volledig uit <div>-elementen bestaat, biedt geen dergelijke kaart.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Robuust: code die hulptechnologie niet kan interpreteren

Ontoegankelijke aangepaste widgets en misbruik van ARIA

Wie het treft: schermlezergebruikers bovenal, en elke hulptechnologie die afhankelijk is van een correcte toegankelijkheidsboom.

WCAG-criterium: 4.1.2 Naam, rol, waarde (niveau A).

Aangepaste dropdowns, tabs, accordeons, comboboxen, modals en tooltips gebouwd uit <div> en <span> hebben geen inherente rol, toestand of toetsenbordgedrag. Ontwikkelaars grijpen naar ARIA om dit op te lappen, maar ARIA beschrijft alleen — het voegt geen gedrag toe, en onjuiste ARIA is erger dan geen ARIA. De eerste regel van ARIA is om de voorkeur te geven aan een native HTML-element wanneer dat bestaat. Wanneer u een aangepaste widget moet bouwen, implementeer dan de volledige toetsenbordinteractie die de ARIA-authoringpatronen voorschrijven en houd aria-expanded, aria-selected en soortgelijke toestanden in lijn met de werkelijkheid.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

Dit zijn precies de problemen die geautomatiseerde scanners het vaakst missen. Een scanner ziet een aria-expanded-attribuut en keurt het goed; alleen een mens (of een tester die een schermlezer gebruikt) kan bevestigen dat de waarde daadwerkelijk omslaat wanneer het menu opent. Zie onze gids voor schermlezertests voor hoe u het gedrag van widgets van begin tot eind verifieert.

Een opmerking over overlay-widgets

Het is verleidelijk om een “toegankelijkheidswidget” of overlay van één regel te installeren die directe compliance belooft. Deze tools lossen de bovenstaande problemen niet op — de alt-tekst ontbreekt nog steeds in de bron, het contrast faalt nog steeds, de aangepaste widget werkt nog steeds niet. Overlays kunnen de code die barrières veroorzaakt niet herstellen, ze verstoren vaak de eigen hulptechnologie van gebruikers en ze hebben een rol gespeeld in een groeiend aantal toegankelijkheidsrechtszaken. Echte digitale toegankelijkheid komt voort uit het repareren van de onderliggende HTML, CSS en het gedrag, niet uit het maskeren ervan.

Voorkom dat deze problemen terugkomen

Een lijst met bugs één keer oplossen is noodzakelijk maar niet voldoende; dezelfde problemen duiken weer op bij de volgende release, tenzij u verandert hoe dingen worden gelanceerd. De duurzame oplossing is om toegankelijkheid in de workflow in te bouwen:

Voor een stapsgewijze stappenplan voor herstel begint u met onze gids over hoe u uw website WCAG-conform maakt.

Waar u vandaag kunt beginnen

Met wereldwijd meer dan 1,3 miljard mensen die met een vorm van beperking leven, is de zakelijke argumentatie voor toegankelijkheid duidelijk — en sinds juni 2025 geldt dat ook voor de juridische argumentatie onder de European Accessibility Act. De problemen in deze catalogus zijn degene die als eerste worden onderzocht in elke klacht of audit.

De snelste manier om te zien waar u staat, is door een gratis URL-scan uit te voeren — geen installatie, geen verplichting. Wanneer u klaar bent om verder te gaan dan wat automatisering kan bereiken, vraag een demo aan en laten we u zien hoe een gecombineerd geautomatiseerd-plus-handmatig programma de resterende kloof dicht.

Vind de problemen die geautomatiseerde tools missen

Praat met een expert Gratis toegankelijkheidsscan