WCAG 3.3.2: Labels of instructies

Wat Deze Regel Betekent

WCAG Succescriterium 3.3.2 — Labels of Instructies (Niveau A) stelt: "Labels of instructies worden verstrekt wanneer content gebruikersinvoer vereist." In praktische termen betekent dit dat elk formulierveld, invoercontrole, tekstgebied en select-element dat een gebruiker vraagt om informatie in te voeren of te selecteren, een zichtbaar, betekenisvol label of een set instructies moet hebben die het doel van het veld duidelijk maakt voordat de gebruiker ermee interacteert.

Het criterium is bewust ruim geformuleerd. Het dekt elk mechanisme waarmee een gebruiker gegevens verstrekt: <input>-elementen van alle typen (text, email, password, number, date, checkbox, radio, file upload), <textarea>-elementen voor meerregelige tekst en <select>-dropdowns. Het is ook van toepassing op aangepaste interactieve controles die zijn gebouwd met ARIA-rollen zoals role='combobox' of role='listbox'.

Een label kan op verschillende manieren worden verstrekt die aan dit criterium voldoen. De meest robuuste manier is een programmatisch geassocieerd <label>-element dat visueel aanwezig is en gekoppeld is aan de controle via een overeenkomend for/id-paar. Als alternatief kan een zichtbaar labeltekst worden geassocieerd met behulp van aria-labelledby dat verwijst naar een bestaand element, of kunnen aanvullende instructies worden gekoppeld met aria-describedby. De belangrijkste vereiste is dat het label of de instructie wordt verstrekt — het moet in een vorm bestaan die de gebruiker kan waarnemen. Alleen placeholdertekst voldoet niet aan dit criterium, omdat deze verdwijnt zodra de gebruiker begint te typen en niet door alle ondersteunende technologieën betrouwbaar wordt overgebracht als een persistent label.

Een pass vereist dat elke invoer een label heeft dat zichtbaar is (of minimaal programmatisch bepaalbaar), aanwezig is voordat de gebruiker zich commit aan het invullen van het veld, en voldoende beschrijvend is om duidelijk te maken welke gegevens worden verwacht. Een fail treedt op wanneer een veld helemaal geen label heeft, wanneer het enige label een placeholder-attribuut is, wanneer het label visueel aanwezig is maar niet programmatisch is geassocieerd, of wanneer instructies over het vereiste formaat (bijv. "Voer datum in als DD/MM/JJJJ") volledig ontbreken.

WCAG vermeldt een beperkte uitzondering: wanneer een formulier één enkel, duidelijk veld bevat — zoals een sitebrede zoekbalk met een duidelijk gelabelde verzendknop direct ernaast — kan de context zelf voldoende instructie bieden. Deze uitzondering is echter beperkt en mag niet worden gebruikt als algemene rechtvaardiging om labels weg te laten bij formulieren met meerdere velden.

Waarom Het Belangrijk Is

Formulierlabels zijn de meest impactvolle toegankelijkheidsfunctie voor een brede groep gebruikers. Hun afwezigheid creëert barrières die het voor veel mensen onmogelijk kunnen maken om transacties te voltooien, zich te registreren voor diensten of contact op te nemen met een organisatie.

Voor blinde en slechtziende gebruikers die afhankelijk zijn van schermlezers, wordt een veld zonder label simpelweg aangekondigd als "edit text" of "blank" zonder context. De gebruiker heeft geen manier om te weten of hij zijn naam, e-mailadres of creditcardnummer moet invoeren. Volgens de Wereldgezondheidsorganisatie hebben wereldwijd ongeveer 2,2 miljard mensen een vorm van visuele beperking, en miljoenen van hen gebruiken schermlezers als hun primaire middel om met het web te communiceren.

