Toegankelijkheidsrapport

Wat controleert deze regel?

Het accesskey attribuut laat toe dat een gebruiker via een sneltoets direct naar een bepaald element springt. Als meerdere elementen dezelfde accesskey hebben werkt de sneltoets niet voorspelbaar.

Waarom is dit belangrijk?

Toetsenbord-gebruikers en schermlezer-gebruikers die op sneltoetsen vertrouwen raken in de war wanneer dezelfde toets naar verschillende plekken leidt. Bovendien kunnen accesskeys conflicteren met bestaande browser- of assistive-technology sneltoetsen.

Hoe los je dit op?

Gebruik accesskey zo min mogelijk. Als je ze toepast, zorg dat elke waarde binnen de pagina uniek is. Beter nog: vervang accesskeys door goede skip-links en logische tab-volgorde, want accesskey-gedrag is onvoorspelbaar op verschillende besturingssystemen en browsers.

Code voorbeeld

<a accesskey="h" href="/home">Home</a>
<a accesskey="h" href="/help">Help</a>

<a accesskey="h" href="/home">Home</a>
<a accesskey="p" href="/help">Help</a>

Hoe controleer je dit?

Doe een DOM-zoekopdracht op alle accesskey attributen en controleer op duplicaten. Herhaal daarna de toegankelijkheidstest.

Wat controleert deze regel?

Tabindex bepaalt in welke volgorde elementen focus krijgen bij tabben. Een positieve tabindex (1, 2, 3...) dwingt een custom volgorde af die afwijkt van de natuurlijke DOM-volgorde.

Waarom is dit belangrijk?

Een tabindex-waarde hoger dan 0 breekt de intuïtieve tab-volgorde. Schermlezer- en toetsenbord-gebruikers verwachten dat ze van boven naar beneden door de pagina tabben. Positieve waarden dwingen uitzonderingen af die bij elke paginawijziging opnieuw gehandhaafd moeten worden.

Hoe los je dit op?

Gebruik uitsluitend tabindex="0" (element wordt focusbaar op natuurlijke positie) of tabindex="-1" (element focusbaar via JavaScript, niet via tab). Verwijder alle positieve waarden en herorden de DOM als de volgorde niet klopt.

Code voorbeeld

<input tabindex="3" name="voornaam">
<input tabindex="1" name="email">
<input tabindex="2" name="bericht">

<input name="voornaam">
<input name="email">
<input name="bericht">

Hoe controleer je dit?

Doorloop de pagina met alleen de Tab-toets en controleer of de volgorde logisch aansluit bij de visuele layout.

Wat controleert deze regel?

Elementen met role="dialog" of role="alertdialog" (modals, popups) moeten een naam hebben zodat de schermlezer deze aankondigt bij het openen.

Waarom is dit belangrijk?

Zonder naam weet een gebruiker met een schermlezer niet waarover de dialog gaat. Een anoniem "dialog opened" is geen bruikbare aankondiging.

Hoe los je dit op?

Geef de dialog een aria-label (korte tekst) of aria-labelledby (verwijzing naar een bestaand heading element binnen de dialog).

Code voorbeeld

<div role="dialog">
  <p>Weet je zeker dat je wilt verwijderen?</p>
  <button>Ja</button>
  <button>Nee</button>
</div>

<div role="dialog" aria-labelledby="dlg-title">
  <h2 id="dlg-title">Verwijderen bevestigen</h2>
  <p>Weet je zeker dat je wilt verwijderen?</p>
  <button>Ja</button>
  <button>Nee</button>
</div>

Hoe controleer je dit?

Open de dialog met een schermlezer en luister of de titel wordt voorgelezen bij het openen.

Wat controleert deze regel?

Items binnen een tree widget (hiërarchische boomstructuur, zoals een file explorer) moeten een duidelijke naam hebben.

Waarom is dit belangrijk?

Schermlezers navigeren door de boom en moeten elk item kunnen identificeren. Zonder naam hoort de gebruiker alleen "treeitem" zonder context.

Hoe los je dit op?

Zorg dat elk element met role="treeitem" tekstinhoud heeft, of gebruik aria-label of aria-labelledby.

Code voorbeeld

<ul role="tree">
  <li role="treeitem" aria-expanded="true">Documenten
    <ul role="group">
      <li role="treeitem">2024.pdf</li>
    </ul>
  </li>
</ul>

Hoe controleer je dit?

Navigeer met pijltjestoetsen door de boomstructuur en controleer of elk item voorgelezen wordt.

Wat controleert deze regel?

role="text" wordt gebruikt om schermlezers te vertellen dat een samengesteld element als één tekstblok moet worden voorgelezen. Focusbare elementen binnen zo'n blok creëren een conflict.

Waarom is dit belangrijk?

Wanneer een link of knop binnen een role=text staat wordt die wel focusbaar maar niet als interactief element aangekondigd. De gebruiker kan er op tabben zonder te weten wat het is.

Hoe los je dit op?

Verwijder focusbare elementen uit blokken met role="text" of haal de role weg. Gebruik role="text" alleen op statische content zonder interactie.

Hoe controleer je dit?

Tab door de content: als focus landt op een element binnen role=text, is er een probleem.

Wat controleert deze regel?

Ieder formulierveld hoort een visueel zichtbaar label te hebben. Placeholders of aria-labels alleen zijn niet voldoende.

Waarom is dit belangrijk?

Zichtbare labels helpen alle gebruikers: mensen met cognitieve beperkingen herkennen het veld als ze typen, mensen met dyscalculie of geheugenproblemen hoeven niet te onthouden wat een placeholder zei nadat ze begonnen te typen, en het helpt browser-autofill correct te functioneren.

Hoe los je dit op?

Plaats een <label> element zichtbaar bij elk formulierveld. Placeholder-tekst is een aanvulling, geen vervanging.

Code voorbeeld

<input type="email" placeholder="E-mailadres">

<label for="email">E-mailadres</label>
<input type="email" id="email" placeholder="jij@voorbeeld.nl">

Hoe controleer je dit?

Controleer op elke pagina met formulieren of bij ieder invulveld een zichtbaar tekstlabel staat.

Wat controleert deze regel?

Als een pagina <iframe> of <frame> bevat, moet de toegankelijkheidscontrole ook binnen die frames worden uitgevoerd. Anders blijft de inhoud van de frame ongecontroleerd.

Waarom is dit belangrijk?

