WCAG 2.4.6: Koppen en labels

Wat Deze Regel Betekent

WCAG 2.4.6 stelt: "Headings and labels describe topic or purpose." In de kern vereist dit criterium dat elke kop (<h1> tot en met <h6>) of label (<label>, aria-label, aria-labelledby) die op een pagina voorkomt, voldoende beschrijvend is om het onderwerp van de inhoud die het inleidt of het doel van de bediening die het identificeert, over te brengen.

Dit criterium vereist niet dat koppen of labels aanwezig zijn — die verplichting wordt gedekt door andere succescriteria zoals 1.3.1 (Info and Relationships) en 2.4.2 (Page Titled). Wat 2.4.6 regelt is de kwaliteit van koppen en labels die al bestaan: als je ze hebt, moeten ze betekenisvol zijn. Een kop met de tekst "Section 1" of een label met de tekst "Field" vertelt gebruikers niets nuttigs over de inhoud die volgt of de invoer die het beschrijft. Vergelijk dit met "Your Shipping Address" of "Monthly Budget Summary", die gebruikers direct oriënteren.

Labels in deze context omvatten niet alleen het HTML-element <label> dat is gekoppeld aan formulierelementen, maar ook elke programmatische labelmechanisme: aria-label, aria-labelledby, het title-attribuut wanneer dit wordt gebruikt als een toegankelijke naam, en het legend-element voor fieldsets. Elk van deze dat wordt blootgesteld aan ondersteunende technologieën moet het doel van de bijbehorende bediening duidelijk beschrijven.

Er is sprake van een fout wanneer een kop of label zo generiek, dubbelzinnig of niet-informerend is dat een gebruiker niet kan bepalen waar de sectie of bediening over gaat zonder de omringende context te lezen. Een formulier met drie invoervelden die allemaal zijn gelabeld met "Enter here" voldoet bijvoorbeeld niet aan dit criterium, net zomin als een pagina die herhaalde koppen zoals "More Info" gebruikt voor elke subsectie. Evenzo is een kop die technisch aanwezig is in de DOM maar de gebruiker volledig misleidt — zoals een contactformuliersectie labelen met een kop die "News and Updates" luidt — ook een fout.

Er is één belangrijke officiële uitzondering: WCAG 2.4.6 is alleen van toepassing wanneer koppen en labels gebruikt worden. Als een pagina legitiem geen koppen heeft (bijvoorbeeld een zeer kort document met één onderwerp) of een formulierelement dat geen zichtbaar of programmatisch label heeft (wat in plaats daarvan door 1.3.1 wordt opgevangen), is 2.4.6 zelf niet van toepassing. De reikwijdte van het criterium gaat strikt over beschrijvendheid, niet over aanwezigheid.

Waarom Het Belangrijk Is

Beschrijvende koppen en labels zijn nuttig voor een opmerkelijk brede doelgroep, maar de impact is het grootst voor mensen met een beperking die afhankelijk zijn van structuur om te navigeren.

Schermlezersgebruikers — voornamelijk mensen die blind zijn of een ernstige visuele beperking hebben — navigeren routinematig door pagina’s door met sneltoetsen van kop naar kop te springen (H in NVDA/JAWS, de Rotor in VoiceOver). Als koppen vaag of misleidend zijn, valt deze navigatiestrategie volledig in duigen. Een blinde gebruiker die op een overheidsportaal terechtkomt dat "Section A", "Section B" en "Section C" als koppen gebruikt, moet elk woord van elke sectie achter elkaar lezen om te vinden wat hij of zij nodig heeft, waardoor het efficiëntievoordeel dat koppen zouden moeten bieden, verdwijnt. Volgens de Wereldgezondheidsorganisatie hebben wereldwijd ongeveer 2.2 miljard mensen een vorm van visuele beperking, wat dit tot een aanzienlijke wereldwijde populatie maakt.

Mensen met cognitieve beperkingen, waaronder mensen met aandachtsstoornissen, geheugenstoornissen of leerstoornissen, zijn sterk afhankelijk van duidelijke, voorspelbare labels en koppen om de cognitieve belasting te verminderen. Wanneer een formulierveld alleen "Name" heet op een pagina die zowel een bedrijfsnaam als de naam van een contactpersoon verzamelt, kan een gebruiker met een cognitieve beperking de dubbelzinnigheid mogelijk niet alleen uit de context oplossen, wat leidt tot fouten en frustratie.

Gebruikers met motorische beperkingen die afhankelijk zijn van switch access, oogvolgsoftware of spraakbesturing (zoals Dragon NaturallySpeaking) profiteren van beschrijvende labels omdat zij een specifiek formulierveld kunnen activeren door de naam van het label uit te spreken. Als meerdere velden dezelfde labeltekst delen, kan spraakbesturingssoftware geen onderscheid maken tussen deze velden, waardoor de gebruiker extra stappen moet nemen die fysiek belastend zijn.