Voor gebruikers met cognitieve en leerstoornissen — waaronder dyslexie, ADHD en geheugen gerelateerde aandoeningen — is placeholdertekst bijzonder schadelijk. Omdat placeholders verdwijnen bij focus of invoer, heeft een gebruiker die midden in een formulier pauzeert geen referentie meer voor wat er werd verwacht in een veld dat hij al is begonnen in te vullen. Dit dwingt hen om het veld te wissen om de instructie opnieuw te lezen, wat verwarring en frustratie veroorzaakt. Persistente, zichtbare labels nemen deze cognitieve belasting volledig weg.

Voor motorisch beperkte gebruikers die navigeren met toetsenbord, schakelapparaat of spraakbesturing, vervullen labels een extra functie: ze leveren de gesproken woorden die worden gebruikt om een veld te activeren via spraakbesturingssoftware zoals Dragon NaturallySpeaking. Als de zichtbare labeltekst niet overeenkomt met de programmatische toegankelijke naam, faalt het spraakcommando zonder zichtbare fout.

Beschouw een concreet scenario uit de echte wereld: een gebruiker met een visuele beperking vraagt een overheidsuitkering aan op het portaal van een Turkse publieke instelling. Het formulier gebruikt placeholdertekst in plaats van labels. Wanneer de gebruiker tot 200% inzoomt om het scherm te kunnen lezen, verdwijnen de placeholders voordat ze gelezen kunnen worden. De gebruiker vult de velden op basis van gokken in en verstuurt een formulier met fouten, om vervolgens een generieke foutmelding te ontvangen zonder aanwijzing welke velden onjuist zijn. Dit scenario resulteert in uitsluiting van een cruciale publieke dienst — en is volledig te voorkomen.

Naast toegankelijkheid verbeteren gelabelde formulieren de SEO omdat zoekmachinecrawlers het doel van formulieren beter kunnen begrijpen, en ze verbeteren de bruikbaarheid voor alle gebruikers, inclusief gebruikers op mobiele apparaten, waar kleine aanraakdoelen profiteren van aanklikbare labelgebieden die de activatiezone van de bijbehorende invoer vergroten.

Gerelateerde Axe-core Regels

• label — Deze regel controleert of elk <input>-element (behalve die met type='hidden', type='image', type='button', type='submit' en type='reset'), elke <textarea> en elke <select> een toegankelijke naam heeft. De regel markeert elementen die geen geassocieerd <label>, een aria-label-attribuut, een aria-labelledby-verwijzing of een title-attribuut hebben. Dit is het primaire geautomatiseerde signaal voor 3.3.2-overtredingen bij standaard formuliercontroles.
• select-name — Deze regel richt zich specifiek op <select>-dropdown-elementen en controleert of ze een niet-lege toegankelijke naam hebben. Ontwikkelaars gaan er soms van uit dat de opties van een dropdown het doel ervan vanzelfsprekend maken, maar zonder label horen schermlezergebruikers alleen de momenteel geselecteerde optie — die een generieke standaardwaarde kan zijn zoals "Select one" — zonder enige aanwijzing van welke categorie ze kiezen. Axe markeert <select>-elementen die een van de standaard labelmechanismen missen.
• textarea-label — Deze regel controleert <textarea>-elementen op een toegankelijke naam. Meerregelige tekstgebieden worden vaak gebruikt voor opmerkingen, berichten of gedetailleerde invoer, maar blijven vaak ongelabeld onder de onjuiste aanname dat de omringende context voldoende is. Axe markeert elke <textarea> die niet programmatisch kan worden geassocieerd met een label via <label for>, aria-label, aria-labelledby of title.

Het is belangrijk om de grenzen van geautomatiseerd testen voor dit criterium te begrijpen. Axe-core kan de afwezigheid van een programmatisch label detecteren, maar kan niet bepalen of een label dat aanwezig is daadwerkelijk betekenisvol of accuraat is. Een veld met het label "Field 1" of een label dat simpelweg "*" weergeeft, zal geautomatiseerde controles doorstaan terwijl het gebruikers volledig in de steek laat. Handmatige beoordeling is altijd nodig om te bevestigen dat labels de verwachte invoer duidelijk beschrijven, dat formaat-instructies aanwezig zijn waar nodig (bijv. datumformaten, wachtwoordvereisten) en dat verplichte velden worden geïdentificeerd — idealiter zowel visueel als programmatisch.

