Hoe train je je team in toegankelijkheid?

Geplaatst op door

WCAG praktisch toepassen — Formulieren, focus en ARIA | WCAGTool

In de praktijk falen veel implementaties op WCAG door kleine maar cruciale fouten: ontbrekende labels, onjuiste focusmanagement, foutieve ARIA-toepassingen en content die alleen visueel begrijpelijk is. Dit artikel richt zich op concrete, testbare oplossingen die developers en designers direct kunnen toepassen.

Wij vertalen WCAG-richtlijnen naar kant-en-klare code, checklists en teststappen zodat jouw site of applicatie snel voldoet. Test direct met onze WCAG checker, download onze plugin of neem contact op via het contactformulier — wij reageren binnen 24 uur: https://wcagtool.nl/checker, https://wcagtool.nl/plugin, https://wcagtool.nl/contact.

Het probleem in de praktijk

1) Ontbrekende of foutieve labels

Veel formulieren missen expliciete <label>-elementen of gebruiken visuele placeholders als enige indicatie. Screenreaders hebben expliciete associaties nodig.

2) Focus en keyboardtoegankelijkheid

Interactie-elementen zijn niet via toetsenbord bereikbaar of focusstijlen zijn verwijderd. Dit breekt keyboard-navigatie en zichtbaarheid van focus.

3) Onjuist gebruik van ARIA

Ontwikkelaars gebruiken aria-attributes als vervanging voor semantische HTML (bijv. role=”button” zonder tabindex of gedragingen), wat verwarring veroorzaakt voor hulptechnologieën.

4) Dynamische content zonder live-regions of focus-management

Modalen, foutmeldingen en updates worden niet gecommuniceerd naar screenreaders of krijgen geen focus, waardoor gebruikers belangrijke informatie missen.

Zo los je dit op in code

Formulieren: correcte labels, errors en associaties

<form id="contact"><div><label for="name">Naam</label><input id="name" name="name" type="text" required aria-required="true" /></div><div><label for="email">E-mail</label><input id="email" name="email" type="email" required aria-required="true" /></div><div id="form-error" role="alert" aria-live="assertive" class="visually-hidden">Er zijn fouten in het formulier.</div><button type="submit">Verstuur</button></form>

Tips: gebruik altijd for op labels, aria-required alleen als extra semantiek en een role="alert" of aria-live voor foutmeldingen.

Keyboard en focus management: skip link en zichtbare focus

