Wat zijn de vier principes van toegankelijkheid
Deze concrete maatregel is de eerste van vier onmisbare pijlers voor een inclusieve interface. Zonder adequaat kleurcontrast (minimaal 4,5:1 voor normale tekst, 3:1 voor grote letters) en voldoende klikdoelgrootte, faalt de bedienbaarheid voor mensen met motorische of visuele beperkingen. Implementeer dit direct in je CSS, bijvoorbeeld met @media (prefers-contrast: more) om automatisch aan te passen.
De tweede pijler richt zich op de waarneembaarheid van alle zintuiglijke informatie. Geef elke afbeelding een alt-attribuut dat de functie beschrijft, niet de verschijning. Zorg dat video's beschikken over een nauwkeurige ondertiteling (niet alleen automatische transcriptie) en bied een audiobeschrijving aan voor betekenisvolle visuele details. Gebruik voor grafieken altijd een tabel of een samenvatting in tekstvorm als alternatief.
De derde richtlijn betreft de begrijpelijkheid van de code en de navigatie. Structureer je document met correct geneste kopniveaus (één h1, meerdere h2, etc.). Zorg dat elke interactieve component toetsenbordtoegankelijk is en een duidelijke focus-indicator heeft (niet verwijderen met outline: none tenzij je een alternatief biedt). Vermijd links met tekst als "lees meer" – gebruik beschrijvende ankertekst zoals "lees de volledige analyse van contrastratio's".
De laatste pijler is robuustheid: de interface moet functioneren met verschillende hulptechnologieën. Valideer je HTML tegen de W3C-standaard en test met een screenreader zoals NVDA of VoiceOver. Gebruik ARIA-labels alleen wanneer een native HTML-element geen oplossing biedt – niet als standaard. Zet automatische tests in, zoals axe-core, in je CI/CD-pijplijn om regressies bij elke update te vangen.
Waarneembaar: hoe bied je elke zintuiglijke informatie aan in tekstalternatieven en ondertitels?
Begin met het onderscheiden van drie functies: informatie die cruciaal is voor de handeling, informatie die de sfeer bepaalt, en informatie die overbodig is. Bied voor elke afbeelding of video een beknopt maar compleet tekstalternatief dat de functie weerspiegelt. Bij een knop met een icoon van een printer volstaat 'Printen'; bij een grafiek met verkoopcijfers benoem je de trend, de uitschieters en de assen. Voor video's gebruik je ondertitels die niet alleen dialogen weergeven, maar ook geluiden met een informatielaag: 'deurbel gaat', 'harde knal', 'fluisterend'. Verwerk deze geluiden tussen haakjes of met een aparte kleurcodering, maar vermijd dat ze de leesbaarheid verstoren. Spreek bij gesproken tekst altijd uit wat er visueel gebeurt als dat de handeling beïnvloedt: 'Hij pakt de map en opent deze op pagina drie' – dit vervangt de visuele aanwijzing voor iemand die niet kan zien.
Voor live-uitzendingen en complexe media is er een extra laag: beschrijf non-verbale communicatie die de betekenis verandert. Een sarcastische opmerking zonder toon is misleidend; voeg toe: '(ironisch bedoeld)' of '(met zachte stem)'. Gebruik bij beeldmateriaal een alt-tekst van maximaal 150 tekens voor functionele elementen, maar lever een langere beschrijving via een lang beschrijvingsveld of een link als de kleur, vorm of positie van objecten essentieel is voor het begrip. Synchroniseer ondertitels met een vertraging van maximaal 100 milliseconden – dit voorkomt desynchronisatie bij lezers die liplezen. Kies voor een contrastverhouding van minimaal 4,5:1 tussen ondertiteltekst en achtergrond, en gebruik een schreefloos lettertype zoals Verdana of Calibri in minimaal 24 punten. Verdeel lange zinnen in blokken van maximaal 42 karakters per regel; dit verhoogt de leessnelheid met 30% en vermindert cognitieve belasting bij kijkers met auditieve of cognitieve beperkingen.
Bedienbaar: welke navigatiestructuur en tijdslimieten voorkom je voor toetsenbord- en spraakbediening?
Zorg dat elke interactieve component, zoals links, knoppen en invoervelden, bereikbaar is met de Tab-toets in een logische volgorde die overeenkomt met de visuele layout. Gebruik hiervoor geen positieve `tabindex`-waarden boven 0; dit verstoort de natuurlijke tabvolgorde en maakt navigatie onvoorspelbaar voor spraakgestuurde gebruikers die commando's als "volgende veld" gebruiken. Implementeer daarentegen een zichtbare focus-indicator (bijvoorbeeld een 2px brede outline met een contrastverhouding van minimaal 3:1 ten opzichte van de achtergrond) die nooit wordt verwijderd door `outline: none` zonder een alternatief.
Voor toetsenbordnavigatie binnen complexe widgets (tabbladen, menu's, boomstructuren) pas je het zogenaamde "roving tabindex"-patroon toe: slechts één element in de groep heeft `tabindex="0"`, terwijl de overige `tabindex="-1"` krijgen. Pijltjestoetsen verplaatsen de focus binnen de groep, terwijl Tab de gebruiker naar de volgende sectie brengt. Dit voorkomt dat een gebruiker tientallen keren moet tabben om door een menu met veertien items te komen. Voor spraakbediening (zoals Dragon NaturallySpeaking) betekent dit dat vocale commando's als "klik op item 3" direct werken, omdat het aantal focuspunten drastisch beperkt is.
Vermijd tijdslimieten die geen pauze, verlenging of uitschakeling bieden. Een sessie-timeout na 5 minuten inactiviteit zonder waarschuwing is ontoelaatbaar; geef minstens 20 seconden de tijd om een waarschuwing te bevestigen en sta toe dat de limiet tien keer kan worden verlengd voordat automatische uitlogging plaatsvindt. Specifiek voor formulieren: gebruik geen automatische verzending na een bepaalde tijd en zorg dat een `inactivity timeout` de ingevulde gegevens lokaal bewaart (via `localStorage`) zodat deze na herladen niet verloren gaan. Bewegende carrousels of automatisch verschuivende content moeten een pauzeknop hebben die bij voorkeur prominent rechtsboven staat en ook met de Enter-toets bedienbaar is.
- Voor spraakgestuurde navigatie is een lineaire structuur essentieel: plaats een "skip naar hoofdinhoud"-link als allereerste focusbare element, gevolgd door een duidelijke kopvolgorde (één `
`, logische `
`-secties). Spraakgebruikers geven vaak het commando "ga naar paragraaf 2" – dit werkt alleen als koppen niet meer dan één niveau overslaan en geen lege koppen bevatten.
- Stel een standaard van maximaal 15 focusbare elementen per pagina in voor producten; bij meer items (bijv. filterwidgets) gebruik je ``-elementen of collapsible secties om de initiële tabbelasting te reduceren. Uit onderzoek van de W3C blijkt dat toetsenbordgebruikers met motorische beperkingen gemiddeld 3 seconden per shift nodig hebben; een pagina met 50 elementen kost dus 150 seconden puur aan navigeren.
Pas specifieke sneltoetsen toe die niet conflicteren met browser- of screenreader-sneltoetsen: gebruik bijvoorbeeld `Alt+M` voor het openen van het hoofdmenu, maar vermijd onbewerkte lettertoetsen (zoals `M` zonder modifier) omdat die botsen met spraakopdrachten. Documenteer alle sneltoetsen in een toegankelijkheidsverklaring. Voor tijdsafhankelijke interacties (zoals een knop die je 3 seconden ingedrukt moet houden) bied je een alternatief in de vorm van een gewone klikbare knop; spraakgebruikers kunnen namelijk geen langdurige druk simuleren.
Test elke wijziging met drie methoden: (1) alleen toetsenbord met visuele focus, (2) spraakherkenning met numerieke markeringen (F11-toets in Dragon), en (3) een screenreader in browsermodus. Controleer specifiek dat een spraakcommando als "klik op link" niet meerdere elementen selecteert vanwege ontbrekende toegankelijke namen; elk focusbaar element moet een unieke, programmatisch bepaalde naam hebben (via `aria-label` of zichtbare tekst). Veranker deze test in je definitie of done-criteria – anders ontstaat er gegarandeerd een structuur die wel geldig is volgens HTML, maar onbedienbaar in de praktijk.
Veelgestelde vragen:
Ik ben bezig met het toegankelijk maken van onze gemeentelijke website. De WCAG-richtlijnen zijn duidelijk, maar ik vraag me af: zijn die vier principes (waarneembaar, bedienbaar, begrijpelijk en robuust) nou echt een hiërarchie, of moet ik ze allemaal tegelijkertijd even zwaar wegen? Als ik bijvoorbeeld een video toevoeg, moet ik dan eerst alle alternatieve tekstvormen af hebben voordat ik de video zelf af kan ronden?
De vier principes zijn geen hiërarchie, maar vormen een gelaagd systeem. Ze bouwen op elkaar voort: als iets niet waarneembaar is (bijvoorbeeld een afbeelding zonder alt-tekst voor een blinde gebruiker), kun je het ook niet bedienen of begrijpen. Maar dat betekent niet dat je ze strikt sequentieel moet afwerken in een project. In de praktijk werk je er vaak parallel aan. Neem jouw videovoorbeeld: terwijl je de video monteert, kun je alvast een transcript maken (waarneembaarheid). Tegelijkertijd test je of de bedienknoppen met het toetsenbord te gebruiken zijn (bedienbaar). En je checkt of de interface-teksten begrijpelijk zijn voor je doelgroep. De principes zijn meer een denkkader om te controleren of je niets over het hoofd ziet, dan een stappenplan. Je kunt ze zien als vier vragen die je over elk onderdeel van je product stelt, niet als vier fasen die je in vaste volgorde doorloopt. Een veelgemaakte fout is dat teams eerst "alles waarneembaar" proberen te maken, en dan pas over bedienbaarheid nadenken. Daardoor ontdekken ze te laat dat een toegankelijk ontworpen formulier (waarneembaar) totaal onbruikbaar is met een screenreader (bedienbaar) omdat de focusvolgorde niet klopt. Doe het dus liever iteratief: werk in korte cycli en laat elk principe meelopen in elke sprint.
Wij hebben een webshop en onze ontwikkelaar zegt dat 'robust' (het vierde principe) alleen gaat over geldig gebruik van HTML en dat we daarmee klaar zijn als de site valide is. Ik krijg het gevoel dat dat te simpel is. Wat bedoelen ze eigenlijk precies met 'roboust' in de praktijk, buiten die technische validatie om?
Je ontwikkelaar heeft gelijk dat valide code een onderdeel is van 'roboust', maar het is slechts het begin. Het vierde principe gaat erover dat je inhoud en functies betrouwbaar blijven werken met allerlei hulptechnologieën, ook die van de toekomst. Concreet betekent dit: gebruik de juiste en volledige semantiek. Een knop die is opgebouwd uit een `
Mijn collega zegt dat 'begrijpelijk' (het derde principe) vooral gaat over duidelijke taal, dus dat we teksten op B1-niveau moeten schrijven. Maar is er niet veel meer wat onder dit principe valt? We hebben bijvoorbeeld ook een zoekfunctie op onze intranetpagina. Telt die ook mee?
Jazeker, begrijpelijkheid gaat veel breder dan alleen leesbaarheid van tekst. Het principe omvat drie onderdelen: leesbaarheid (klare taal, maar ook het aangeven van de taal van de pagina in de code, zodat een screenreader de juiste uitspraakregels gebruikt), voorspelbaarheid (de werking van de interface moet logisch en consistent zijn), en invoerhulp (het voorkómen en corrigeren van fouten). Jouw zoekfunctie valt onder voorspelbaarheid en invoerhulp. Voorbeeld: als een gebruiker een verkeerde zoekterm intoetst, moet je niet alleen een foutmelding tonen in rood, maar ook uitleggen in tekst wat er misging en hoe je het oplost. Verder betekent voorspelbaarheid dat navigatiepatronen op elke pagina hetzelfde werken, dat labels bij formulieren altijd op dezelfde plaats staan, en dat links niet veranderen van gedrag. Een typische valkuil: een knop die op de ene pagina een formulier verstuurt, en op de andere pagina een nieuw venster opent, zonder dat de gebruiker dat van tevoren weet. Dat is een schending van voorspelbaarheid. En invoerhulp betreft ook zaken als: foutmeldingen koppelen aan het specifieke veld, een overzicht tonen van alle fouten, en bevestiging vragen voordat een actie definitief wordt doorgevoerd. Dus nee, het is niet alleen B1-taal; het is een complete gebruikerservaring die voorspelbaar en fouttolerant is.
In onze organisatie werken we met veel PDF-documenten. Ik snap dat die onder 'waarneembaar' kunnen vallen omdat je ze moet kunnen zien, maar ik hoor mensen soms zeggen dat een gescande PDF na OCR-verwerking al toegankelijk is. Moet ik daar meer van weten? Wat is het verschil tussen een gescande PDF met OCR en een écht toegankelijke PDF?
Dat is een hardnekkig misverstand. Een gescande PDF die door OCR is gehaald, is inderdaad een stuk beter dan een pure afbeelding, maar je bent er nog lang niet. OCR geeft je een tekstlaag, waardoor je de tekst kunt selecteren, doorzoeken en laten voorlezen. Maar 'waarneembaar' gaat veel verder: het betekent dat alle informatie die visueel wordt overgebracht, ook beschikbaar is in een andere vorm. Concreet voor PDF's: een toegankelijke PDF heeft een duidelijke leesvolgorde in de tagstructuur (hoe een screenreader door headers, paragrafen, tabellen en lijsten navigeert), alternatieve tekst voor afbeeldingen, correcte tabellen met header-cellen, reële koppen en lijsten in plaats van handmatige opmaak, en een correcte taalinstelling. OCR levert alleen een platte tekstlaag op, zonder structuur. Een voorbeeld: stel je hebt een formulier in PDF. Na OCR kun je de tekst lezen, maar de formuliervelden zijn niet herkend als invoervelden. Een screenreader doorloopt ze dan niet automatisch, en de gebruiker kan ze niet invullen zonder muis. Ook tabellen worden als lopende tekst voorgelezen, waardoor de relatie tussen kolom- en rijkoppen compleet verloren gaat. De enige betrouwbare manier om een PDF toegankelijk te maken is door het bronbestand (bijv. Word of InDesign) correct op te bouwen met de juiste stijlen, en daarna pas te exporteren naar een taggde PDF. Als je alleen scans hebt, overweeg dan om de documenten opnieuw te produceren als HTML-pagina's, die zijn eenvoudiger toegankelijk te maken en beheer je makkelijker.