Hoe te Testen

1. Geautomatiseerde scan met axe DevTools of Lighthouse: Open de pagina met het formulier in Chrome of Firefox. Voer de axe DevTools browserextensie uit en filter de resultaten op de regels label, select-name en textarea-label. Noteer elk gemarkeerd element. Voer Google Lighthouse (Accessibility audit) uit als secundaire controle. Exporteer of maak schermafbeeldingen van alle overtredingen. Onthoud dat een schoon geautomatiseerd rapport geen naleving garandeert — ga door met de handmatige stappen.
2. Visuele inspectie: Zonder gebruik van ondersteunende technologie, bekijk elk formulierveld op de pagina. Bevestig dat elk veld een zichtbaar, statisch label heeft — niet alleen een placeholder — dat duidelijk in de buurt van het veld is gepositioneerd (meestal erboven of links ervan). Bevestig dat formaatvereisten (bijv. "Wachtwoord moet minimaal 8 tekens zijn") worden getoond vóór of op het moment van invoer, niet pas na een mislukte verzending. Bevestig dat verplichte velden worden geïdentificeerd door meer dan alleen kleur.
3. Toetsenbordnavigatietest: Doorloop elk formulierveld met de Tab-toets. Zorg ervoor dat zodra een veld focus krijgt, het doel ervan onmiddellijk duidelijk is aan de hand van het zichtbare label. Geen enkel veld mag met het toetsenbord bereikbaar zijn zonder dat er op dat moment een aangrenzend, persistent label zichtbaar is.
4. Schermlezertest met NVDA en Firefox: Open het formulier terwijl NVDA actief is. Druk op Tab om door elke interactieve controle te gaan. NVDA moet het label, de rol (bijv. "edit", "combo box") en eventuele status (bijv. "required") aankondigen. Als NVDA alleen de rol en status zonder label aankondigt, faalt het veld. Gebruik de formuliermodus van NVDA (automatisch geactiveerd op interactieve elementen) om realistische gebruikersnavigatie te simuleren.
5. Schermlezertest met VoiceOver en Safari (macOS/iOS): Schakel VoiceOver in (Command + F5 op Mac). Gebruik Tab of veegbewegingen om naar elk formulierveld te navigeren. VoiceOver moet het label aankondigen vóór de rol. Tik op iOS op elk veld en bevestig dat het label wordt voorgelezen voordat het toetsenbord verschijnt. Velden met alleen een placeholder worden bij eerste focus meestal als de placeholder voorgelezen, maar worden stil zodra tekst is ingevoerd.
6. Schermlezertest met JAWS en Chrome: Open JAWS en navigeer door het formulier met Tab. Gebruik de Forms Mode van JAWS. Bevestig dat de aangekondigde naam van elk veld exact overeenkomt met het zichtbare label. Gebruik Insert + F1 (field help) van JAWS om te controleren op aanvullende beschrijvingen via aria-describedby.
7. Spraakbesturingstest met Dragon NaturallySpeaking: Activeer Dragon en probeer met elk veld te communiceren door het zichtbare label uit te spreken. Als het uitgesproken label niet overeenkomt met de programmatische toegankelijke naam, reageert het veld niet op het spraakcommando, wat wijst op een mismatch die zowel 3.3.2 als gerelateerde criteria schendt.

Hoe te Herstellen

Ontbrekend label bij een tekstinvoer — Onjuist

<!-- No label provided; placeholder is the only hint -->
<input type='text' name='email' placeholder='Email address' />

Ontbrekend label bij een tekstinvoer — Juist