<a class="skip-link" href="#main">Sla navigatie over</a><!-- CSS -->.skip-link{position:absolute;left:-999px;top:auto;width:1px;height:1px;overflow:hidden}.skip-link:focus{position:static;left:0;width:auto;height:auto;background:#000;color:#fff;padding:.5rem;border-radius:3px}
<!-- Zorg voor zichtbare focus op interactie-elementen -->button, a, input{outline:3px solid #005fcc;outline-offset:2px}button:focus{box-shadow:0 0 0 3px rgba(0,95,204,.2)}

Zorg dat elk interactief element via Tab bereikbaar is (geen tabindex=”-1″ tenzij tijdelijk) en dat focus zichtbaar is in de UI.

Correcte ARIA: gebruik het als aanvulling, niet als vervanging

<!-- Gebruik semantische HTML waar mogelijk --><button id="save">Opslaan</button><!-- Als je ARIA nodig hebt --><div role="status" aria-live="polite">Wijzigingen opgeslagen</div>

Vervang geen <button> door <div role=”button”> tenzij je ook keyboard- en enter/space-gedrag implementeert en tabindex toevoegt.

Modalen en dynamische content: focus trap en terugzetten

<!-- eenvoudige focus trap (vanuit modal open functie) -->const firstFocusable = modal.querySelector('button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])');const focusable = modal.querySelectorAll('button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])');let lastFocusable = focusable[focusable.length-1];firstFocusable.focus();modal.addEventListener('keydown', e => {if(e.key==='Tab'){if(e.shiftKey && document.activeElement===firstFocusable){e.preventDefault();lastFocusable.focus()}else if(!e.shiftKey && document.activeElement===lastFocusable){e.preventDefault();firstFocusable.focus()}}});

Zet focus terug naar de trigger na sluiten en markeer de rest van de pagina met aria-hidden="true" indien nodig.

Checklist voor developers

  • Alle form controls hebben een gekoppeld <label> of aria-label/aria-labelledby.
  • Tab-volgorde volgt visuele volgorde; vermijd onnodige tabindex-waarden.
  • Interactieve elementen gebruiken semantische HTML (button, a, input) of volledige ARIA-implementatie.
  • Contrast ≥ 4.5:1 voor tekst (controleer met onze WCAG checker).
  • Foutmeldingen zijn bereikbaar en worden aangekondigd via role=”alert” of aria-live.
  • Modalen hebben focus trap en focusterugzetting; dynamische updates gebruiken aria-live.
  • Afbeeldingen hebben bruikbare alt-tekst; decoratieve afbeeldingen krijgen alt=””.
  • Multimedia heeft ondertiteling en transcript waar relevant.

Tips voor designers en redacties

Designsystemen en componentbibliotheken

Implementeer toegankelijkheidsregels in je component library: voorzie components van props voor aria-attributes, focusstyles en keyboard-gedrag. Documenteer voorbeelden met code en testcases.

Contentrichtlijnen voor redacties

  • Gebruik duidelijke kopstructuur (H1 → H2 → H3). Screenreaders gebruiken dit voor navigatie.
  • Vermijd betekenisloze linkteksten als “klik hier”. Geef context: “Bekijk onze toegankelijkheidscheck”.
  • Schrijf korte, heldere alt-teksten; complex beeldmateriaal met rol legt uit in omliggende tekst of een lange beschrijving.

Contrast en kleurgebruik

Sla alle kleurstalen op in een tokens-lijst met contrastwaarden en voorbeelden. Zorg voor voldoende contrast voor tekst en interface-elementen, niet alleen voor primaire kleuren.

Hoe test je dit?

Automatisch testen

Gebruik onze WCAG checker voor snelle automatisering: https://wcagtool.nl/checker. Integreer onze plugin in CI/CD voor regressietests: https://wcagtool.nl/plugin.

Handmatige tests — stap-voor-stap

  1. Keyboard-only: zet je muis weg en navigeer met Tab, Shift+Tab, Enter en Space. Volg checklist en verifieer focusvolgorde.
  2. Screenreader: test met NVDA (Windows) of VoiceOver (macOS/iOS). Lees formulieren en modalen voor.
  3. Contrast: controleer kleuren met de kleurenchecker in onze validator en test in verschillende schermgroottes.
  4. Dynamische updates: simuleer fouten, successen en dynamische content en controleer aria-live/role aankondigingen.

Testcases en voorbeelden

TEST 1: Formulier validatie - verwijder label van input, voer validator uit, check of role="alert" aanwezig is TEST 2: Modal - open modal, Tab tot de laatste focus, druk Tab en verifieer dat focus terugkeert naar eerste focus TEST 3: Keyboard - navigeer naar alle knoppen en links; geen element mag niet bereikbaar zijn

Loop deze tests periodiek uit. Gebruik onze checker voor snelle scans en de plugin voor CI-integratie: https://wcagtool.nl/checker, https://wcagtool.nl/plugin. Vragen? Gebruik het contactformulier — antwoord binnen 24 uur: https://wcagtool.nl/contact.

Laatste praktische tip

Implementatie-check: plak deze kleine audit-snippet in je console om snel niet-klikbare interactieve elementen te vinden:

Array.from(document.querySelectorAll('[role="button"], [role="link"], [tabindex]')).filter(el => {const tag = el.tagName.toLowerCase();return !(tag==='button' || tag==='a' || tag==='input' || tag==='select' || tag==='textarea') && !el.hasAttribute('onclick')}).slice(0,20)

Plak de output naar je tickettool, fix de elementen en test opnieuw met onze WCAG checker. Wil je hulp bij implementatie of een review? Start een scan op https://wcagtool.nl/checker, download onze plugin op https://wcagtool.nl/plugin of stuur een vraag via https://wcagtool.nl/contact — wij reageren binnen 24 uur.