Label caché?

Bonjour à tous.
Bien que la question de l'emploi des labels semble être récurrente sur le forum, je ne trouve pas les réponses exactes à mes interrogations! Donc je me lâche... (je crois que c'est mon premier post ici !)

On peut lire chez w3c:

a écrit :
12.4 Associate labels explicitly with their controls. [Priority 2]
For example, in HTML use LABEL and its "for" attribute.

En gros chaque balise input doit avoir son label associé grâce à l'attribut "for".
Mais qu'en est-il pour les balises inputs de type "submit" dont l'attribut "value" (s'il est plus explicite que "ok" ou "envoyer" bien-sur ) fait double emplois avec le contenu du label? (en plus c'est moche dans mon design!)

Si les balises input doivent être systématiquement accompagné d'un label pour être accessible, est-il acceptable de cacher ces labels afin de passer avec succès les tests d'accessibilité?

Je remercie très chaleureusement tous les gens qui prendront le temps de se pencher sur ma requête.

barney a écrit :
Mais qu'en est-il pour les balises inputs de type "submit" dont l'attribut "value" (s'il est plus explicite que "ok" ou "envoyer" bien-sur ) fait double emplois avec le contenu du label? (en plus c'est moche dans mon design!)

Si les balises input doivent être systématiquement accompagné d'un label pour être accessible, est-il acceptable de cacher ces labels afin de passer avec succès les tests d'accessibilité?

Comme tu le souligne, l'input de type submit possède un attribut value. Il n'est donc pas nécessaire de lui associer un label, puisque c'est cette valeur qui est son label.

Merci Laurie-Anne!

C'est bien ce qui me semblait! Mais quand j'utilise l'outil de la webdev toolbar "validate WAI" j'obtiens des "warnings" que j'aimerais éviter!

Après relecture du rapport d'accessibilité (je lis trop vite parfois honte à moi!):

a écrit :
Rule: 1.1.2 - All INPUT elements are required to contain the alt attribute or use a LABEL.

Donc si j'ai bien compris la description alternative avec l'attribut "alt" peut remplacer le label?

Bonjour,