<!-- Visible <label> associated via matching for/id attributes.
     Placeholder may still be used as supplementary hint,
     but the label is the primary, persistent identifier. -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

Ongelabelde select-dropdown — Onjuist

<!-- No label; screen readers will only announce the selected option value -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Ongelabelde select-dropdown — Juist

<!-- Programmatically associated label makes the field's purpose clear
     before the user opens the dropdown. -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Textarea zonder label — Onjuist

<!-- The textarea has no label; surrounding paragraph text is not
     programmatically associated and will not be read by screen readers
     as the field's label. -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

Textarea zonder label — Juist

<!-- Using aria-labelledby to associate the existing visible heading
     with the textarea, or alternatively wrapping with a <label> element. -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

Formaatinstructies ontbreken bij een datumveld — Onjuist

<!-- Label present but no instruction about expected date format;
     users must guess whether to enter 01/06/2025 or 2025-06-01. -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

Formaatinstructies aanwezig bij een datumveld — Juist

<!-- Format instruction is visible and linked via aria-describedby
     so screen readers announce it when the field receives focus. -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

Veelvoorkomende Fouten

• placeholder gebruiken als het enige label: Placeholdertekst verdwijnt bij invoer, wordt niet door alle schermlezers betrouwbaar als label aangekondigd en faalt voor gebruikers met cognitieve beperkingen die persistente referentietekst nodig hebben. Voorzie altijd een zichtbaar <label> naast elke placeholder.
• Een label visueel in de buurt van een veld plaatsen zonder programmatische associatie: Een <p> of <span> dat visueel boven een invoer is geplaatst, ziet er voor ziende gebruikers uit als een label, maar wordt door schermlezers genegeerd. Gebruik <label for='id'>, aria-labelledby of wikkel de invoer in een <label>-element.
• aria-label gebruiken met tekst die niet overeenkomt met het zichtbare label: Wanneer de programmatische toegankelijke naam verschilt van de zichtbare tekst, kunnen gebruikers van spraakbesturing het veld niet activeren door uit te spreken wat ze op het scherm lezen, wat SC 2.5.3 (Label in Name) schendt en verwarring veroorzaakt voor schermlezergebruikers.
• Een groep keuzerondjes labelen maar de groepslegenda weglaten: Individuele keuzerondjes kunnen elk worden gelabeld met hun optie-tekst, maar als de overkoepelende vraag (bijv. "Payment method") niet wordt verstrekt via een <fieldset> en <legend>, horen gebruikers die met het toetsenbord navigeren elke optie geïsoleerd, zonder te begrijpen waaruit ze kiezen.
• Verplichte velden alleen met kleur of een asterisk identificeren zonder uitleg: Een asterisk (*) naast een label zegt schermlezergebruikers niets, tenzij de betekenis ervan wordt uitgelegd (bijv. een opmerking bovenaan het formulier met "Fields marked with * are required") en verplichte velden ook het attribuut required of aria-required='true' hebben.
• Formaatinstructies pas na een mislukte verzending tonen: Wachtwoordregels of datumformaatvereisten alleen in foutmeldingen na verzending tonen, dwingt gebruikers om eerst een fout te maken voordat ze leren wat er wordt verwacht. Instructies moeten aanwezig zijn vóór of op het moment dat de gebruiker met het veld interacteert.
• Labels verbergen met display:none of visibility:hidden: Deze CSS-eigenschappen verwijderen labels volledig uit de toegankelijkheidsboom. Als een label visueel verborgen moet worden (bijv. voor een minimalistisch ontwerp), gebruik dan een visueel-verborgen CSS-klasse die het element in de toegankelijkheidsboom houdt terwijl het buiten het scherm wordt geplaatst.
• Het title-attribuut als enig label gebruiken en aannemen dat dit voldoende is: Hoewel axe-core een label dat alleen uit title bestaat mogelijk niet markeert, verschijnt het title-attribuut alleen als tooltip bij hover en is het niet toegankelijk voor toetsenbordgebruikers en mobiele gebruikers. Het moet worden gebruikt als aanvullende beschrijving, niet als primair label.
• Eén aria-label toepassen op een container-<div> en verwachten dat dit de kind-invoervelden labelt: ARIA-labels op containerelementen worden niet geërfd door hun onderliggende formuliercontroles. Elke interactieve controle moet afzonderlijk worden gelabeld.
• Labels niet opnieuw associëren na dynamische contentupdates: Wanneer formuliervelden dynamisch via JavaScript worden ingevoegd (bijv. een adresrij toevoegen), missen nieuw ingevoegde invoervelden vaak geassocieerde labels omdat de ontwikkelaar alleen de zichtbare labeltekst als sibling-element heeft toegevoegd zonder de juiste for/id-koppeling.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt verplichte webtoegankelijkheidseisen vast die zijn afgestemd op WCAG 2.2. WCAG Succescriterium 3.3.2 — Labels of Instructies is een Niveau A-vereiste, wat betekent dat het tot de basis van conformiteit behoort en een van de strengst gehandhaafde bepalingen onder de circulaire is.

