Du bon usage de FIELDSET et LEGEND...

Bonjour,

Parmi les éléments HTML d'usage «courant», il y en a deux qui me laissent perplexe: FIELDSET et LEGEND. Leur usage exact est assez flou pour moi.

La spécification HTML 4 a l'air de suggérer qu'un formulaire un peu long doit être séparé en plusieurs FIELDSET. Les LEGEND seraient alors une sorte de titre de section spécialisé pour les formulaires.

Mais il me semble que les lecteurs d'écran répètent le LEGEND avant l'intitulé de tout LABEL dans le FIELDSET. Ce qui rend l'usage suivant très pertinent:

<fieldset>
	<legend>Civilité:</legend>
	<input type="radio" id="civ1" />
	<label for="civ1"><abbr title="Madame">M<sup>me</sup></abbr></label>
	<input type="radio" id="civ2" />
	<label for="civ2"><abbr title="Monsieur">M.</abbr></label>
</fieldset>

... mais qui rend l'utilisation des LEGEND comme titres des parties de formulaires assez casse-gueule, et moins souple à mon sens que des titres de section.

Qu'en pensez-vous?

Pour référence:
http://www.la-grange.net/w3c/html4.01/interact/forms.html#edef-FIELDSET
http://rgaa.dgme.fr/index.php/front/web/points_de_controle/12_3

Salut Florent,

Qu'est-ce que tu entends par casse gueule et moins souple?

Par rapport à ce que j'en perçois, la paire "fieldset / legend" est uniquement un complément aux balises label (donc elle doit être utiliser dans un contexte de formulaire).

A mes yeux, 2 cas de figures d'utilisation :
- cas où les balises label sont propres à une caractéristique précise (ton exemple sur la civilité est à mon sens tout à fait pertinent) ;
- cas où les balises label ont un intitulé ambigüe nécessitant une information supplémentaire (exemple deux labels ayant un intitulé "nom" un pour une personne un autre pour une autre personne ... donc 2 fieldsets à mettre en place).

Dans les autres cas, alors oui le titre de section s'impose.

<edit>

a écrit :
Qu'est-ce que tu entends par casse gueule et moins souple?

Dans le cas d'un utilisateur de synthèse vocale, le legend ne sera pas lu dans un contexte hors formulaire (sans liaison avec label) ... d'où une perte d'information (par rapport à un titre de section)
</edit>
Modifié par yodaswii (13 Aug 2008 - 14:13)

a écrit :
Mais il me semble que les lecteurs d'écran répètent le LEGEND avant l'intitulé de tout LABEL dans le FIELDSET. Ce qui rend l'usage suivant très pertinent

C'est exact, en tout cas pour jaws 7.10+. Et effectivement c'est très pertinent, ça permet de bien savoir où on est.
J'avais déjà repéré depuis longtemps ce comportement de jaws, mais je n'ai jamais réellement osé l'utiliser pour une raison toute simple : je ne sais pas quelle gueule ça a graphiquement.
Ce qui est sûr c'est que vocalement, ça joue très bien son rôle de label de button group, tel qu'on les voit dans les boîtes de dialogue ordinaires. Encore faudrait-il qu'après, ça en prenne l'aspect.

J'ai toujours considéré les fieldset+legend dans cette optique plutôt qu'en tant que délimiteurs de parties de formulaire. A mon sens, si un formulaire a plusieurs grandes parties distinctes, les classiques titres <h#> sont très adaptés puisqu'ils sont atteignables directement (ce qui n'est pas le cas des legend, évidemment)

EDIT : double-grillé, ça m'apprendra à écrire des tartines pendant 15 minutes.
Modifié par QuentinC (13 Aug 2008 - 14:22)

a écrit :
cas où les balises label ont un intitulé ambigüe nécessitant une information supplémentaire (exemple deux labels ayant un intitulé "nom" un pour une personne un autre pour une autre personne ... donc 2 fieldsets à mettre en place).

Pourquoi ne pas de suite éluder la question des intitulés ambigües en les nommant respectivement nom1 et nom2.

a écrit :
Pourquoi ne pas de suite éluder la question des intitulés ambigües en les nommant respectivement nom1 et nom2.

Pour précision, quand je parle des intitulés il s'agit de l'information véhiculée (donc le "textNode" du label). Exemple :

<fieldset>
<legend>Concubin</legend>
<label for="nom1">Nom :</label> <input type="text" id="nom1" name="nomconcubin" />
<label for="pnom1">Prénom :</label> <input type="text" id="pnom1" name="pnomconcubin" />
</fieldset>
<fieldset>
<legend>Concubine</legend>
<label for="nom1">Nom :</label> <input type="text" id="nom1" name="nomconcubine" />
<label for="pnom1">Prénom :</label> <input type="text" id="pnom1" name="pnomconcubine" />
</fieldset>

Par contre oui, on peut tout à fait envisager de préférer un label plus explicite ("Nom du concubin") et laisser ainsi de côté le fieldset avec son legend ...
Modifié par yodaswii (13 Aug 2008 - 14:29)