il faut associer les label à leurs contrôles ... du moins pour les contrôles qui ont besoin d'un intitulé. submit et image n'en font pas partie.
Par expérience, radio, text, checkbox, select et textarea peuvent avoir un label associé (j'ai pas vérifié dans la doc pour les 2 derniers mais ça fonctionne )

EDIT: value pour le type submit mais alt pour image, yop. Le truc c'est que certains navigateurs acceptent aussi value pour image mais çaÿmal
Modifié par Felipe (26 May 2009 - 12:53)

Donc je disais une bétise:

a écrit :
Donc si j'ai bien compris la description alternative avec l'attribut "alt" peut remplacer le label?

L'attribut "alt" ne peut remplacer le label que pour les balise input de type "image". Aussi pour une balise input de type "text" il faut absolument un label.

Donc je reviens à mes interrogations précédente:
Dans le cadre d'un champ texte, si le label jure avec mon design, est-il convenable de le cacher?

Si oui, quelle est la meilleur technique pour le faire?
text-indent=-3000px, display:none, visibility:hidden ou autre?

Est-il possible de mettre un value faisant office de label, effacé sur le onfocus avec js (comme sur la recherche de ce site)? Dans ce cas, est-il nécessaire d'encapsuler la balise input dans une balise label (comme il est fait ici aussi)?

 <label for="recherche-texte"><input id="recherche-texte" name="q" value="recherche" title="recherche" onfocus="if(value=='recherche') this.value='';" type="text"></label>

Pourtant il me semble que ce genre pratique (i.e. l'encapsulation dans label) n'est pas conseillé par le w3c!

barney a écrit :
Dans le cadre d'un champ texte, si le label jure avec mon design, est-il convenable de le cacher?

Aucune idée. Il faudrait tester si, concrètement, le label est bien lu lorsqu'il est caché. Et voir aussi sur les autres solutions possibles (notamment la présence d'un value et/ou d'un title sur l'INPUT, servant de label) donnent des résultats corrects. Et enfin, dans le cas où le title ne serait pas lu tandis que le value le serait, voir ce que donnent les scripts qui écrivent dynamiquement un value ou le remettent à zéro au focus.

Si on opte pour un label caché, il faudra sans doute le cacher via JavaScript (ne serait-ce qu'en ajoutant une classe sur le label concerné), puis exploiter le contenu de ce label pour l'utiliser comme value du champ associé.

barney a écrit :
Si oui, quelle est la meilleur technique pour le faire?
text-indent=-3000px, display:none, visibility:hidden ou autre?

Positionnement absolu, affichage hors écran (en haut ou à gauche de préférence).

barney a écrit :
Est-il possible de mettre un value faisant office de label, effacé sur le onfocus avec js (comme sur la recherche de ce site)?

Techniquement, bien sûr. Est-ce accessible? Aucune idée, à tester.

barney a écrit :
Dans ce cas, est-il nécessaire d'encapsuler la balise input dans une balise label (comme il est fait ici aussi)?

C'est effectivement fait ici, mais j'avoue ne pas voir quel est l'intérêt de la manoeuvre en l'absence de texte dans le label.

barney a écrit :
Pourtant il me semble que ce genre pratique (i.e. l'encapsulation dans label) n'est pas conseillé par le w3c!

Ce sont les labels implicites, sans attribut for, qui sont déconseillés car ils sont inefficaces. Ici il n'y a pas de texte dans le label, donc il semblerait que la question ne se pose même pas...

Dans le cas des boutons, il n'y a pas de label, le bouton se suffit à lui-même. Par contre, l'alt est obligatoire pour les boutons sous forme d'image.

Dans le cas des zones de texte simple ou multilignes, zones de listes, boutons radio, ou cases à cocher, si vous ne pouvez vraiment pas mettre de label, un truc qui marche assez bien (en tout cas avec jaws) est de mettre un title sur l'input / textarea / select.

C'est notamment pratique dans deux cas :
1 - Si plusieurs composants doivent être l'un à côté de l'autre mais que visuellement ils se rattachent à une même chose. Exemple typique : saisie de date en trois zones jour, mois année (où tout le monde pensera au label sur le premier champ mais l'oubierait assez facilement pour les suivants), ou choix dans plusieurs zones de liste directement dépendantes (p.ex. catégories et sous-catégories). Si c'est clair visuellement, ça ne l'est pas forcément pour un lecteur d'écran.
2 - Dans les tableaux lorsque l'input et son label associé ne sont pas dans des cellules adjaçantes horizontalement.
Si l'input et son label ne sont pas dans des cellules adjaçantes, ça a même tendance à boulverser la « mise en page » de jaws, si vous voyez ce que je veux dire par là.

Le texte par défaut qui s'efface au onfocus, c'est possible aussi, mais c'est moins bon que le title. Au cas où le texte par défaut ne disparaît pas pour une raison ou pour une autre, on ne se rend pas facilement compte du problème (je me suis déjà surpris à faire des recherches du genre "propriété XXXXXVotre recherch", on se sent un peu con quand on le remarque un peu trop tard).

Merci pour vos réponses, je vais mettre tout ça en application!

Bonjour,

le label ne sert pas qu'aux lecteur d'écran.

Le cacher c'est enlever une aide qui peux s'avérer très utile pour certains profils d'utilisateurs.

a écrit :
Dans le cadre d'un champ texte, si le label jure avec mon design, est-il convenable de le cacher?

On recommence :

Comment je peux faire pour que le label s'intègre bien dans mon design.

Ca sent le design réalisé avant la prise en compte de l'accessibilité.

La prochaine fois peut-être agir dans l'autre sens.

QuentinC a écrit :
Dans le cas des zones de texte simple ou multilignes, zones de listes, boutons radio, ou cases à cocher, si vous ne pouvez vraiment pas mettre de label, un truc qui marche assez bien (en tout cas avec jaws) est de mettre un title sur l'input / textarea / select.

L'utilisation du TITLE est une des techniques suffisantes à présent admise par WCAG2.0 quand on ne souhaite pas recourir au LABEL.

knarf a écrit :
La prochaine fois peut-être agir dans l'autre sens.

Oui, mais un peu non (j'aurais dû montrer cet exemple hier )

Cas-type: le formulaire de recherche simple, affiché sur chaque page. Le libellé du bouton de soumission est "Chercher" et la position du formulaire dans le design fait partie de celles qui sont prévisibles (vaguement en haut à droite par exemple). Le bouton bien visible suffit à expliciter le rôle du champ, et le LABEL serait redondant. TITLE est ton ami. Même chose pour l'abonnement à la newsletter.

Mais là où tu as tout à fait raison, c'est que la réflexion en amont sur l'accessibilité et l'ergonomie a eu lieu, et que c'est pour cela que le bouton de soumission est parfaitement explicite

Oui question de contexte on vas dire.

Mais si cette réflexion est faites sur un champ (recherche) il y 'a de fortes chances que cela soit fait sur d'autre (formulaire complet) où là, plus aucun label, cela risque d'être plus embêtant.

On vas dire que c'est de l'anticipation.

a écrit :
Oui, mais un peu non (j'aurais dû montrer cet exemple hier cligne )

A garder au chaud pour la prochaine
Modifié par knarf (30 May 2009 - 12:23)

knarf a écrit :
Oui question de contexte on vas dire.

Définir des formulaires hors contexte, c'est à dire sans approche fonctionelle, c'est idiot. le travail d'un intervenant, quel qu'il soit, dans un projet Web est de dire à la Commune de Trifouili-les-Oies qu'elle ne ne sait pas, mais qu'elle a un truc que ça s'appelle des process, et qu'il y a des règles à suivre dans ce cas.

Après, évidemment, la question est de savoir ce qu'on facture

Je parlais du contexte d'utilisation du formulaire.

Pour une recherche ou pour un formulaire complet.

Mais bon par rapport à WCAG 2.0 on est plus dans la qualité et l'ergonomie.