De circulaire bestrijkt een breed scala aan entiteitstypen en de nalevingstermijnen verschillen per sector. Publieke instellingen — waaronder ministeries, gemeenten, overheidsinstanties en publiek gefinancierde organisaties — moeten binnen één jaar na publicatie van de circulaire volledige Niveau A-conformiteit bereiken. Entiteiten in de private sector binnen de reikwijdte moeten binnen twee jaar voldoen. De entiteiten in de private sector die expliciet worden genoemd, omvatten e-commerceplatforms, banken en financiële instellingen, ziekenhuizen en particuliere zorgaanbieders, telecombedrijven met 200,000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministry of National Education (MoNE).

Voor al deze entiteiten is het niet labelen van formuliervelden niet slechts een tekortkoming in bruikbaarheid — het vormt een directe niet-naleving van de regelgeving. Formulieren zijn alomtegenwoordig in alle gedekte digitale diensten: burgers dienen aanvragen in op overheidsportalen, patiënten maken afspraken op ziekenhuiswebsites, klanten ronden aankopen af op e-commerceplatforms en studenten schrijven zich in via schoolportalen. Elk van deze trajecten is afhankelijk van formulieren, en elk ongelabeld veld in die formulieren is een aantoonbare WCAG 3.3.2-overtreding die auditors kunnen documenteren en rapporteren.

Organisaties die onder de circulaire vallen, moeten naleving van SC 3.3.2 behandelen als een voorwaarde voor elk toegankelijkheidsaudit- of certificeringsproces. Omdat dit een Niveau A-criterium is, kan het niet worden kwijtgescholden of uitgesteld — claims van gedeeltelijke conformiteit die Niveau A-items uitsluiten, worden niet erkend. Entiteiten die geen gelabelde invoervelden in al hun publiek toegankelijke formulieren kunnen aantonen, lopen het risico op bevindingen van toezichthouders, publieke rapportage van niet-naleving en reputatieschade in een markt waar digitaal vertrouwen steeds meer is gekoppeld aan inclusief ontwerp.

Vanuit praktisch oogpunt is het bereiken van 3.3.2-conformiteit een van de stappen met de laagste inspanning en de hoogste impact die een organisatie kan nemen. Labels koppelen aan bestaande formuliercontroles vereist doorgaans slechts kleine HTML-wijzigingen en heeft geen effect op het visuele ontwerp wanneer het correct wordt geïmplementeerd. Voor organisaties die de overlay-SDK van Accsible gebruiken, kan geautomatiseerde detectie van ontbrekende labels deze overtredingen aan het licht brengen tijdens routinematige scans, waardoor ontwikkelteams bruikbare herstelrichtlijnen krijgen voordat de wettelijke deadlines verstrijken.