knarf a écrit :
cas où les balises label ont un intitulé ambigüe nécessitant une information supplémentaire (exemple deux labels ayant un intitulé "nom" un pour une personne un autre pour une autre personne ... donc 2 fieldsets à mettre en place).

Pourquoi ne pas de suite éluder la question des intitulés ambigües en les nommant respectivement nom1 et nom2.
Si on parle d'une personne est de son conjoint, il est plus agréable de voir une section "vous" suivie de "votre conjoint" plutôt que de lire "nom de votre conjoint", "prénom de votre conjoint", etc.

Fieldset et legend remplissent bien leur rôle de section de formulaire.

Pour le casse-gueule, ce n'est peut-être pas le bon terme. Mais en regardant l'exemple de la spécification ou celui donné dans le RGAA, je me dis que FIELDSET et LABEL ne sont pas vraiment nécessaires pour clarifier les labels de chaque partie. Dans l'exemple du RGAA, un lecteur d'écran lirait (mais je peux me planter):

a écrit :
- Information de commande: Nom
- Information de commande: Adresse
- Information de commande: Produit commandé
- Informations complémentaire: Age
- Informations complémentaire: Commentaire

Est-ce vraiment utile?
Dans certains cas, je pense que ça peut même être perturbant si la combinaison fieldset + label donne quelque chose d'un peu étrange.

Ensuite, si l'exemple que je donnais avec la civilité est pertinent -- et on pourrait faire le même pour la saisie très stricte d'une adresse postale, par exemple, avec différents champs pour les différents éléments de l'adresse --, eh bien si on utilise des FIELDSET comme dans l'exemple du RGAA ou de HTML 4 on peut se retrouver avec des imbrications de FIELDSET:

<form>
	...
	<fieldset>
		<legend>Vos coordonnées</legend>
		Nom
		Prénom
		Téléphone
		<fieldset>
			<legend>Adresse</legend>
			Rue et numéro
			Ligne complémentaire
			Ville
			Code postal
			Pays
		</fieldset>
	</fieldset>
...
</form>

(Je schématise, bien sûr.)

Ce type de construction serait valide. Mais qu'est-ce que ça donnerait dans les navigateurs, et surtout avec les lecteurs d'écran?

a écrit :
Si on parle d'une personne est de son conjoint, il est plus agréable de voir une section "vous" suivie de "votre conjoint" plutôt que de lire "nom de votre conjoint", "prénom de votre conjoint", etc.

Agréable ... oui et non. Tout dépendra de l'utilisateur et de la façon dont la page est conçue.

Mais dans la plupart des cas en effet je pense que 2 fieldsets dans ce genre de configuration sont de loin plus ergonomiques que de la répétition d'une même information pour un non-utilisateur de synthèse vocale.
Modifié par yodaswii (13 Aug 2008 - 14:40)

a écrit :
Ce type de construction serait valide. Mais qu'est-ce que ça donnerait dans les navigateurs, et surtout avec les lecteurs d'écran?

Je pense que le lecteur d'écran attaquerait du 1er legend au dernier legend soit : Vos coordonnées > Adresse > Rue et numéro. (à confirmer bien sûr)

Mais un fieldset seul me semble une grave erreur si l'on doit faire un regroupement de champs, il me semble logique qu'il doit y avoir 2 regroupements.

a écrit :

Ce type de construction serait valide. Mais qu'est-ce que ça donnerait dans les navigateurs, et surtout avec les lecteurs d'écran?

Je concocte un test rapide et je vous dis de suite ce qu'il en est avec jaws 7.10.

EDIT : ça marche pas

Avec la structure suivante :

Groupe 1 {
champ 1
champ 2
}
Groupe 2 {
champ 1
Sous-groupe {
sous-champ 1
sous-champ 2
}
champ 2
}
Groupe 3 {
champ 1
champ 2
}

J'obtiens la sortie suivante en parcourant les champs successivement, avec tab en mode formulaire, ou avec F en mode de lecteure normale :

Groupe 1 champ 1
Groupe 1 champ 2
Groupe 2 champ 1
Sous-groupe sous-champ 1
Sous-groupe sous-champ 2
[b]Sous-groupe champ 2[/b]
Groupe 3 champ 1
Groupe 3 champ 2

Cependant l'ordre que vous avez proposé serait le plus logique...
Modifié par QuentinC (13 Aug 2008 - 15:12)

Est-ce vraiment grave qu'on perde la section?

En cherchant j'ai vu sur A list A Part un auteur conseiller cet agencement :

Brian Crescimanno a écrit :
for radio buttons or checkboxes, use the <fieldset> and <legend> tags to group the elements logically under an obvious heading. This grouping keeps the form manageable to users, as it can be broken down into smaller pieces in their minds.

Par contre, désolé je reviens à mon problème initial décrit dans un autre message, si c'est le bon gest à avoir, quid de la mise en forme CSS de <legend> sous Firefox? Proposer un <hn>, comme conseillé par Florent V., en lieu et place de <legend> en attendant qu'on puisse correctement le mettre en forme serait-il la bonne marche à suivre en attendant?

a écrit :
Est-ce vraiment grave qu'on perde la section?

Si il y a perte d'information alors oui cela devient grave.

