Webrichtlijn 83: Invoervelden en labels
Op het Fronteers blog schreef ik in 2008 en 2009 korte artikelen over de Webrichtlijnen, die toen door de Nederlandse overheid in het leven zijn geroepen. De reacties zijn bij Fronteers niet meer zichtbaar, dus ik heb ze op mijn eigen site in augustus 2026 weer gepubliceerd.
Gebruik het label element om tekst expliciet met een invoerveld in een formulier te associëren. (R-pd.13.1)
Deze richtlijn kun je op drie manieren naleven:
<!-- Mogelijkheid 1: -->
<label>
Uw naam:
<input type="text" name="naam">
</label>
<!-- Mogelijkheid 2: -->
<label for="naam">Uw naam:</label>
<input type="text" name="naam" id="naam">
<!-- Mogelijkheid 3: -->
<label for="naam">
Uw naam:
<input type="text" name="naam" id="naam">
</label>In het tweede geval heb je een for="" en id="" paartje nodig. Welke manier heeft jouw voorkeur? Waarom?
Hoe ver ga je met labels in het volgende voorbeeld:
En hack je in het volgende voorbeeld met positioning, of gebruik je gewoon 2 labels, ondanks de problemen:
Hoe vaak kom je nog tegen dat een checkbox of een radio button niet geassocieerd is met een tekstlabel? Erger je je dan ook zo enorm?
Comments
Voorkeur gaat uit naar de eerste variant met een
<span></span>om de label tekst.<label>s als block tonen,<span>s floaten of juist als block tonen voor positioneren van labels t.o.v. invoervelden.:beforeen:afterpseudo classes werken goed voor het toevoegen van extraatjes als 'uur' en de euro tekens. Niet in IE6 maar goed, da's progressive enhancement toch?Foutmeldingen zijn interessant... Een lijstje bovenin het
<form>met links naar de labels met de foute velden kan je er met javascript op alle mogelijke manieren laten uitzien.De eerste versie met inderdaad een span om de labeltekst. Ik zet in die span dan nog een
<b>met een * er in als er iets verplicht is. Na de input plaats ik dan nog eventueel een<i>met de foutmelding of instructie. Op deze manier kan je met floaten en positioneren zo ongeveer elke layout bouwen.Als er meer dan één input in een label staan (postcode bijvoorbeeld) dan werkt een label helaas niet. Iets met bubbling.
Ik vind persoonlijk dat postcodes prima in 1 veld kunnen. Serverside / clientside is er genoeg mogelijk om dit te valideren.
Helemaal met je eens, uiteraard. Wist even geen beter voorbeeld te geven en het is in elk geval duidelijk wat ik bedoel (-:
Dit artikeltje http://green-beast.com/blog/?p=254 heeft mij er toe gebracht standaard methode 2 te gebruiken. Naar verluidt heeft Window Eyes moeite met de eerste methode.
Voor zover ik weet, hebben we helemaal niet de keuze tussen mogelijkheid 1 en 2. Webrichtlijnen.nl vermeldt weliswaar beide methodes, maar schrijft daaronder: "De webontwikkelaar moet erop letten dat het tekstlabel alleen met het invoerveld geassocieerd kan worden door het gebruik van het for attribuut op de <label> tag." Bovendien bevat de richtlijn het woord "expliciet". Methode 1 is niet een expliciete, maar een impliciete associatie tussen de velden.
Deze interpretatie is overigens niet mijn eigen verzinsel; toen ik een tijd geleden een site door Bartiméus moest laten testen (ik had methode 1 gebruikt) werd de site op dit punt afgekeurd.
@Marc (reactie #6):
Heb je de precieze argumentatie van Accessibility beschikbaar?
Voor inspectie-instellingen is het normdocument (http://www.drempelvrij.nl/webrichtlijnen) de referentie. Het gaat in dit geval om checkpoint 12.4: "Associate labels explicitly with their controls". Naar mijn mening is het standpunt van Accessibility op dit punt gebaseerd op een te strikte interpretatie: een stuk tekst in de nabijheid van een invoerveld is een impliciete associatie; bij juist gebruik van het
<LABEL>element is altijd sprake van een expliciete associatie. Gebruik vanIDenFORattributen biedt meer flexibiliteit, maar is niet noodzakelijk om te kunnen spreken van een expliciete associatie.Het argument dat Koen Willems aanvoert kan een reden zijn om te kiezen voor methode 2. Maar methode 2 kiezen omdat methode 1 'volgens de regels' niet zou mogen is naar mijn mening onterecht. Bovendien: in dat geval zou het voorbeeld bij webrichtlijn 13.1 strijdig zijn met het normdocument. Dat is het voorbeeld dat Krijn heeft gebruikt voor dit bericht.
@Raph: even zoeken, en ja, daar is 'ie! Ik citeer uit het onderzoeksrapport:
R-pd.13.1
Gebruik het label element om tekst expliciet met een invoerveld in een formulier te associëren.
Uitslag: nee
Toelichting:
Bij de quiz op pagina http://www.XXXX.nl/quiz/1 en volgende pagina's is wel het label element gebruikt, maar is de associatie niet expliciet gemaakt door gebruik te maken van het for-attribuut bij het label element en het id-attribuut bij het invoerveld en bij dezelfde waarde mee te geven.
(einde citaat)
Ik was er indertijd (begin '08) ook verbaasd over, zeker omdat er dus een onjuist voorbeeld op de site zou staan, maar ik heb me er toen maar bij neergelegd. Toch is de discussie wel zinvol; er zijn genoeg cms'en die standaard methode 1 opleveren, en als het niet nodig is om dat om te bouwen, besteed ik mijn tijd graag ergens anders aan :-)
Eerst mijn standpunt nader toelichten voordat een ander me er op wijst...
De angel bij de interpretatie van deze richtlijn zit 'm in het woord 'expliciet'. In het W3C-jargon heeft dat woord in combinatie met het
<label>element wel degelijk een betekenis die inhoudt dat hetforenidattribuut moet worden gebruikt. Zie http://www.w3.org/TR/html401/interact/forms.html#h-17.9 en http://www.w3.org/TR/WCAG20-CSS-TECHS/H44.html (let wel op: dit document gaat over toepassing van de Web Content Accessibility Guidelines (WCAG) versie 2.0; niet versie 1.0 die in de Webrichtlijnen is verwerkt).Echter, in het Normdocument Webrichtlijnen wordt het woord 'expliciet' niet nader gedefinieerd. De richtlijn luidt dat je het
<label>element moet gebruiken om tekst expliciet met een invoerveld in een formulier te associëren. En dus niet dat je hetforenidattribuut moet gebruiken om tekst expliciet met een invoerveld in een formulier te associëren. Die laatste is veel ... ehhh ... explicieter ;-)Er zijn dus meerdere interpretaties mogelijk voor wat betreft deze specifieke richtlijn, die in het normdocument is gedefinieerd als een 'succescriterium' van WCAG 1.0 ijkpunt 12.4: "Associeer labels expliciet met hun besturingsmechanismen".
In geval van tekst (zoals genoemd in Webrichtlijn 12.3) is een
<label>element een probaat middel om een relatie te leggen; in geval van een label (zoals genoemd in WCAG ijkpunt 12.4) is dat niet het geval; dan is gebruik van hetforenidattribuut de aangewezen manier.Snap je het nog? Mooi!
Zo niet, dan kan niemand je dat kwalijk nemen... het kan duidelijker dan nu het geval is. Dus dat is een puntje voor verbetering, lijkt me.
Wordt een leuke discussie voor de normcommissie van het Waarmerk drempelvrij.nl ;-)
Raph, bedankt voor je uitleg, ik had het niet beter kunnen verwoorden. Inderdaad een mooi discussiestuk voor de normcommissie.
Daar kunnen we het best over hebben in de Normcommissie, maar dat zou ik graag ook meer informatie willen over de problemen die Mike Cherim in zijn hierboven door mij gegeven blogpost noemt.
Ik zou daarom nog wel wat meer informatie willen hebben over de vraag of, en zo ja, welke screenreaders allemaal moeite hebben met methode 1.
ik zou voor keuze 2 gaan. simpelweg omdat keuze 1 je in ie6 geen focus geeft op het input veld bij klikken op het label.
Keuze 2. Om de redenen die Koen benoemt en om alle <span>-achtige dingen te voorkomen.
Wat weerhoudt ons er van om aan methode 1 (met of zonder <span>s) een for met id koppeling toe te voegen?
Duh! Dat is natuurlijk nog een derde mogelijkheid :) Heb de post aangepast.
Ik doe 2 of 3. Als ik hulptekst hebben in de label dan gebruik ik de span om hulptekst te houden. Als er geen hulptekst is, gebruik ik de label als container en een floated span voor de label tekst. Altijd altijd altijd met expliciet association, behalve:
soms heb je tekst die moet in een form-control zetten, te lang om in een legend te zetten, die een vraagje stelt en gevolgt is door checkbox/radio button vragen (die z'n eigen labels hebben). Daar gebruik ik niet een p maar een label zonder eigen input.
JAWS leest alleen form controls in Forms Mode. Met impliciet labels rond checkboxes/radio buttons, hoor je alleen de eerste label bij alle vragen: Vindt u Oreo's lekker? Ja, Ja.
Jammer dat ik Javascript moet aandoen alleen om rond de spammer vraag te komen : ( Ik vulde hem niet in, maar dat maakt niet uit : (
(@Mallory: zonder JavaScript kun je toch gewoon 'nee' invullen?)
(@krijn) sorry ik las dat als "niet invullen"!!)
Ah :)