Iframes bevatten vaak externe content (embeds, formulieren, video's) die ook toegankelijk moet zijn. Zonder test in de iframe kunnen grote problemen onopgemerkt blijven.

Hoe los je dit op?

Zorg dat de toegankelijkheidscontrole ook binnen iframes wordt uitgevoerd. Voor productie: controleer dat externe embeds (YouTube, Google Maps, formulieren van derden) zelf toegankelijk zijn.

Hoe controleer je dit?

Voor externe iframes: test de ingebedde URL apart. Voor eigen iframes: zorg dat een toegankelijkheidschecker ook binnen de frame draait.

Wat controleert deze regel?

Het scope attribuut op <th> elementen geeft aan of de header voor een rij (scope="row") of kolom (scope="col") geldt. Andere waarden zijn colgroup of rowgroup.

Waarom is dit belangrijk?

Schermlezers gebruiken scope om bij het voorlezen van een cel te weten welke header erbij hoort. Verkeerde of ontbrekende scope maakt grote tabellen onbegrijpelijk.

Hoe los je dit op?

Gebruik alleen de waarden row, col, rowgroup of colgroup op <th>. Typische fout is scope op een <td> plaatsen, dat werkt niet.

Code voorbeeld

<tr><td scope="col">Maand</td><td scope="col">Totaal</td></tr>

<tr><th scope="col">Maand</th><th scope="col">Totaal</th></tr>

Hoe controleer je dit?

Navigeer met een schermlezer door een tabel en controleer of headers correct worden aangekondigd bij elke cel.

Wat controleert deze regel?

Een skip-link ("ga direct naar hoofdinhoud") moet verwijzen naar een bestaand element dat focus kan krijgen zodat de browser er daadwerkelijk naartoe springt.

Waarom is dit belangrijk?

Skip-links zijn vaak het eerste element op een pagina voor toetsenbord-gebruikers. Een gebroken skip-link (verwijst naar niet-bestaand ID of naar een element dat geen focus kan krijgen) frustreert juist de gebruikers die het meest afhankelijk zijn van goede navigatie.

Hoe los je dit op?

Zorg dat het anker-ID bestaat op de bestemming, en dat dat element focusbaar is (heeft een interactieve rol of tabindex="-1" zodat JavaScript-focus werkt).

Code voorbeeld

<a class="skip-link" href="#main-content">Skip to main</a>
...
<main id="main-content" tabindex="-1">...</main>

Hoe controleer je dit?

Tab één keer op een pagina: de eerste focus hoort op de skip-link te landen. Activeer (Enter) en controleer of focus naar de hoofdinhoud springt.

Wat controleert deze regel?

Alle zichtbare content op een pagina hoort binnen een semantisch landmark te staan: <header>, <nav>, <main>, <aside> of <footer> (of de equivalente ARIA rollen).

Waarom is dit belangrijk?

Schermlezer-gebruikers navigeren door landmarks heen om snel bij een bepaalde sectie te komen. Content buiten landmarks wordt overgeslagen bij deze navigatie en is moeilijker te vinden.

Hoe los je dit op?

Wikkel alle content in de juiste HTML5 landmark-elementen. Losse <div>'s op top niveau horen hoogstwaarschijnlijk in een van de bovenstaande elementen thuis.

Code voorbeeld

<body>
  <div class="header">...</div>
  <div class="content">...</div>
  <div class="footer">...</div>
</body>

<body>
  <header>...</header>
  <main>...</main>
  <footer>...</footer>
</body>

Hoe controleer je dit?

Gebruik een browser-extensie zoals Landmarks (Firefox/Chrome) om alle landmarks op een pagina te visualiseren en controleer of er content tussen valt.

Wat controleert deze regel?

Per pagina mag er slechts één banner landmark zijn. Dit is normaal het <header> element dat direct kind is van <body>, of een element met role="banner".

Waarom is dit belangrijk?

Meerdere banners maken de paginastructuur onduidelijk. Schermlezer-gebruikers verwachten één herkenbare site-header waarin meestal logo en hoofdnavigatie staan.

Hoe los je dit op?

Gebruik <header> alleen op top niveau voor de site-header. Headers binnen <article> of <section> tellen niet als banner (dat zijn sectie-headers) mits ze binnen die elementen staan.

Hoe controleer je dit?

Zoek in DevTools of via een landmarks-extensie naar alle banner landmarks: je hoort er maximaal één te vinden.

Wat controleert deze regel?

Een banner (site-header) hoort op het hoogste niveau van de pagina te staan, niet genest binnen een ander landmark.

Waarom is dit belangrijk?

Geneste banners doorbreken de verwachte hiërarchie. De gebruiker verwacht de banner als eerste te vinden met een sneltoets.

Hoe los je dit op?

Plaats <header> (met role="banner") als directe kind van <body>. Gebruik <header> binnen <article> of <section> alleen als sectie-header zonder role="banner".

Hoe controleer je dit?

Inspecteer DOM: de site-header moet een direct child zijn van body, niet van main, article of iets anders.

Wat controleert deze regel?

Er hoort maximaal één contentinfo (footer) landmark per pagina te zijn. Dit is normaal de site-footer onderin.

Waarom is dit belangrijk?

Meerdere footers verwarren gebruikers die met footer-sneltoetsen naar copyright en contactinformatie springen.

Hoe los je dit op?

Gebruik <footer> op top niveau voor de site-footer. Footers binnen <article> (bijvoorbeeld een datum of auteursregel) tellen niet als contentinfo mits ze binnen het article element staan.

Hoe controleer je dit?

Inspecteer DOM: op top niveau hoort één <footer> of element met role="contentinfo" te staan.

Wat controleert deze regel?

Een pagina mag maximaal één zichtbare main hebben. Meerdere mains zijn alleen toegestaan als er steeds één zichtbaar is (bijvoorbeeld bij tabbed interfaces).

Waarom is dit belangrijk?

Een uniek main landmark stelt gebruikers in staat direct naar de hoofdinhoud te springen. Meerdere mains ondermijnen die functionaliteit.

Hoe los je dit op?

Combineer de content in één main element, of verberg de niet-actieve mains met hidden attribuut.

Hoe controleer je dit?

Inspecteer DOM op meerdere main elementen en controleer of slechts één zichtbaar is.

Wat controleert deze regel?

Elementen met role="complementary" of <aside> op top niveau (niet binnen article of section) horen niet genest te zijn binnen andere landmarks.

Waarom is dit belangrijk?

Complementary landmarks (sidebars, aanverwante info) zijn ontworpen om naast de hoofdcontent te staan. Als ze genest worden binnen main of andere landmarks ontstaat een structureel onjuiste opbouw.

Hoe los je dit op?

Plaats <aside> die een zelfstandige sectie vertegenwoordigt als direct kind van <body>, naast <main>. Asides binnen <article> zijn anders en krijgen geen complementary rol toegewezen.

Hoe controleer je dit?

Inspecteer DOM: top-level asides moeten parallel aan main staan, niet erin.

Wat controleert deze regel?

De site-footer (contentinfo landmark) hoort op het hoogste niveau van de pagina te staan.

Waarom is dit belangrijk?

Schermlezer-gebruikers springen met een sneltoets naar de footer voor contactinformatie. Een geneste footer is niet bereikbaar via die shortcut.

Hoe los je dit op?

Plaats <footer> met role="contentinfo" als direct kind van <body>. Als je <footer> binnen <main> of <article> gebruikt, gaat dat alleen op als het een sectie-specifieke footer is zonder role="contentinfo".

Hoe controleer je dit?

De site-footer moet in DevTools een direct child van body zijn.

Wat controleert deze regel?

Het <main> element mag niet genest zijn binnen een ander landmark (header, nav, aside, footer).

Waarom is dit belangrijk?

Main is per definitie de hoofdinhoud van de pagina en hoort parallel aan de andere landmarks te staan, niet eronder.

Hoe los je dit op?

Plaats <main> als direct kind van <body>, nooit binnen andere landmarks.

Hoe controleer je dit?

Inspecteer DOM: main hoort direct onder body te staan.

Wat controleert deze regel?

Als een pagina meerdere landmarks van hetzelfde type heeft (bijvoorbeeld twee nav landmarks), moet elk een unieke naam hebben via aria-label of aria-labelledby.

Waarom is dit belangrijk?

Schermlezer-gebruikers zien bij een landmarks-lijst alleen het type van het landmark ("navigation"). Zonder onderscheidende naam kunnen ze "hoofdmenu" niet van "footer-menu" onderscheiden.

Hoe los je dit op?

Geef elke navigatie, section of complementary landmark een aria-label met een onderscheidende naam.

Code voorbeeld

<nav aria-label="Hoofdnavigatie">...</nav>
<nav aria-label="Footer">...</nav>

Hoe controleer je dit?

Open de landmarks-lijst in een schermlezer (bijvoorbeeld VoiceOver Rotor) en controleer dat elke landmark een unieke naam heeft.

Wat controleert deze regel?

Elementen met role="presentation" of role="none" worden door schermlezers genegeerd. Als zo'n element toch focus krijgt of betekenisvolle child elementen heeft, ontstaat een conflict.

Waarom is dit belangrijk?

Een element dat als presentational is gemarkeerd hoort geen semantische rol meer te hebben, maar soms raapt de browser alsnog interactieve children op, wat verwarrend is.

Hoe los je dit op?

Gebruik role="presentation" alleen op zuivere layout-tags (oude tabellen voor layout, decoratieve iconen). Plaats geen interactieve of semantische inhoud binnen presentational elementen.

Hoe controleer je dit?

Controleer met DevTools Accessibility panel of presentational elementen inderdaad geen naam of rol hebben.

Wat controleert deze regel?

ARIA rollen mogen niet conflicteren met de semantiek van het onderliggende HTML element. role="button" op een <a> element wordt bijvoorbeeld afgeraden.

Waarom is dit belangrijk?

Dubbele of conflicterende semantiek verwart schermlezers. Gebruik de juiste HTML elementen in plaats van alles via ARIA op te lossen.

Hoe los je dit op?

Volg de regel "No ARIA is better than bad ARIA": gebruik <button> voor knoppen, <a href> voor links, <input type="checkbox"> voor checkboxes. Voeg ARIA alleen toe als het standaard HTML niet volstaat.

Code voorbeeld

<div role="button" tabindex="0">Klik hier</div>

<button>Klik hier</button>

Hoe controleer je dit?

Controleer of ieder element met een ARIA role echt die aanvullende informatie nodig heeft. Zo niet, gebruik het juiste HTML element.

Wat controleert deze regel?

Heading-elementen (h1 tot h6) moeten altijd tekstinhoud of een equivalent voor schermlezers bevatten.

Waarom is dit belangrijk?

Lege headings creëren geen bruikbaar ankerpunt en verstoren de hiërarchie. Schermlezer-gebruikers zien een lege entry in de headings-lijst, wat verwarring veroorzaakt.

Hoe los je dit op?

Zorg dat elke heading tekst bevat. Als een heading een icoon is, gebruik dan een aria-label. Verwijder lege h-tags die vaak per ongeluk door CMS-editors worden toegevoegd.

Code voorbeeld

<h2></h2>
<h2><i class="icon-star"></i></h2>

<h2>Voordelen</h2>
<h2><i class="icon-star" aria-hidden="true"></i> Voordelen</h2>

Hoe controleer je dit?

DevTools console: Array.from(document.querySelectorAll('h1,h2,h3,h4,h5,h6')).filter(h => !h.textContent.trim()).length - hoort 0 te zijn.

Wat controleert deze regel?

De meta viewport tag hoort gebruikers niet te beperken in inzoomen. Idealiter tot minimaal 500% voor mensen die dit nodig hebben om tekst te kunnen lezen.

Waarom is dit belangrijk?

Mensen met een visuele beperking hebben vaak 200 tot 500% zoom nodig. Als de viewport dit blokkeert of de maximum-scale te laag zet, is de site onbruikbaar voor hen.

Hoe los je dit op?

Gebruik een viewport tag zonder user-scalable=no en zonder maximum-scale, of zet maximum-scale op 5 of hoger.

Code voorbeeld

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

<meta name="viewport" content="width=device-width, initial-scale=1">

Hoe controleer je dit?

Test op mobiel: probeer te pinch-zoomen op de pagina. Als dit niet werkt, klopt de viewport niet.

Wat controleert deze regel?

Als een afbeelding alt-tekst heeft die identiek is aan direct omringende zichtbare tekst, krijgt de schermlezer-gebruiker dezelfde informatie twee keer te horen.

Waarom is dit belangrijk?

Dubbele aankondigingen zijn vermoeiend en traag voor schermlezer-gebruikers. Ze zijn vaak het resultaat van automatisch gegenereerde alt-tekst in CMSen.

Hoe los je dit op?

Als de afbeelding puur decoratief is naast tekst met dezelfde betekenis, geef het een lege alt (alt=""). Geef het alleen een alt als het écht informatie toevoegt.

Code voorbeeld

<img src="award.png" alt="Award winnaar 2024">
<p>Award winnaar 2024</p>

<img src="award.png" alt="">
<p>Award winnaar 2024</p>

Hoe controleer je dit?

Loop door content-pagina's en check of img alt attributen niet identiek zijn aan de direct omringende tekst.

Wat controleert deze regel?

Elke <th> in een datatabel hoort leesbare tekst te bevatten die de inhoud van die kolom of rij beschrijft.

Waarom is dit belangrijk?

Schermlezers lezen bij elke cel de bijbehorende header voor. Lege of ondoorgrondelijke headers maken de tabel onleesbaar.

Hoe los je dit op?

Geef iedere th een duidelijke tekst. Gebruik aria-label als alleen een icoon in de header staat. Voorkom lege cellen links bovenin tabellen.

Hoe controleer je dit?

Controleer datatabellen in DevTools: elke th moet niet-lege tekstinhoud hebben.

Wat controleert deze regel?

Het summary attribuut en de <caption> van een tabel hebben verschillende functies en mogen niet dezelfde tekst bevatten.

Waarom is dit belangrijk?

Caption beschrijft wat de tabel is (titel), summary beschrijft de structuur en hoe de tabel gelezen moet worden. Als ze identiek zijn wordt de gebruiker tweemaal hetzelfde voorgelezen.

Hoe los je dit op?

Het summary attribuut is in HTML5 deprecated. Gebruik alleen <caption> voor de tabeltitel en leg de structuur uit in tekst boven de tabel indien nodig.

Hoe controleer je dit?

Verwijder summary attributen bij voorkeur geheel. Als ze er staan, moeten ze iets wezenlijk anders zeggen dan de caption.

Wat controleert deze regel?

Regios met overflow scroll (bijvoorbeeld een div met overflow-y:auto) moeten met toetsenbord te scrollen zijn. Dit vereist dat het element focusbaar is.

Waarom is dit belangrijk?

Gebruikers die geen muis gebruiken moeten ook de inhoud van scroll-containers kunnen lezen. Als het element geen focus krijgt, is er geen manier om te scrollen.

Hoe los je dit op?

Geef scrollbare containers tabindex="0" zodat ze focusbaar worden. De browser zorgt dan voor toetsenbord-scrollen met pijltjestoetsen en Page Up/Down.

Code voorbeeld

<div style="overflow-y:auto; height:200px">...lange content...</div>

<div tabindex="0" role="region" aria-label="Beschrijving" style="overflow-y:auto; height:200px">...lange content...</div>

Hoe controleer je dit?

Tab naar de scroll-container: je moet een focus-indicator zien. Gebruik dan pijltjestoetsen om te scrollen.

Wat controleert deze regel?

Sommige ARIA rollen vereisen specifieke attributen om correct te functioneren. role="checkbox" vereist bijvoorbeeld aria-checked.

Waarom is dit belangrijk?

Zonder de verplichte attributen kan de schermlezer de staat van het element niet bepalen. Een checkbox zonder aria-checked klinkt bijvoorbeeld niet als checked of unchecked.

Hoe los je dit op?

Controleer per gebruikte ARIA rol welke attributen verplicht zijn. Gebruik bij voorkeur native HTML (input type=checkbox) waar dat mogelijk is.

Code voorbeeld

<div role="checkbox">Ik ga akkoord</div>

<div role="checkbox" aria-checked="false" tabindex="0">Ik ga akkoord</div>

Hoe controleer je dit?

Raadpleeg de ARIA Authoring Practices Guide voor elk role. Test met een schermlezer of staten correct worden aangekondigd.

Wat controleert deze regel?

Elk ARIA attribuut heeft regels over welke rollen en elementen het mag gebruiken. Verkeerd gebruik maakt het attribuut ineffectief.

Waarom is dit belangrijk?

Een aria-checked op iets anders dan een checkbox- of radio-achtig element wordt door schermlezers genegeerd, maar kan wel verwarring veroorzaken of onverwacht gedrag geven.

Hoe los je dit op?

Gebruik aria-* attributen alleen op de rollen waarvoor ze bedoeld zijn. Raadpleeg WAI-ARIA 1.2 specificatie bij twijfel.

Hoe controleer je dit?

Automatische toegankelijkheidstools vangen dit op. Handmatig: vergelijk elk ARIA attribuut met de specificatie.

Wat controleert deze regel?

ARIA attributen hebben vaak een beperkte set toegestane waarden. aria-expanded kan bijvoorbeeld alleen "true" of "false" zijn.

Waarom is dit belangrijk?

Een ongeldige waarde wordt genegeerd, waardoor de schermlezer de staat van het element niet kent. Dat maakt bijvoorbeeld collapsible menu's stuk voor schermlezer-gebruikers.

Hoe los je dit op?

Gebruik alleen de waarden uit de ARIA specificatie. Let op typefouten (TRUE in hoofdletters werkt wel, maar waarden als "yes" of "open" niet).

Code voorbeeld

<button aria-expanded="open">Menu</button>

<button aria-expanded="true">Menu</button>

Hoe controleer je dit?

Test in axe DevTools browser-extensie. Alle aria-* attributen met ongeldige waarden worden gerapporteerd.

Wat controleert deze regel?

Alleen ARIA attributen die in de specificatie staan werken. Aria-exapnded (typo) of aria-foo (verzonnen) worden genegeerd.

Waarom is dit belangrijk?

Typo's in attribuutnamen zijn stille fouten: er gebeurt niets verkeerd zichtbaar, maar de beoogde toegankelijkheidsverbetering werkt niet.

Hoe los je dit op?

Gebruik de lijst van geldige ARIA attributen uit de WAI-ARIA specificatie. Moderne IDE's met HTML-linting vangen vaak typo's.

Hoe controleer je dit?

axe DevTools rapporteert onbekende aria-* attributen.

Wat controleert deze regel?

Elementen met command-achtige rollen (role="button", role="link", role="menuitem") hebben een toegankelijke naam nodig.

Waarom is dit belangrijk?

Zonder naam wordt de knop aangekondigd als "button" zonder dat de gebruiker weet wat de actie doet. Dit maakt de knop effectief onbruikbaar voor schermlezer-gebruikers.

Hoe los je dit op?

Zorg dat de knop tekst bevat, of gebruik aria-label of aria-labelledby. Liever nog: gebruik een native <button> met tekst.

Code voorbeeld

<div role="button" aria-label="Sluiten" tabindex="0">×</div>

Hoe controleer je dit?

Tab naar elk command element en luister naar de aankondiging in een schermlezer.

Wat controleert deze regel?

Custom input componenten (role="textbox", role="combobox", role="searchbox") moeten een toegankelijke naam hebben.

Waarom is dit belangrijk?

Schermlezer-gebruikers moeten weten wat ze invullen. "textbox" zonder context is onbruikbaar.

Hoe los je dit op?

Gebruik aria-label, aria-labelledby, of een gekoppeld <label> element. Nog beter: gebruik native <input>.

Code voorbeeld

<div role="combobox" aria-label="Land" aria-expanded="false">...</div>

Hoe controleer je dit?

Tab naar elk ARIA input veld en controleer dat de naam wordt voorgelezen.

Wat controleert deze regel?

Elementen met role="meter" (voor bijvoorbeeld schijfruimte of batterijstatus) hebben een naam nodig die aangeeft wat er gemeten wordt.

Waarom is dit belangrijk?

Een meter zonder naam vertelt de gebruiker niet wat er gemeten wordt. Een waarde van 60% is betekenisloos zonder context.

Hoe los je dit op?

Gebruik bij voorkeur het native <meter> element met een zichtbaar label, of aria-label/aria-labelledby op een div met role=meter.

Code voorbeeld

<label for="disk">Schijfruimte</label>
<meter id="disk" value="0.6" min="0" max="1">60%</meter>

Hoe controleer je dit?

Raadpleeg DevTools Accessibility panel om de naam van de meter te controleren.

Wat controleert deze regel?

Progressbars (role="progressbar") moeten een naam hebben die aangeeft wat er voortgaat.

Waarom is dit belangrijk?

"75% voltooid" is betekenisloos zonder context. De gebruiker moet weten of het om bestandsupload, pagina-laden of iets anders gaat.

Hoe los je dit op?

Gebruik native <progress> met label, of aria-label op een custom progressbar.

Code voorbeeld

<div role="progressbar" aria-label="Upload voortgang" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100">75%</div>

Hoe controleer je dit?

Schermlezer moet iets als "Upload voortgang, 75 procent" aankondigen.

Wat controleert deze regel?

Sommige ARIA rollen mogen alleen binnen een specifieke ouder voorkomen. role="listitem" moet bijvoorbeeld binnen role="list" of een <ul>/<ol> staan.

Waarom is dit belangrijk?

Schermlezer-gebruikers verwachten bepaalde relaties. Een listitem zonder list is een weesitem zonder context.

Hoe los je dit op?

Gebruik ARIA rollen in de context waarvoor ze bedoeld zijn. Gebruik bij voorkeur native HTML (<ul><li>) zodat deze relatie automatisch klopt.

Hoe controleer je dit?

axe DevTools rapporteert weesrollen. Handmatig: controleer dat elke listitem, menuitem, treeitem een juiste parent heeft.

Wat controleert deze regel?

Alleen bestaande, juist gespelde ARIA rollen werken. role="buton" (typefout) of role="bigbutton" worden genegeerd.

Waarom is dit belangrijk?

Typfouten zijn stille fouten: de intentie is goed maar het effect is nul. De schermlezer krijgt geen rol-informatie door.

Hoe los je dit op?

Gebruik alleen rollen uit de WAI-ARIA specificatie. IDE's met HTML-linting vangen dit vaak op.

Hoe controleer je dit?

axe DevTools rapporteert onbekende role-waarden.

Wat controleert deze regel?

Toggle velden (checkbox, radio, switch) met ARIA rollen moeten een naam hebben zodat de gebruiker weet wat er aan of uit wordt gezet.

Waarom is dit belangrijk?

Een anonieme checkbox is niet te bedienen door schermlezer-gebruikers. "checked, checkbox" zonder label zegt niets.

Hoe los je dit op?

Geef elk toggle een label via <label>, aria-label of aria-labelledby. Gebruik bij voorkeur native inputs.

Code voorbeeld

<label><input type="checkbox"> Nieuwsbrief ontvangen</label>

Hoe controleer je dit?

Schermlezer moet bij elke toggle zowel de naam als de staat aankondigen.

Wat controleert deze regel?

Elementen met role="tooltip" moeten een naam hebben, meestal de inhoud van de tooltip zelf.

Waarom is dit belangrijk?

Een naamloze tooltip wordt niet voorgelezen wanneer hij verschijnt, waardoor de hulpinfo niet toegankelijk is.

Hoe los je dit op?

Zorg dat de tooltip tekstinhoud heeft of gebruik aria-label. Koppel de tooltip aan het trigger-element met aria-describedby.

Code voorbeeld

<button aria-describedby="tip1">Info</button>
<div role="tooltip" id="tip1">Uitleg over deze knop</div>

Hoe controleer je dit?

Focus het trigger-element en controleer dat de tooltip-inhoud wordt voorgelezen.

Wat controleert deze regel?

Rollen als role="list" vereisen role="listitem" als kinderen. role="menu" vereist role="menuitem". Ontbrekende kinderen maken de structuur onbruikbaar.

Waarom is dit belangrijk?

Als een menu geen menuitems bevat, navigeert de gebruiker door lucht. De schermlezer verwacht bepaalde structuur bij bepaalde rollen.

Hoe los je dit op?

Gebruik native HTML elementen die de correcte kind-elementen afdwingen. Bij custom widgets: zorg dat alle vereiste kindrollen aanwezig zijn.

Hoe controleer je dit?

Tab door de widget met een schermlezer en controleer of de structuur logisch is.

Wat controleert deze regel?

De attributen aria-braillelabel en aria-brailleroledescription mogen alleen gebruikt worden als er ook een gewone aria-label of aria-roledescription aanwezig is.

Waarom is dit belangrijk?

Braille-attributen zijn bedoeld als aanvulling op gesproken tekst, niet als vervanging. Zonder niet-braille variant mist de gesproken schermlezer informatie.

Hoe los je dit op?

Als je aria-braillelabel gebruikt, voeg dan altijd ook aria-label toe. Hetzelfde voor aria-brailleroledescription naast aria-roledescription.

Hoe controleer je dit?

Zoek in DOM naar aria-braille* attributen en controleer of er een niet-braille variant bij staat.

Wat controleert deze regel?

Als je een element verbergt voor schermlezers via aria-hidden="true", mag dat element geen focusbare elementen bevatten.

Waarom is dit belangrijk?

Tab naar een knop binnen aria-hidden geeft een paradox: de knop krijgt focus, maar de schermlezer meldt niets. De gebruiker raakt gedesoriënteerd.

Hoe los je dit op?

Als je een container verbergt, zorg dan dat geen enkel element erbinnen focusbaar is. Gebruik eventueel ook het hidden attribuut, of verwijder tabindex, of zet tabindex="-1" op focusbare kinderen.

Code voorbeeld

<div aria-hidden="true">
  <a href="/x">Klik hier</a>
</div>

<div aria-hidden="true" inert>
  <a href="/x">Klik hier</a>
</div>

Hoe controleer je dit?

Tab door de pagina en controleer of focus nooit in een aria-hidden container terechtkomt.

Wat controleert deze regel?

Het body element mag nooit aria-hidden="true" krijgen, aangezien dat de hele pagina verbergt voor schermlezers.

Waarom is dit belangrijk?

Een aria-hidden op body maakt de pagina compleet onzichtbaar voor schermlezer-gebruikers. De hele site wordt onbruikbaar.

Hoe los je dit op?

Verwijder aria-hidden="true" van het body element. Als je een modal opent en de rest wilt uitschakelen, gebruik dan inert of aria-hidden op een wrapper-div binnen body, niet op body zelf.

Hoe controleer je dit?

Inspecteer het body element: er mag geen aria-hidden op staan.

Wat controleert deze regel?

Bepaalde HTML elementen staan geen of beperkte ARIA toe. Een <div> mag alles, maar een <input type="submit"> mag geen aria-pressed.

Waarom is dit belangrijk?

Niet-toegestane ARIA op native elementen kan het gedrag verstoren. De browser en assistive technology raken in conflict.

Hoe los je dit op?

Volg de regel "No ARIA is better than bad ARIA". Controleer per element welke ARIA attributen zijn toegestaan in de HTML Accessibility API Mappings specificatie.

Hoe controleer je dit?

axe DevTools markeert niet-toegestane combinaties.

Wat controleert deze regel?

ARIA attributen moeten passen bij de rol van het element, impliciet of expliciet. aria-checked op een <div> zonder role="checkbox" wordt genegeerd.

Waarom is dit belangrijk?

Attributen zonder passende rol hebben geen effect en suggereren vals veiligheid. De ontwikkelaar denkt dat iets toegankelijk is, maar het werkt niet.

Hoe los je dit op?

Gebruik ARIA attributen alleen in combinatie met de bijbehorende rol. Controleer per attribuut welke rollen het ondersteunen.

Hoe controleer je dit?

axe DevTools rapporteert dit soort mismatches.

Wat controleert deze regel?

ID's waar aria-labelledby, aria-describedby, for of andere attributen naar verwijzen moeten uniek zijn in het document.

Waarom is dit belangrijk?

Bij duplicate ID's pakt de browser doorgaans alleen de eerste. De verwijzing werkt dan niet correct voor andere elementen.

Hoe los je dit op?

Zorg dat alle ID's in het document uniek zijn. Gebruik een naming-conventie (component-naam + unieke suffix) om collisions te voorkomen.

Hoe controleer je dit?

DevTools console: let s = new Set(); document.querySelectorAll('[id]').forEach(e => { if(s.has(e.id)) console.log('dup:', e.id); else s.add(e.id); }); - hoort niets te loggen.

Wat controleert deze regel?

Een pagina moet een mechanisme hebben om herhaalde content (header, navigatie) over te slaan. Meestal is dit een skip-link bovenaan, of een main landmark.

Waarom is dit belangrijk?

Toetsenbord-gebruikers moeten op elke pagina door dezelfde navigatie heen. Zonder skip-link kost dat tientallen tab-aanslagen per pagina.

Hoe los je dit op?

Plaats als eerste element op de pagina een zichtbare of focus-zichtbare skip-link naar #main. Alternatief: zorg dat er een main landmark is zodat schermlezers er direct naartoe kunnen springen.

Code voorbeeld

<a class="skip-link" href="#main">Skip to main content</a>
...
<main id="main">

Hoe controleer je dit?

Druk één keer Tab bij een frisse paginalading. De focus hoort op de skip-link te landen (zichtbaar).

Wat controleert deze regel?

Elk <iframe> en <frame> hoort een beschrijvend title attribuut te hebben.

Waarom is dit belangrijk?

De schermlezer kondigt de titel aan als de gebruiker bij de iframe komt. Zonder title hoort de gebruiker alleen "frame" zonder wat erin zit.

Hoe los je dit op?

Geef elke iframe een title dat beschrijft wat er in staat. Niet "iframe" of "embedded content" maar bijvoorbeeld "Google Maps routebeschrijving naar kantoor".

Code voorbeeld

<iframe src="..." title="YouTube video: Introductie Joomla"></iframe>

Hoe controleer je dit?

Doorloop alle iframes op de site en controleer of elke een zinvolle title heeft.

Wat controleert deze regel?

Als een pagina meerdere iframes heeft, moeten de titles uniek zijn.

Waarom is dit belangrijk?

Twee iframes met dezelfde titel zijn niet van elkaar te onderscheiden voor schermlezer-gebruikers.

Hoe los je dit op?

Geef elke iframe een unieke, beschrijvende titel. Voeg context toe als de content van de iframes lijkt ("Video 1", "Video 2" is beter dan twee keer "Video").

Hoe controleer je dit?

DevTools: Array.from(document.querySelectorAll('iframe')).map(f=>f.title) - controleer op duplicaten.

Wat controleert deze regel?

Een iframe met tabindex="-1" is niet bereikbaar via tab. Als de iframe focusbare content bevat, wordt die content onbereikbaar voor toetsenbord-gebruikers.

Waarom is dit belangrijk?

Een YouTube-embed met tabindex="-1" bevat knoppen die niet meer bereikbaar zijn. De gebruiker kan de video niet bedienen.

Hoe los je dit op?

Haal tabindex="-1" weg van iframes die interactieve content bevatten. Gebruik tabindex="-1" alleen op iframes met zuiver decoratieve content.

Hoe controleer je dit?

Tab door de pagina en controleer of je in elke iframe kunt komen.

Wat controleert deze regel?

Elke pagina moet een niet-leeg <title> element in de <head> hebben.

Waarom is dit belangrijk?

De page title wordt getoond in browsertabs, bookmarks, zoekresultaten en is het eerste dat schermlezers voorlezen bij het openen van een pagina. Zonder title is oriëntatie onmogelijk.

Hoe los je dit op?

Zorg dat elke pagina (inclusief ajax-endpoints die als HTML worden gerenderd) een unieke, beschrijvende title heeft.

Code voorbeeld

<head>
  <title>Toegankelijkheidsrapport voor joomill.nl — Joomill</title>
</head>

Hoe controleer je dit?

Controleer voor elk pagina-type dat document.title een zinvolle waarde heeft.

Wat controleert deze regel?

Het lang attribuut op <html> moet een geldige BCP 47 taalcode bevatten (bijvoorbeeld "nl", "en-US", "nl-BE").

Waarom is dit belangrijk?

Schermlezers gebruiken het lang attribuut om het juiste uitspraak-profiel te kiezen. Een ongeldige code (lang="dutch" in plaats van "nl") wordt genegeerd en de tekst klinkt dan als andere taal.

Hoe los je dit op?

Gebruik ISO 639-1 codes (nl, en, de, fr) eventueel met regio (nl-BE, en-GB). Niet "Dutch" of "nederlands".

Code voorbeeld

<html lang="dutch">

<html lang="nl">

Hoe controleer je dit?

Inspecteer het html element: lang attribuut moet voldoen aan BCP 47.

Wat controleert deze regel?

Het <html> element moet een lang attribuut hebben dat de primaire taal van de pagina aangeeft.

Waarom is dit belangrijk?

Zonder lang weet een schermlezer niet in welke taal hij moet voorlezen. Nederlandse tekst wordt dan in een Engels profiel uitgesproken, wat onverstaanbaar kan zijn.

Hoe los je dit op?

Voeg een lang attribuut toe aan het html element met de juiste taalcode.

Code voorbeeld

<html lang="nl">

Hoe controleer je dit?

DevTools: document.documentElement.lang moet een niet-lege, geldige waarde hebben.

Wat controleert deze regel?

Een <input type="image"> wordt gerenderd als een klikbare afbeelding en heeft een alt attribuut nodig.

Waarom is dit belangrijk?

Zonder alt hoort de schermlezer alleen "submit button, image" zonder te weten wat de knop doet.

Hoe los je dit op?

Geef input type=image altijd een alt attribuut dat de actie beschrijft.

Code voorbeeld

<input type="image" src="search.png" alt="Zoeken">

Hoe controleer je dit?

Controleer in DevTools dat elk input type=image een alt attribuut heeft.

Wat controleert deze regel?

Het <object> element (embed van externe content zoals PDFs of Flash) moet een tekstuele fallback bieden binnen het object.

Waarom is dit belangrijk?

Als de embed niet geladen kan worden, of de gebruiker een schermlezer gebruikt, moet er alternatieve tekst zijn.

Hoe los je dit op?

Plaats beschrijvende tekst binnen het <object> element of gebruik een title attribuut.

Code voorbeeld

<object data="brochure.pdf" type="application/pdf">
  <p>Download de <a href="brochure.pdf">Brochure (PDF, 1MB)</a></p>
</object>

Hoe controleer je dit?

Inspecteer elke <object> in DevTools op fallback content of title.

Wat controleert deze regel?

In een image map moet elke klikbare <area> een alt attribuut hebben dat de bestemming beschrijft.

Waarom is dit belangrijk?

Een area zonder alt is een link zonder tekst voor schermlezer-gebruikers.

Hoe los je dit op?

Geef elke area een alt die de doelpagina of actie beschrijft.

Code voorbeeld

<map name="wereld">
  <area shape="rect" coords="0,0,100,100" href="/nl" alt="Nederland">
</map>

Hoe controleer je dit?

Doorloop image maps en controleer alt attributen op elke area met href.

Wat controleert deze regel?

Een element met role="img" (meestal gebruikt voor icoonbundels of CSS-afbeeldingen) moet een toegankelijke naam hebben.

Waarom is dit belangrijk?

Zonder naam wordt het element als afbeelding aangekondigd zonder beschrijving van wat er te zien is.

Hoe los je dit op?

Gebruik aria-label of aria-labelledby op het element met role="img".

Code voorbeeld

<span role="img" aria-label="Rode waarschuwing">⚠️</span>

Hoe controleer je dit?

Controleer alle elementen met role=img op een toegankelijke naam via DevTools Accessibility panel.

Wat controleert deze regel?

Inline SVG moet een <title> element als eerste kind hebben, of gebruik maken van aria-label/aria-labelledby.

Waarom is dit belangrijk?

SVG zonder title wordt door schermlezers niet aangekondigd. Voor informatieve iconen (statusindicatoren, grafieken) is dat een probleem.

Hoe los je dit op?

Voeg <title> toe als eerste kind van de SVG. Als het icoon decoratief is, gebruik role="img" aria-hidden="true" of geef role="presentation".

Code voorbeeld

<svg role="img" aria-labelledby="t1">
  <title id="t1">Groen vinkje: voltooid</title>
  <path .../>
</svg>

Hoe controleer je dit?

Controleer met DevTools Accessibility panel of SVG's de juiste naam hebben.

Wat controleert deze regel?

Video's met geluid hebben ondertiteling nodig via een <track kind="captions"> element.

Waarom is dit belangrijk?

Doven en slechthorenden kunnen de gesproken inhoud anders niet volgen. Ook mensen in luidruchtige omgevingen of met geluid uit profiteren.

Hoe los je dit op?

Voeg een track element toe naar een WebVTT ondertitelingsbestand. Voor YouTube embeds: schakel ondertiteling in en zorg dat er goede captions (niet alleen auto-generated) beschikbaar zijn.

Code voorbeeld

<video controls>
  <source src="video.mp4" type="video/mp4">
  <track kind="captions" src="nl.vtt" srclang="nl" label="Nederlands">
</video>

Hoe controleer je dit?

Speel elke video af en controleer of ondertiteling zichtbaar is.

Wat controleert deze regel?

Media mag niet automatisch afspelen met geluid als de gebruiker daar geen controle over heeft. De gebruiker moet het kunnen stoppen binnen korte tijd.

Waarom is dit belangrijk?

Onverwacht audio interfereert met schermlezers. De gebruiker kan mogelijk niet eens de controls vinden om te stoppen.

Hoe los je dit op?

Verwijder het autoplay attribuut, of zorg dat media muted start en duidelijke pauze-controls heeft.

Code voorbeeld

<video autoplay src="intro.mp4"></video>

<video controls src="intro.mp4"></video>

Hoe controleer je dit?

Laad elke pagina met media en controleer of er nergens onverwacht geluid speelt.

Wat controleert deze regel?

Elke <button> moet tekstinhoud of een aria-label hebben die aangeeft wat de knop doet.

Waarom is dit belangrijk?

Een lege knop of een knop met alleen een icoon zonder aria-label is niet bruikbaar voor schermlezer-gebruikers. De gebruiker hoort "button" zonder te weten welke actie volgt.

Hoe los je dit op?

Zet tekst in de knop, of voeg aria-label toe voor icoon-knoppen. Maak icoon-elementen binnen de knop aria-hidden.

Code voorbeeld

<button><i class="icon-close"></i></button>

<button aria-label="Sluiten"><i class="icon-close" aria-hidden="true"></i></button>

Hoe controleer je dit?

Tab naar elke knop en luister wat een schermlezer zegt. "button" zonder extra info is fout.

Wat controleert deze regel?

<input type="submit">, <input type="button"> en <input type="reset"> moeten een value attribuut hebben dat de actie beschrijft.

Waarom is dit belangrijk?

Zonder value gebruikt de browser een default tekst ("Submit") die niet altijd de actie beschrijft. Met een lege value hoort de schermlezer niets.

Hoe los je dit op?

Geef elke input van deze types een beschrijvende value.

Code voorbeeld

<input type="submit">

<input type="submit" value="Versturen">

Hoe controleer je dit?

Inspecteer elk input element van button-types en controleer op een zinvolle value.

Wat controleert deze regel?

Links in lopende tekst moeten visueel te onderscheiden zijn van normale tekst, meestal via onderstreping of een duidelijk kleurverschil met contrast 3:1 tegenover omliggende tekst.

Waarom is dit belangrijk?

Kleurenblinde gebruikers kunnen links alleen op kleur niet herkennen. Onderstreping of andere visuele marker helpt hen.

Hoe los je dit op?

Onderstreep links in lopende tekst, of zorg voor een kleurcontrast van minstens 3:1 tussen link- en omliggende tekstkleur én een extra niet-kleurgebaseerde marker (zoals onderstreping bij hover).

Code voorbeeld

a { color: #0066cc; text-decoration: underline; }

Hoe controleer je dit?

Bekijk de site in grijsschaal (browser extensie) en controleer of links nog steeds herkenbaar zijn.

Wat controleert deze regel?

Een <summary> binnen een <details> element moet tekstinhoud hebben zodat de gebruiker weet wat er kan worden uitgeklapt.

Waarom is dit belangrijk?

Een lege summary geeft een anoniem uitklapbaar element. De gebruiker weet niet wat zich erachter bevindt.

Hoe los je dit op?

Zorg voor een duidelijke tekst in elke summary.

Code voorbeeld

<details>
  <summary>Veelgestelde vragen</summary>
  <p>...</p>
</details>

Hoe controleer je dit?

Controleer alle details/summary combinaties op niet-lege summary tekst.

Wat controleert deze regel?

Het <marquee> element (scrollende tekst) is verouderd en niet toegankelijk.

Waarom is dit belangrijk?

Scrollende tekst kan epilepsie triggeren, is lastig te lezen voor mensen met leesbeperkingen en kan niet worden gepauzeerd zonder aanvullende controls.

Hoe los je dit op?

Verwijder marquee elementen. Als scrollende content echt nodig is, bouw het dan met CSS animation met respect voor prefers-reduced-motion en voorzie een pauzeknop.

Hoe controleer je dit?

Zoek in de DOM naar marquee elementen: er horen er geen te zijn.

Wat controleert deze regel?

Interactieve elementen (links, knoppen, inputs) mogen niet genest worden binnen andere interactieve elementen.

Waarom is dit belangrijk?

Een knop binnen een link levert onvoorspelbaar klikgedrag en is voor schermlezer-gebruikers onnavigeerbaar: ze horen de geneste rollen door elkaar.

Hoe los je dit op?

Ontkoppel de interactieve elementen. Gebruik CSS om het visuele effect te bereiken zonder neste interactie.

Code voorbeeld

<a href="/item"><button>Kopen</button></a>

<div class="card">
  <a href="/item">Item naam</a>
  <button>Kopen</button>
</div>

Hoe controleer je dit?

DevTools: document.querySelectorAll('a a, a button, button a, button button') - hoort geen resultaten op te leveren.

Wat controleert deze regel?

Een <li> element hoort binnen een <ul>, <ol> of <menu> te staan.

Waarom is dit belangrijk?

Losse li elementen zijn semantisch betekenisloos en worden door schermlezers niet als lijst aangekondigd.

Hoe los je dit op?

Wikkel li elementen altijd in ul of ol. Als een structuur geen lijst is, gebruik dan een andere tag.

Hoe controleer je dit?

DevTools: Array.from(document.querySelectorAll('li')).filter(l => !['UL','OL','MENU'].includes(l.parentElement?.tagName)).length - hoort 0 te zijn.

Wat controleert deze regel?

Een <ul> of <ol> mag als directe kinderen alleen <li> elementen bevatten (plus script en template).

Waarom is dit belangrijk?

Losse divs of spans binnen ul/ol doorbreken de lijst-semantiek. Schermlezers kondigen de lijstlengte verkeerd aan.

Hoe los je dit op?

Plaats alle content binnen li elementen, ook als het om wrapper-divs gaat.

Code voorbeeld

<ul>
  <div class="wrapper">
    <li>Item</li>
  </div>
</ul>

<ul>
  <li><div class="wrapper">Item</div></li>
</ul>

Hoe controleer je dit?

Inspecteer elke lijst: alle directe kinderen moeten li zijn.

Wat controleert deze regel?

Definition terms (<dt>) en definition descriptions (<dd>) moeten binnen een definition list (<dl>) staan.

Waarom is dit belangrijk?

Losse dt/dd elementen zijn semantisch verbroken en worden niet als definitielijst aangekondigd.

Hoe los je dit op?

Wikkel dt/dd altijd in dl.

Code voorbeeld

<dl>
  <dt>Joomla</dt>
  <dd>Een open-source CMS</dd>
</dl>

Hoe controleer je dit?

Zoek in DOM naar losse dt/dd elementen zonder dl parent.

Wat controleert deze regel?

Een definition list moet een logische volgorde van dt gevolgd door één of meer dd hebben. Of als alternatief, groepering in <div> wrappers.

Waarom is dit belangrijk?

Verkeerde structuur breekt de semantische relatie tussen term en definitie.

Hoe los je dit op?

Zorg voor een correcte structuur: dt, dan dd (eventueel meerdere), dan volgende dt. Geen losse dd zonder voorafgaande dt.

Code voorbeeld

<dl>
  <dt>CMS</dt>
  <dd>Content Management System</dd>
  <dt>SEO</dt>
  <dd>Search Engine Optimization</dd>
</dl>

Hoe controleer je dit?

Inspecteer definition lists op correcte term/description paren.

Wat controleert deze regel?

Het <blink> element is verouderd en werkt in moderne browsers niet meer, maar kan nog in legacy content voorkomen.

Waarom is dit belangrijk?

Blinking content kan epilepsie triggeren en is voor veel gebruikers hinderlijk.

Hoe los je dit op?

Verwijder blink elementen volledig. Als aandachtstrekken gewenst is, gebruik dan subtielere middelen.

Hoe controleer je dit?

Zoek de DOM door op blink elementen: er mogen er geen zijn.

Wat controleert deze regel?

Een th element hoort bijbehorende td cellen te hebben in de tabel. Anders beschrijft de header geen data.

Waarom is dit belangrijk?

Een th zonder bijbehorende data is structureel zinloos en verwarrend voor schermlezer-gebruikers.

Hoe los je dit op?

Zorg dat elke th in een tabel datacellen (td) in dezelfde rij of kolom heeft.

Hoe controleer je dit?

Inspecteer datatabellen: elke header moet data onder zich hebben.

Wat controleert deze regel?

Als een td het headers attribuut gebruikt om naar headers te verwijzen, moeten die headers in dezelfde tabel staan.

Waarom is dit belangrijk?

Een verwijzing naar een header in een andere tabel of naar een niet-bestaand ID is een gebroken relatie.

Hoe los je dit op?

Controleer dat alle waarden in headers attributen overeenkomen met ID's van th elementen binnen dezelfde tabel.

Hoe controleer je dit?

Inspecteer td headers attributen en match ze met th ID's binnen hetzelfde tabel-element.

Wat controleert deze regel?

Een input hoort gekoppeld te zijn aan één label element. Twee labels voor hetzelfde veld veroorzaken onvoorspelbare aankondiging.

Waarom is dit belangrijk?

Schermlezers kondigen meestal alleen het eerste label aan, waardoor informatie in het tweede label verloren gaat.

Hoe los je dit op?

Combineer de tekst in één label. Als je extra tekst wilt koppelen (hint-tekst), gebruik aria-describedby in plaats van een tweede label.

Code voorbeeld

<label for="wachtwoord">Wachtwoord <span class="hint">(minstens 8 tekens)</span></label>
<input type="password" id="wachtwoord">

Hoe controleer je dit?

DevTools: Array.from(document.querySelectorAll('label[for]')).reduce((a,l)=>(a[l.htmlFor]=(a[l.htmlFor]||0)+1,a),{}) - geen ID mag waarde >1 hebben.

Wat controleert deze regel?

Als zowel lang als xml:lang op het html element staan, moeten ze dezelfde taalcode bevatten.

Waarom is dit belangrijk?

Tegenstrijdige taal-attributen kunnen afhankelijk van de user agent verschillend worden geïnterpreteerd.

Hoe los je dit op?

Stel dezelfde waarde in voor beide, of verwijder xml:lang (alleen nodig voor XHTML).

Hoe controleer je dit?

Inspecteer html element: als beide attributen aanwezig zijn, moeten ze identiek zijn.

Wat controleert deze regel?

Enkele ARIA rollen zijn verouderd (bijvoorbeeld role="directory") en moeten niet meer gebruikt worden.

Waarom is dit belangrijk?

Verouderde rollen worden door moderne assistive technology niet meer goed ondersteund.

Hoe los je dit op?

Vervang verouderde rollen door hun moderne equivalenten: role="directory" wordt role="list".

Hoe controleer je dit?

Zoek in DOM naar verouderde role-waarden volgens de actuele ARIA specificatie.

Wat controleert deze regel?

Een <img ismap> (server-side image map) stuurt alleen kliklocaties naar de server. Deze techniek is niet bereikbaar voor schermlezers of toetsenbord-gebruikers.

Waarom is dit belangrijk?

Zonder beschrijvingen kunnen niet-visuele gebruikers de kliklocaties niet identificeren. De techniek is volledig afhankelijk van visuele interactie.

Hoe los je dit op?

Vervang server-side image maps door client-side image maps (<map> met <area alt>) of door echte HTML links op de afbeelding.

Hoe controleer je dit?

Zoek in DOM naar img elementen met het ismap attribuut: er mogen er geen zijn.

Wat controleert deze regel?

De meta viewport mag niet user-scalable=no bevatten, want dat blokkeert de gebruiker om in te zoomen.

Waarom is dit belangrijk?

Mensen met een visuele beperking hebben vaak zoom nodig. Zonder zoom is content onleesbaar voor hen. Dit is een harde WCAG 2.0 AA vereiste onder Succescriterium 1.4.4 (Resize text).

Hoe los je dit op?

Verwijder user-scalable=no uit de viewport meta tag. Verwijder ook maximum-scale als die op 1 staat.

Code voorbeeld

<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">

<meta name="viewport" content="width=device-width, initial-scale=1">

Hoe controleer je dit?

Open de site op mobiel en probeer te zoomen met pinch-gesture. Als het werkt, is het goed.

Wat controleert deze regel?

Elk lang attribuut in het document (niet alleen op html) moet een geldige BCP 47 taalcode bevatten.

Waarom is dit belangrijk?

Schermlezers schakelen tussen taalprofielen op basis van het lang attribuut. Ongeldige codes worden genegeerd en Nederlandse tekst wordt in Engels uitgesproken, wat onverstaanbaar klinkt.

Hoe los je dit op?

Gebruik correcte ISO taalcodes: nl, en, de, fr, nl-BE, en-US, enzovoort. Niet lang="nederlands" of lang="dutch".

Code voorbeeld

<p lang="nederlands">Welkom</p>

<p lang="nl">Welkom</p>

Hoe controleer je dit?

DevTools: Array.from(document.querySelectorAll('[lang]')).map(e => e.lang) - alle waarden moeten geldige taalcodes zijn.

Wat controleert deze regel?

Een meta refresh met een vertraging (bijvoorbeeld <meta http-equiv="refresh" content="30;url=...">) laadt de pagina na tijd automatisch opnieuw.

Waarom is dit belangrijk?

Een automatische refresh onderbreekt gebruikers die traag lezen of door content navigeren. Schermlezer-gebruikers kunnen hierdoor hun positie verliezen.

Hoe los je dit op?

Vervang meta refresh door een gebruikersgestuurde knop ("Vernieuwen"), of biedt de optie om de refresh uit te stellen of uit te schakelen. Server-side HTTP redirects (status 301/302) zijn geen issue.

Code voorbeeld

<meta http-equiv="refresh" content="30;url=/new-page">

Hoe controleer je dit?

Zoek in HTML source naar meta refresh met numerieke vertraging.

Wat controleert deze regel?

Twee of meer links met dezelfde zichtbare tekst of aria-label moeten naar dezelfde bestemming wijzen. Anders is de context onduidelijk.

Waarom is dit belangrijk?

Schermlezer-gebruikers zien een lijst van alle links op een pagina (bijvoorbeeld via Rotor in VoiceOver). Drie keer "Lees meer" zonder context maakt die lijst onbruikbaar.

Hoe los je dit op?

Maak link-teksten uniek en beschrijvend. In plaats van drie "Lees meer" links: "Lees meer over Joomla", "Lees meer over WordPress", enzovoort. Of gebruik aria-label om extra context toe te voegen terwijl de zichtbare tekst kort blijft.

Code voorbeeld

<a href="/joomla">Lees meer</a>
<a href="/wordpress">Lees meer</a>

<a href="/joomla" aria-label="Lees meer over Joomla">Lees meer</a>
<a href="/wordpress" aria-label="Lees meer over WordPress">Lees meer</a>

Hoe controleer je dit?

Activeer de Links-lijst in een schermlezer: dubbele teksten horen naar dezelfde URL te wijzen, of verschillende teksten te hebben.

Wat controleert deze regel?

Het autocomplete attribuut op formuliervelden moet geldige waarden uit de HTML specificatie gebruiken (bijvoorbeeld "email", "given-name", "postal-code").

Waarom is dit belangrijk?

Autocomplete helpt alle gebruikers, maar is essentieel voor mensen met cognitieve of motorische beperkingen die geen lange formulieren handmatig willen invullen. Ongeldige waarden schakelen de browser-autocomplete uit. Dit is onder WCAG 2.1 AA succescriterium 1.3.5 (Identify Input Purpose).

Hoe los je dit op?

Gebruik de standaard autocomplete waarden. Voor gebruikers: "given-name", "family-name", "email", "tel", "street-address", "postal-code", "country". Voor betalingen: "cc-number", "cc-exp". Zie de HTML Living Standard voor de volledige lijst.

Code voorbeeld

<input name="email" autocomplete="yes">

<input name="email" autocomplete="email" type="email">

Hoe controleer je dit?

Browser autocomplete test: begin in te vullen en controleer of de browser suggesties biedt uit eerder opgeslagen gegevens.

Wat controleert deze regel?

Als gebruikers de tekstafstand aanpassen (line-height, letter-spacing, word-spacing, paragraph spacing) mag er geen content verloren gaan of overlappen.

Waarom is dit belangrijk?

Mensen met dyslexie of visuele beperkingen passen vaak tekstafstand aan via browser-extensies om beter te kunnen lezen. Als de site daarvan breekt (tekst valt uit containers, kop wordt niet zichtbaar), is hij onbruikbaar.

Hoe los je dit op?

Vermijd vaste hoogtes en overflow:hidden op tekst-containers. Gebruik min-height in plaats van height. Laat containers meeschalen met de content.

Code voorbeeld

.card { height: 120px; overflow: hidden; }

.card { min-height: 120px; }

Hoe controleer je dit?

Installeer een bookmarklet die line-height, letter-spacing etc. injecteert volgens WCAG 2.1 drempels (line-height 1.5x, letter-spacing 0.12em, etc.) en controleer of de pagina nog werkt.