Sectie 1 · Hoofdstuk 9
Markup-validiteit
Valide HTML voorkomt dat hulpsoftware je pagina verkeerd interpreteert.
Waarom valide HTML ertoe doet
HTML is de taal die hulpsoftware leest. Als die taal fouten bevat – ontbrekende tags, dubbele ID’s, verkeerd geneste elementen – dan moet de browser gokken wat je bedoelt. Browsers zijn daar inmiddels goed in, maar hulpsoftware niet altijd.
WCAG succescriterium 4.1.1 (Parsing) stelde oorspronkelijk vier eisen aan HTML:
- Elementen hebben volledige begin- en eindtags
- Elementen zijn correct genest
- Elementen bevatten geen dubbele attributen
- ID’s zijn uniek binnen de pagina
SC 4.1.1 is afgeschaft – maar de principes niet
In WCAG 2.2 is SC 4.1.1 afgeschaft (deprecated). De reden: moderne browsers parsen HTML inmiddels zo consistent dat de meeste fouten geen problemen meer veroorzaken. Een ontbrekende </p>-tag? De browser fixt dat automatisch.
Maar dat betekent niet dat valide HTML onbelangrijk is. De problemen die er echt toe doen – dubbele ID’s, verkeerde nesting van interactieve elementen – vallen nu onder andere succescriteria zoals 1.3.1 en 4.1.2. De technische eis is weg, maar de impact op toegankelijkheid is gebleven.
WCAG 2.1 vs. 2.2
Als je auditeert tegen WCAG 2.1 (bijvoorbeeld voor het BDTO), dan is SC 4.1.1 nog van toepassing. Bij WCAG 2.2 is het afgeschaft, maar de fouten die het criterium beschreef zijn nog steeds relevant – ze vallen alleen onder andere criteria.
Dubbele ID’s: het meest voorkomende probleem
Van alle validatiefouten zijn dubbele ID’s het meest impactvol voor toegankelijkheid. Een ID moet uniek zijn binnen een pagina. Als twee elementen hetzelfde ID hebben, breekt er van alles:
- Een
<label for="email">koppelt aan het eerste element metid="email"– het tweede formulierveld krijgt geen label - Een skiplink naar
#main-contentspringt altijd naar het eerste element met dat ID aria-labelledbyenaria-describedbyverwijzen naar het verkeerde element- JavaScript met
getElementById()vindt alleen het eerste element
Fout
<label for="naam">Naam bezorgadres</label>
<input type="text" id="naam" />
<label for="naam">Naam factuuradres</label>
<input type="text" id="naam" />
Beide labels koppelen aan het eerste invoerveld. Het tweede veld heeft effectief geen label.
Goed
<label for="naam-bezorg">Naam bezorgadres</label>
<input type="text" id="naam-bezorg" />
<label for="naam-factuur">Naam factuuradres</label>
<input type="text" id="naam-factuur" />
Unieke ID’s zorgen dat elk label aan het juiste veld gekoppeld is.
Waar komen dubbele ID's vandaan?
In de praktijk ontstaan dubbele ID’s vaak door hergebruikte componenten. Een “contactformulier”-component die twee keer op dezelfde pagina staat, levert dubbele ID’s op als de ID’s niet dynamisch worden gegenereerd. Check dit bij hergebruikte templates en componenten.
Verkeerde nesting
HTML heeft regels voor welke elementen in welke andere elementen mogen staan. De belangrijkste regel voor toegankelijkheid: plaats geen interactief element in een ander interactief element.
Fout
<button>
<a href="/producten">Bekijk producten</a>
</button>
Een <a> in een <button> is ongeldig. De browser moet kiezen welk interactief element voorrang krijgt. Het resultaat verschilt per browser en per schermlezer.
Goed
<a href="/producten">Bekijk producten</a>
Kies een element. Navigeert het ergens naartoe? Gebruik een link. Voert het een actie uit? Gebruik een knop.
Fout
<span>
<div>Dit is een alinea</div>
</span>
Een <div> (blokelement) hoort niet in een <span> (inline element). De browser sluit de <span> impliciet, wat leidt tot een onverwachte DOM-structuur.
Goed
<div>
<p>Dit is een alinea</p>
</div>
Blokelementen bevatten andere blokelementen of inline elementen, niet andersom.
Ontbrekende tags
Ontbrekende begin- of eindtags zijn meestal cosmetische fouten die browsers goed afhandelen. Maar soms leidt een ontbrekende tag tot een onverwachte DOM-structuur.
Fout
<ul>
<li>Item 1
<li>Item 2
<li>Item 3
</ul>
Werkt in de praktijk – browsers sluiten de <li> impliciet. Maar het is slordig en kan verwarrend zijn bij complexere structuren.
Goed
<ul>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ul>
Expliciete eindtags maken de structuur ondubbelzinnig.
De W3C-validator
De W3C Markup Validation Service controleert je HTML op fouten. Je kunt een URL invoeren, een bestand uploaden of HTML direct plakken.
Niet elke fout die de validator meldt is een toegankelijkheidsprobleem. Focus op deze categorieën:
| Fouttype | Impact op toegankelijkheid |
|---|---|
| Dubbele ID’s | Hoog – breekt labels, skiplinks en ARIA-verwijzingen |
| Interactieve elementen in interactieve elementen | Hoog – onvoorspelbaar gedrag in hulpsoftware |
| Ontbrekende verplichte attributen | Gemiddeld – afhankelijk van het element |
| Ontbrekende eindtags | Laag – browsers herstellen dit meestal correct |
| Verouderde attributen | Laag – geen directe impact op toegankelijkheid |
Pragmatisch valideren
Je hoeft niet elke validatiefout op te lossen. Richt je op fouten die hulpsoftware in de war brengen: dubbele ID’s, verkeerde nesting van interactieve elementen, en ontbrekende attributen die de naam of rol van een element bepalen. Een waarschuwing over een verouderd attribuut is geen toegankelijkheidsprobleem.
WCAG-succescriteria
| Succescriterium | Niveau | Toelichting |
|---|---|---|
| 4.1.1 Parsing | A | Afgeschaft in WCAG 2.2, maar nog geldig in WCAG 2.1. Vraagt om volledige tags, correcte nesting, geen dubbele attributen en unieke ID’s. |
| 1.3.1 Informatie en relaties | A | Dubbele ID’s en verkeerde nesting kunnen ertoe leiden dat structuur niet correct wordt overgebracht |
| 4.1.2 Naam, Rol, Waarde | A | Een dubbel ID kan ertoe leiden dat een label of ARIA-verwijzing aan het verkeerde element koppelt |