Utilisation de label

Bonjour,

Je ne sais pas pourquoi, mais j'ai toujours cru que que la seule manière d'implémenter un label de la meilleure façon possible était celle là

<label for="foo">mon label</label>
<input name="foo" id="foo" />

Suite à ce post

http://forum.alsacreations.com/topic-4-33370-1-Label-sur-plusieurs-lignes.html

La solution suivante à été donné

<label>
<input type="radio" value="foo" name="bar" />
Lorem ipsum dolor sit amet.
</label>

Les deux sont valide mais dans ce cas là, l'intitulé du label arrive après l'élément donc comment va se comporter une synthèse vocale, elle lira automatiquement l'intitulé du label en premier malgré sa place dans le flux?

Bonjour,

La seconde solution (label implicite) est formellement valide en HTML mais n'est plus admise aujourd'hui (cf Accessiweb, RGAA, et plus généralement WCAG2.0), car elle n'est pas toujours correctement reconnue par les aides techniques. Le seul code à utiliser est celui des labels explicites:

<input type="radio" value="foo" name="bar" id="bar1" />
<label for="bar1">Lorem ipsum dolor sit amet.</label>

Lorsqu'on est en mode formulaire, ou qu'on se déplace avec la tabulation, ou de contrôle en contrôle, Jaws annonce le label avant le contrôle radio, puis l'état et enfin la position éventuelle dans une série (par exemple: "Lorem ipsum dolor sit amet, radio button not checked, one of three"). En revanche, lorsqu'on est en lecture linéaire de la page, Jaws annonce les labels et les contrôles dans l'ordre où ils se présentent (donc ici le contrôle radio d'abord, le label ensuite), sans que ce soit problématique.

Salut Laurent Denis,

En fait ma question portait plus sur la construction html.

Donc en fait du moment que le label est explicite il peut être codé de différente maniére sans que celà pose problème.

label avant, label après, label englobant l'input avec l'intitulé avant ou après.

Je ne sais pas ou j'ai été cherché que ce label devait absolument être devant l'élément qu'il désigne en tous cas merci, je me coucherai moins c.. ce soir

knarf a écrit :
label englobant l'input avec l'intitulé avant ou après.

Justement non

Pas de label englobant l'input (même s'il a un attribut for)

a écrit :
Justement non

Pas de label englobant l'input (même s'il a un attribut for)

Quand benjamin à donné sa solution et que celle-ci à été adoptée, j'étais parti pour faire une réponse négative quant à l'utilisation de cette syntaxe et du hack important! et puis un gros doute, donc vérification rapide w3c et Openweb et sur les deux sites il existe bien des exemples avec label englobant alors je me suis ravisé et dit que j'avais loupé quelquechose et que cela était parfaitement utilisable sans problème du moment que c'était "explicite".

Tiré d'Openweb :

a écrit :
Pour indiquer une description de champ, on inclus celle-ci entre les balises de label et on indique, par l'attribut "for", l'id du champ auquel la description est rattachée, comme ceci :

<form action="...">
<p>
<label for="nom">Nom :</label>
<input type="text" id="nom" />
</p>
</form>
Il existe une autre façon d'utiliser la balise <label> : celle d'inclure le champ de saisie entre les balises de label, en même temps que la description :

<form action="...">
<p>
<label for="nom">
Nom : <input type="text" id="nom" />
</label>
</p>
</form>
Dans ce cas, en théorie, il est possible d'omettre l'attribut "for", mais les navigateurs ne savent pas tous bien gérer cette situation, en particulier Internet Explorer (il ne fait pas la liaison entre le champ et sa description, et donc par exemple, un clic sur le label ne mettra pas le focus sur le champ de saisie). Il est donc recommandé de toujours mettre l'attribut "for".

<hs>
Pourquoi la recherche "formulaires" sur openweb ne me donne aucun résultat?
</hs>

EDIT :

a écrit :
lorsqu'on est en lecture linéaire de la page, Jaws annonce les labels et les contrôles dans l'ordre où ils se présentent (donc ici le contrôle radio d'abord, le label ensuite), sans que ce soit problématique.

Bien que ce ne soit pas problèmatique est-ce que pour une question de confort de compréhension du formulaire le label avant ou le label après à un impact important?

Est ce que je me prends la tête à toujours vouloir le mettre devant dans le flux ce que je trouve le plux logique (on explique d'abord à quoi sert le contrôle) ou est-ce que des fois je peux lacher prise et me dire bon il est derrière ce n'est pas dramatique?
Modifié par knarf (12 Mar 2008 - 15:48)

knarf a écrit :


Tiré d'Openweb :

L'article d'openweb est un peu ancien. L'exclusion déinitive des labels implicites (dans le cadre des travaux de WCAG2.0) s'est décidée après sa parution.

a écrit :
Bien que ce ne soit pas problèmatique est-ce que pour une question de confort de compréhension du formulaire le label avant ou le label après à un impact important?

Est ce que je me prends la tête à toujours vouloir le mettre devant dans le flux ce que je trouve le plux logique (on explique d'abord à quoi sert le contrôle) ou est-ce que des fois je peux lacher prise et me dire bon il est derrière ce n'est pas dramatique?

Tu te prends la tête

Non seulement ça n'est pas dramatique, mais c'est très bien et logique comme ça. La lecture "linéaire" du contenu se fait... dans l'ordre du contenu. Et les modes d'accès spécifiques aux formulaires adoptent eux l'ordre qui convient le mieux dans leur contexte. Mettre les libellés de boutons radios ou de checkbox avant les contrôles, cela reviendrait à chercher une optimisation (qui n'en est par ailleurs pas vraiment une) uniquement pour certains utilisateurs handicapés, au détriment des utilisateurs non visés. Ce qui n'est pas faire de l'accessibilité : elle consiste à éviter que des personnes soient pénalisées par rapport à d'autres. Pas à choisir qui on pénaliserait...

Benjamin D.C. a écrit :
En dehors de ces lacunes d'implémentations, en quoi le label implicite peut-il être néfaste?

Un label qui n'est pas reconnu comme tel par une aide technique... c'est suffisant comme raison, je crois ?

Laurent Denis a écrit :


Un label qui n'est pas reconnu comme tel par une aide technique... c'est suffisant comme raison, je crois ?

Nous sommes bien d'accord.
Je m'interrogeais surtout sur le bien fondé d'une décision qui exclut un principe cohérent sur base d'un manque ponctuel de support par certaines aides techniques.

principe cohérent, non, pas vraiment.

Pourquoi devoir implémenter deux méthodes quand l'une n'apporte rien par rapport à l'autre ? (elles co-existent en HTML4.01 uniquement pour des raisons de compromis historique entre fabriquants).

Sauf erreur de ma part, les labels implicites disparaissent en HTML5, d'ailleurs, au profit de la liaison explicite nettement plus intéressante du point de vue du DOM.

Laurent Denis a écrit :
elles co-existent en HTML4.01 uniquement pour des raisons de compromis historique entre fabriquants

J'ignorais que la cause était si... platement commerciale.
Merci pour la précision.