Fronteers — vakvereniging voor front-end developers

Webrichtlijn 83: Invoervelden en labels

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:

Een simpel formulier met tekstlabels en invoervelden, met achter 1 invoerveld het woord "uur" en voor 2 invoervelden een €-teken.

En hack je in het volgende voorbeeld met positioning, of gebruik je gewoon 2 labels, ondanks de problemen:

Een invoerveld met een tekstlabel aan de linkerkant en een foutmelding eronder.

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?

Reacties

1 Matijs op 03-03-2009 om 15:35 uur:
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.

:before en :after pseudo 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.
2 Vasilis op 03-03-2009 om 15:42 uur:
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.
3 Matijs op 03-03-2009 om 18:20 uur:
Ik vind persoonlijk dat postcodes prima in 1 veld kunnen. Serverside / clientside is er genoeg mogelijk om dit te valideren.
4 Vasilis op 03-03-2009 om 20:24 uur:
Helemaal met je eens, uiteraard. Wist even geen beter voorbeeld te geven en het is in elk geval duidelijk wat ik bedoel (-:
5 Koen Willems op 06-03-2009 om 22:27 uur:
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.
6 Marc op 09-03-2009 om 16:35 uur:
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.
7 Raph de Rooij op 11-03-2009 om 10:48 uur:
@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 van ID en FOR attributen 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.
8 Marc op 12-03-2009 om 01:50 uur:
@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 :-)
9 Raph de Rooij op 12-03-2009 om 22:28 uur:
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 het for en id attribuut 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 het for en id attribuut 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 het for en id attribuut 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 ;-)
10 Marc op 12-03-2009 om 23:21 uur:
Raph, bedankt voor je uitleg, ik had het niet beter kunnen verwoorden. Inderdaad een mooi discussiestuk voor de normcommissie.
11 Koen Willems op 13-03-2009 om 00:46 uur:
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.
12 Wilfred Nas op 17-03-2009 om 09:43 uur:
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.
13 Stephen Hay op 18-03-2009 om 22:48 uur:
Keuze 2. Om de redenen die Koen benoemt en om alle <span>-achtige dingen te voorkomen.
14 Matijs op 19-03-2009 om 17:48 uur:
Wat weerhoudt ons er van om aan methode 1 (met of zonder <span>s) een for met id koppeling toe te voegen?
15 Krijn op 19-03-2009 om 17:51 uur:
Duh! Dat is natuurlijk nog een derde mogelijkheid :) Heb de post aangepast.
16 Mallory op 20-03-2009 om 14:46 uur:
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 : (
17 Krijn op 20-03-2009 om 18:31 uur:
(@Mallory: zonder JavaScript kun je toch gewoon 'nee' invullen?)
18 Mallory op 23-03-2009 om 15:36 uur:
(@krijn) sorry ik las dat als "niet invullen"!!)
19 Krijn op 23-03-2009 om 15:43 uur:
Ah :)
Plaats een reactie