a écrit :
Par contre, désolé je reviens à mon problème initial décrit dans un autre message, si c'est le bon gest à avoir, quid de la mise en forme CSS de <legend> sous Firefox? Proposer un <hn>, comme conseillé par Florent V., en lieu et place de <legend> en attendant qu'on puisse correctement le mettre en forme serait-il la bonne marche à suivre en attendant?

Je plussoie Florent ... c'est-à-dire virer ce fieldset avec le legend "Identité" et utiliser un hN à la place ... Au delà de l'aspect présentation, il se pose aussi l'aspect de rendu. Sur un navigateur visuel l'imbrication de fieldset n'est pas problématique mais semble l'être avec certains lecteurs d'écran (comportement normal ou problème d'implémentation) d'où une conclusion qui me fait dire qu'il faut éviter d'utiliser de l'imbrication de fieldset et plutôt avoir recours à des titres de section.

D'ailleurs dans ton exemple, la pertinence de ton fieldset "Identité" est pour moi nulle : les informations ne désignent pas la même caractéristique (ce qui est le cas de civilité).

Ainsi dans ton exemple, le fieldset devient pertinent dans le cas d'intitulé de label ambigüe uniquement.
Modifié par yodaswii (14 Aug 2008 - 13:55)

yodaswii a écrit :
D'ailleurs dans ton exemple, la pertinence de ton fieldset "Identité" est pour moi nulle : les informations ne désignent pas la même caractéristique (ce qui est le cas de civilité).

Il faudrait plutôt parler de ça dans l'autre fil de discussion. Mais ça voudrait dire que l'un de nous deux interprète mal la recommandation du w3c : http://www.la-grange.net/w3c/html4.01/interact/forms.html#edef-FIELDSET (cf. 1er exemple)

a écrit :
Mais ça voudrait dire que l'un de nous deux interprète mal la recommandation du w3c ...

Il s'agit de moi qui m'éloigne volontairement de la recommandation (qui me semble ma foi des plus flous).
Par rapport à ton problème, il s'agit "juste" d'un problème de présentation.

En ce qui me concerne, je me place plus dans une démarche d'utilisabilité et d'accessibilité. Par rapport aux différents commentaires, il faut trouver un juste compromis pour les utilisateurs de navigateurs visuels et de lecteurs d'écran.

Donc pas trop abuser de fieldset.
Modifié par yodaswii (14 Aug 2008 - 14:14)

J'arrive pas à comprendre pourquoi vous voulez imbriquer des fieldset et mettre des titres dans les formulaires.

Si l'on vient à se poser cette question est-ce que ce n'est pas parce que l'organisation du formulaire et que ces différents intitulés ne sont pas bon?

Le RGAA dit:

a écrit :
Utiliser l'élément fieldset pour regrouper les champs de formulaire lorsque cela est nécessaire

Il ne dit pas regrouper les champs et les groupes de champs de formulaire

a écrit :
J'arrive pas à comprendre pourquoi vous voulez imbriquer des fieldset et mettre des titres dans les formulaires.
Si l'on vient à se poser cette question est-ce que ce n'est pas parce que l'organisation du formulaire et que ces différents intitulés ne sont pas bon?

Pas du tout selon moi. L'exemple avec "vous : non, prénom. Votre conjoint : nom, prénom" est un excellent exemple où des titres de section sont appropriés pour "vous" et "votre conjoint".
Des titres de section seraient même plus appropriés que des legend si ces derniers venaient à être imbriqués par exemple si vous voulez ajouter l'exemple civilité du premier post de Florent.
Comme vous pouvez le voir, l'imbrication de fieldset+legend pose problème aux lecteurs d'écran, cf. mon exemple précédent, la ligne qui pose problème est celle en gras, car elle rapporte une information erronnée.

Legend restera toujours pour moi un label de groupe de boutons, et non un titre pour une partie de formulaire. Dans ce dernier cas, personnellement, je priviligierais les titres de section normaux <h#>.
Cela dit, je ne vois pas de contre-indication à utiliser des fieldset imbriqués sans legend. Auquel cas leur fonction devient substitut de l'élément générique div.

QuentinC a écrit :
Cela dit, je ne vois pas de contre-indication à utiliser des fieldset imbriqués sans legend.

Le RGAA demande de ne pas le faire.

Sinon plutôt d'accord dans l'ensemble avec tes conclusions, Quentin.
Modifié par Florent V. (15 Aug 2008 - 11:24)

a écrit :
Le RGAA demande de ne pas le faire.

Ah, bon.... Mais pour quelle raison ?
En tout cas du côté du W3C, ça reste valide.

QuentinC a écrit :
Le RGAA demande de ne pas le faire.

Ah, bon.... Mais pour quelle raison ?
Sans doute pour éviter que des éléments LEGEND réellement nécessaires ne soient absents, par mégarde ou parce qu'ils étaient trop compliqués à styler.

Et comme tu le dis, un FIELDSET sans LEGEND revient à utiliser un DIV pour faire de la mise en forme. Donc autant utiliser un DIV.
Modifié par Florent V. (15 Aug 2008 - 12:30)