1178 sujets

Accessibilité du Web

Utilisation des fieldsets pour encadrer chaque champ

Bonjour,

Je rencontre de plus en plus souvent une utilisation des fieldset et legend que me paraît étonnante :

l’emploi d’une balise [i]fieldset sans legend sur chaque couple label+input[/b]

<fieldset>
          <label for="monNom">Nom :</label><input type="text" name="monNom" />
</fieldset>
<fieldset>
          <label for="monPrenom">Prenom :</label><input type="text" name="monPrenom" />
</fieldset>

Vous pouvez retrouver un exemple de ce type d’utilisation sur l’excellent site KNACSS dans la démo N°5 sur les formulaires (http://www.knacss.com/demos/5.html).

J’avais pris pour habitude de faire un emploi plus classique, à savoir une balise fieldset avec legend pour regrouper des champs liés par le sens ; 

<fieldset>
          <legend>Vous</legend>
          <label for="monNom">Nom :</label><input type="text" name="monNom" />
          <label for="monPrenom">Prenom :</label><input type="text" name="monPrenom" />
</fieldset>

Dans cette manière de faire, l’accessibilité semblait plutôt bonne car les lecteurs d’écran avaient tendance à répéter la legend avant chaque label, ce qui me convenait parfaitement.

Par contre, je ne comprends pas l’intérêt d’encadrer chaque label+input d’un fieldset. Je ne vois pas ce que cela apporte d’un point sémanthique et d’un point pratique pour l’internaute.

Aurais-je loupé quelques choses ? Y’a-t-il eut une évolution que j’aurais manqué ? Ou simplement, mon utilisation des fieldset actuels est complètement erroné (voir hérétique) ?

.
Modifié par Styus (30 Jul 2012 - 22:25)
Administrateur
Bonjour et bienvenue, Smiley smile

un fieldset sans legend ne sert pas à grand chose.
Il est à utiliser pour regrouper :
- des informations de même nature, surtout quand il peut y avoir confusion (livraison : nom, rue, code postal, ville vs. facturation : nom, rue, code postal, ville pour prendre un exemple ultra-classique. Ou Voyageur 1, voyageur 2, voyageur 3 sur un site de réservation de voyage)
- avec leur étiquette associée : des boutons radio ou des cases à cocher (checkbox) par le même attribut name ou des select (toujours avec leur label) pour une date tel que jour, mois et année de naissance

Dans l'exemple que tu cites, j'utilise un paragraphe et non un fieldset.
Et comme en général les maquettes fournies par nos clients n'ont pas prévu de legend, je met la légende dans un span affiché hors viewport (.visually-hidden) lui-même dans un legend (parce qu'IE ne touche pas correctement à la position d'un legend ...), c'est le moins pire comme solution.
Il y a des styles par défaut de fieldset et de fieldset > legend à annuler (Firefox ne style pas legend mais fieldset > legend, du coup problème de poids du sélecteur si tu ne fais pas pareil Smiley ohwell )
Modifié par Felipe (02 Aug 2012 - 18:43)
Bonjour Felipe,

Je suis rassuré sur l'utilisation des fieldsets tel que tu le décris car c'est exactement ce que je faisait jusqu'à présent.

Par contre, je suis étonné par ta réponse sur l'exemple que j'ai pris. Le but n'était pas de pointer du doigt une mauvaise pratique dans les démos de KNACSS mais plutôt de comprendre le pourquoi de cette sémantique.

Tu dis utiliser un paragraphe et non un fieldset, or voici un extrait du code HTML de l'exemple :
<fieldset>
	<p>
		<label for="name">Name</label>
		<input type="text" id="name" class="form-text">
	</p>
	<p class="form-help">This is help text under the form field.</p>
</fieldset>
<fieldset>
	<p>
		<label for="email">Email</label>
		<input type="email" id="email" class="form-text">
	</p>
</fieldset>	
<fieldset>
	<p>
		<label for="gender">Gender</label>
		<select id="gender">
			<option>Male</option>
			<option>Female</option>
			<option>Cylon</option>
		</select>
	</p>
</fieldset>
...


Du coup, je ne comprends pas la suite de ton message. Smiley decu

.
Administrateur
Bonjour,

Il est généralement pratique et propre d'englober plusieurs champs dans un fieldset.
Comme tu le soulignes, ce n'est pas forcément idéal d'entourer *chaque* input d'un fieldset, même si cela ne porte pas vraiment à préjudice.

Dans l'exemple de KNACSS, j'ai simplement récupéré le code de http://pea.rs/forms/multi-left-labels pour aller plus vite Smiley cligne
Bonjour Raphael,

Merci pour ta réponse.

Comme le dit Felipe, l'idéal est d'utiliser le Fieldset intelligemment et pour ce à quoi il est fait.

Vu que j'ai rencontré plusieurs personnes qui encadrait *chaque* input d'un fieldset, j'ai cru que je faisais fausse route dans mon interprétation de cette balise.

Je te remercie, toi et Felipe, de m'avoir confirmer que cette méthode n'est pas idéal "même si cela ne porte pas vraiment à préjudice".
Administrateur
Styus a écrit :
Par contre, je suis étonné par ta réponse sur l'exemple que j'ai pris.

Je m'étais fié au code que tu citais, ai vérifié qu'il y avait bien des fieldset dans l'exemple en ligne mais n'ai pas vu les p dans Firebug ...
Du coup par rapport à cet exemple j'utilise également les p mais pas les fieldset sans légende (visible ou au pire hors viewport)


EDIT: rien à voir, juste pour aller plus loin :
Il est préférable de placer l'input (ou select, textarea, etc) dans le label, quitte à placer le texte de l'étiquette dans un span ou strong pour pouvoir le styler. Toujours avec for/id bien évidemment (les lecteurs d'écran sont trop c... pour comprendre qu'un input dans un label pourrait bien être associé au reste du label ...).
Ça ne change rien tel quel mais plus tard en cas de message d'erreur ou lorsque on ajoute un texte explicatif malheureusement souvent après l'élément de formulaire, ils seront lus avec l'étiquette.

<p>
  <label for="blah1">
    <strong>Texte étiquette</strong>
    <input type="text" id="blah1">
    <span class="error">ERREUR&nbsp;: mais n'importe quoi ça!</span>
  </label>
</p>

Modifié par Felipe (03 Aug 2012 - 15:40)
Pour appuyer ce qui est dit plus haut, certains lecteurs d'écrans vont annoncer les <legend> avant chaque <label> si il y a un fieldset. Bref on les utilisera si c'est vraiment nécessaire et pas pour faire joli. Smiley cligne
Sujet clos
Aller à