Denk aan een scenario uit de echte wereld: een persoon die een schermlezer gebruikt, bezoekt een afrekenpagina van een e-commerce site. De pagina bevat drie adressecties — factuuradres, verzendadres en een adres van een cadeaugeadresseerde — maar elke sectie gebruikt dezelfde generieke kop "Address" en elke set invoervelden gebruikt dezelfde labels: "Street", "City", "Postal Code". Zonder unieke, beschrijvende koppen en labels kan de schermlezersgebruiker niet bepalen welke groep velden hij of zij invult, wat het risico op bestel fouten drastisch vergroot en de kans vergroot dat de aankoop helemaal wordt afgebroken.

Naast toegankelijkheid bieden beschrijvende koppen aanzienlijke SEO-waarde. Zoekmachines gebruiken de kopstructuur als een sterk signaal om de pagina-inhoud te begrijpen en deze te koppelen aan zoekopdrachten van gebruikers. Betekenisvolle koppen helpen zoekmachines pagina’s nauwkeuriger te indexeren en kunnen de doorklikratio in zoekresultaten verbeteren, waar koppen vaak worden getoond als voorbeeldtekst. Dit brengt zakelijke belangen direct in lijn met toegankelijkheidseisen.

Gerelateerde Axe-core Regels

WCAG 2.4.6 vereist handmatige tests omdat geen enkele geautomatiseerde tool betrouwbaar kan bepalen of een kop of label beschrijvend is. Beschrijvendheid is een semantisch, contextueel oordeel — een kop met de tekst "Products" kan op de ene pagina perfect beschrijvend zijn en op een andere volledig dubbelzinnig. Geautomatiseerde scanners kunnen de aanwezigheid of afwezigheid van koppen en labels detecteren, maar ze kunnen niet beoordelen of de tekst van die koppen en labels betekenisvol is zonder menselijke interpretatie.

• Handmatige beoordeling van koptekst: Axe-core zal ontbrekende koppen of onjuiste nesting markeren (via regels zoals heading-order), maar kan een kop met de tekst "Click Here" of "Untitled Section" niet markeren als een 2.4.6-overtreding. Een menselijke tester moet elke kop geïsoleerd lezen — zoals een schermlezersgebruiker deze zou tegenkomen bij navigatie op koppen — en beoordelen of deze het onderwerp van de onderliggende inhoud communiceert.
• Handmatige beoordeling van formulierlabeltekst: De label-regel van axe-core controleert of elke formulierinvoer een gekoppeld label heeft, maar beoordeelt niet of de tekst van dat label beschrijvend is. Een labelelement dat alleen een placeholder-teken, een pictogramteken of een generiek woord zoals "Input" bevat, zal geautomatiseerde controles doorstaan en toch niet voldoen aan 2.4.6. Handmatige beoordeling vereist dat elk label wordt gelezen en dat wordt bevestigd dat het nauwkeurig het doel van de bijbehorende bediening beschrijft.
• Handmatige beoordeling van aria-label- en aria-labelledby-waarden: Evenzo bevestigt de axe-core aria-label-is-accessible-familie van regels dat ARIA-labels syntactisch geldig zijn en dat verwezen elementen bestaan, maar ze beoordelen niet of de labeltekst semantisch betekenisvol of beschrijvend is voor het doel van de bediening.
• Detectie van dubbele labels: Hoewel sommige tools dubbele labeltekst op een pagina kunnen markeren, kunnen ze niet bepalen of duplicatie opzettelijk en passend is (twee velden met hetzelfde doel in verschillende rijen van een tabel) of een echte fout in beschrijvendheid waarbij meerdere verschillende bedieningen een dubbelzinnig label delen. Handmatige beoordeling is nodig om dit onderscheid te maken.

Hoe te Testen

1. Voer eerst een geautomatiseerde scan uit: Gebruik axe DevTools (browserextensie) of Lighthouse in Chrome DevTools om structurele kop- of labelproblemen te identificeren die geautomatiseerde tools kunnen detecteren, zoals ontbrekende labels, overgeslagen kopniveaus of lege kopelementen. Hoewel dit geen directe 2.4.6-overtredingen zijn, wijzen ze op gebieden die tijdens handmatige beoordeling nauwkeuriger moeten worden onderzocht. Noteer elke kop en gelabelde bediening die in het rapport wordt gemarkeerd of geïdentificeerd.
2. Exporteer de koppenlijst: Gebruik een browserextensie zoals de HeadingsMap-extensie (beschikbaar voor Firefox en Chrome) of de WAVE-tool om een platte lijst van alle koppen op de pagina te genereren, ontdaan van hun omringende inhoud. Lees deze lijst alsof het een inhoudsopgave is. Vraag jezelf af: zou een gebruiker de structuur en de hoofdonderwerpen van deze pagina kunnen begrijpen op basis van alleen de koppen, zonder de hoofdtekst te lezen? Als een kop dubbelzinnig of niet-informerend is wanneer hij geïsoleerd wordt bekeken, is dat een 2.4.6-fout.
3. Test met NVDA en Firefox: Open de pagina en druk op H om van kop naar kop te navigeren. Luister naar elke kopaankondiging en beoordeel of deze de inhoud beschrijft die volgt. Druk vervolgens op F om door formuliervelden te bladeren en luister naar het label dat voor elke invoer wordt aangekondigd. Noteer elke kop of elk label dat het onderwerp of doel niet duidelijk beschrijft.
4. Test met VoiceOver en Safari (macOS/iOS): Gebruik de Web Rotor (VO+U) om de lijst met koppen en de lijst met formulierelementen te openen. Navigeer door elke lijst en beoordeel de beschrijvendheid van elk item onafhankelijk van de paginacontext. Gebruik op iOS een veeg met drie vingers om via de Rotor op koppen te navigeren.
5. Test met JAWS en Chrome: Druk op H om door koppen te navigeren en gebruik de Forms Mode (F) om tussen formulierelementen te bewegen. Gebruik het JAWS List of Headings-dialoogvenster (Insert+F6) om alle koppen in een platte lijst te bekijken, wat nabootst hoe een schermlezersgebruiker de paginastructuur zou scannen.
6. Beoordeel formulierlabels geïsoleerd: Bedek of negeer voor elk formulierelement alle omringende context en lees alleen het programmatische label (zichtbare labeltekst, aria-label of aria-labelledby-doel). Bevestig dat het label op zichzelf voldoende is om te begrijpen welke informatie moet worden ingevoerd of welke actie de bediening uitvoert.
7. Controleer op dubbele kop- of labeltekst: Zoek op de pagina naar herhaalde koptekst (bijvoorbeeld meerdere "Read More"-koppen of meerdere "Learn More"-secties). Als dezelfde tekst wordt gebruikt voor koppen of labels die naar verschillende onderwerpen of bedieningen verwijzen, is dit een fout in 2.4.6.

Hoe te Herstellen

Generieke Sectiekoppen — Onjuist

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Generieke Sectiekoppen — Juist

<!-- Each heading now describes the actual topic of its section,
     enabling screen reader users to jump directly to what they need -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Dubbelzinnige Formulierlabels — Onjuist

<!-- A checkout form with two address blocks, both using identical labels -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

Dubbelzinnige Formulierlabels — Juist

<!-- Legends now distinguish the two fieldsets; labels remain short because
     the legend provides the distinguishing context programmatically -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

Niet-beschrijvend ARIA-label op Pictogramknop — Onjuist

<!-- aria-label provides a label but it does not describe the button's purpose -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Niet-beschrijvend ARIA-label op Pictogramknop — Juist

<!-- aria-label now clearly communicates what activating the button will do -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Herhaalde "Read More"-Koppen of Links — Onjuist

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Herhaalde "Read More"-Koppen of Links — Juist

<!-- Each article has a unique, descriptive heading that identifies its topic -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Veelvoorkomende Fouten

• Gebruik van positionele of ordinale koppen zoals "Step 1", "Step 2", "Section A" zonder beschrijvende tekst: deze koppen vertellen de gebruiker alleen waar hij of zij zich in een reeks bevindt, niet waar de sectie over gaat. Combineer volgorde-aanduidingen altijd met een beschrijvende zelfstandignaamwoordgroep, bijvoorbeeld "Step 2: Verify Your Email Address".
• Alle kaart- of artikelcomponenten op een overzichtspagina dezelfde koptekst geven (bijvoorbeeld elke productkaart heeft een <h3> met alleen "Product"): elke kaartkop moet dat specifieke product, blogbericht of item uniek identificeren.
• Placeholdertekst gebruiken als het toegankelijke label voor een formulierinvoer (vertrouwen op het placeholder-attribuut in plaats van een <label>-element of aria-label): placeholders verdwijnen bij invoer en worden niet door alle schermlezers betrouwbaar aangekondigd als toegankelijke namen. Zelfs wanneer een placeholder bestaat, is een apart beschrijvend label vereist.
• Een aria-label schrijven dat alleen het elementtype herhaalt in plaats van het doel, zoals aria-label='input' op een tekstveld of aria-label='button' op een knop: het label moet beschrijven wat de bediening doet of welke waarde deze verzamelt, niet wat voor soort element het is.
• Tooltiptekst of title-attributen gebruiken als het enige label voor een formulierelement en aannemen dat dit voldoet aan 2.4.6: op title gebaseerde labels zijn vaak ontoegankelijk voor gebruikers die alleen het toetsenbord gebruiken en worden niet consistent aangekondigd door schermlezers. Vertrouw in plaats daarvan op zichtbare <label>-elementen of aria-label.
• Zoekvelden alleen labelen met "Search" op een pagina waar meerdere zoekbereiken bestaan (bijvoorbeeld sitebrede zoekfunctie en een zoekfunctie binnen een datatabel): wanneer twee bedieningen verschillende zoekopdrachten uitvoeren, moet elk label het bereik specificeren, zoals "Search all products" en "Search within order history".
• Dezelfde koptekst toepassen op de kop van een modaal dialoogvenster als op de hoofdkop van de pagina: modale koppen moeten de specifieke taak of inhoud van het dialoogvenster beschrijven (bijvoorbeeld "Confirm Your Cancellation") in plaats van de paginatitel over te nemen, wat verwarrend zou zijn voor schermlezersgebruikers die binnen het dialoogvenster navigeren.
• Een beschrijvende <legend> voor groepen keuzerondjes of selectievakjes weglaten terwijl individuele optie-labels worden gegeven: de <legend> biedt essentiële context die elk individueel label betekenisvol maakt. "Yes" en "No" als op zichzelf staande optie-labels zijn niet-informerend zonder een legend zoals "Do you agree to the terms and conditions?".
• Koptekst in de DOM inkorten om visuele ontwerpredenen (bijvoorbeeld een kop die alleen een pictogram of één woord bevat omdat de volledige tekst in aangrenzende visuele elementen staat): de programmatische kop moet volledig beschrijvend zijn omdat schermlezersgebruikers deze horen zonder de omringende visuele lay-out te zien.
• Aannemen dat een label, omdat het zichtbaar is voor ziende gebruikers, daarom voor alle gebruikers voldoende beschrijvend is: een label dat afhankelijk is van ruimtelijke positie (bijvoorbeeld een kolomkop in een aangepast raster waarbij de betekenis van het label afhangt van de relatie met omringende cellen) kan visueel duidelijk zijn maar er niet in slagen dezelfde informatie programmatisch over te brengen. Controleer altijd of de toegankelijke naam op zichzelf voldoende is.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt verplichte digitale toegankelijkheidsverplichtingen vast voor een breed scala aan publieke en private entiteiten die in Turkije actief zijn. De circulaire verwijst expliciet naar WCAG 2.1 Level AA als de technische standaard voor conformiteit, en Level AA-vereisten onder WCAG 2.2 — dat achterwaarts compatibel is met WCAG 2.1 op AA-niveau — worden sterk aangemoedigd en zijn vereist voor entiteiten die het officiële Accessibility Logo (Erişilebilirlik Logosu) willen verkrijgen dat wordt uitgegeven door het Ministerie van Gezin en Sociale Diensten (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.4.6 is een Level AA-criterium, wat betekent dat het volledig binnen de reikwijdte valt van wat betrokken entiteiten moeten aanpakken om volledige conformiteit te bereiken. De volgende typen entiteiten vallen onder de Presidential Circular: overheidsinstellingen en -agentschappen; e-commerceplatforms; banken en financiële instellingen; ziekenhuizen en zorgaanbieders; telecomoperators met 200,000 of meer abonnees; reisbureaus; particuliere vervoersbedrijven; en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (Millî Eğitim Bakanlığı).

Voor deze entiteiten brengt het niet bieden van beschrijvende koppen en labels concreet regelgevingsrisico met zich mee. Een overheidsportaal met vage sectiekoppen belemmert burgers met een beperking in de toegang tot openbare diensten, wat rechtstreeks in strijd is met het in de circulaire genoemde doel om gelijke toegang te waarborgen. Een e-commercesite met dubbelzinnige formulierlabels in de afrekenstroom kan voorkomen dat gebruikers met visuele of cognitieve beperkingen aankopen afronden, wat een belemmering vormt voor economische participatie die de circulaire juist wil wegnemen.

Entiteiten die de Erişilebilirlik Logosu willen verkrijgen, moeten conformiteit aantonen via een toegankelijkheidsaudit, en 2.4.6 is een van de criteria die auditors handmatig zullen beoordelen. Omdat dit criterium menselijke beoordeling vereist — geautomatiseerde tools kunnen beschrijvendheid niet beoordelen — moeten organisaties een gestructureerde handmatige beoordeling van alle koppen en formulierlabels opnemen als standaardonderdeel van hun toegankelijkheidsauditproces. Deze beoordeling inbouwen in contentbeheerworkflows en designsystemen, in plaats van deze te behandelen als een eenmalige audittaak, is de meest effectieve strategie om voortdurende naleving te behouden naarmate de inhoud in de loop van de tijd verandert.