Association d'étiquettes HTML avec des entrées; mauvais UX?
Je suis un développeur Web ayant un problème UX étrange. Lorsque je crée des formulaires HTML, je m'assure que chaque étiquette d'entrée est implémentée via un <label></label> et que chaque étiquette utilise l'attribut for pour l'associer à l'entrée. Par exemple:
<label for="firstName">First Name</label>
<input id="firstName" type="text" />
<label for="lastName">Last Name</label>
<input id="lastName" type="text" />
Cela suit ce que j'ai toujours entendu est une meilleure pratique d'accessibilité. Il a également ce que je considère comme un avantage supplémentaire de concentrer l'entrée lorsque l'on clique sur l'étiquette.
D'autres ici ne sont pas d'accord sur ce dernier point.
Ils disent en fait que c'est bizarre que cliquer sur l'étiquette concentre l'entrée, et que c'est un comportement "non standard". Puisque j'utilise ce que je considère comme des pratiques HTML standard, je pense que c'est effectivement le cas. Peut-être que c'est juste leur réaction au fait que d'autres pages du site n'utilisent pas de véritables étiquettes et n'ont pas ce comportement, mais elles semblent vraiment détester ce comportement d'étiquette.
Je ne comprends pas. Suis-je dans l'erreur ici? Est-il considéré comme une mauvaise pratique UX que les étiquettes concentrent une entrée? Si oui, pourquoi? Si je dois résoudre ce problème, existe-t-il un autre moyen de rendre une entrée plus accessible sans utiliser d'étiquette?
Je ne comprends pas pourquoi vous souhaitez une zone de clic réduite pour votre champ de formulaire. L'inclusion de l'attribut "pour" sur la balise d'étiquette vous permet d'augmenter la zone cliquable. Il s'agit d'une norme Web depuis un certain temps et je pense que la plupart des utilisateurs sont habitués au comportement à ce stade, ce qui en fait une convention. Bien qu'il ne s'agisse peut-être pas d'une convention dans le domaine des logiciels, je considérerais certainement que c'est une convention Web.
Le meilleur avantage ici est à coup sûr accessibilité accrue (voir la section sur les étiquettes d'entrée de formulaire).
Je ne pense pas que cela s'applique simplement aux cases à cocher et aux boutons radio. J'ai vu des cas où il est pratique à utiliser pour les entrées de texte également, bien que certainement pas autant d'aide qu'avec les boutons radio et les cases à cocher.
Vous pouvez également voir que W3Schools le mentionne comme une amélioration de l'utilisabilité dans sa référence , alors qu'il est vrai que ce n'est pas la meilleure référence. Cependant, si vous regardez spécification HTML 4.01 l'attribut "pour" de la balise d'étiquette est pour vous assurer qu'il est explicitement associé à un autre contrôle, et la spécification mentionne explicitement que "lorsqu'un élément LABEL reçoit le focus, il passe le focus à son contrôle associé ".
Comme avec ce blog de conception web , je trouve également que c'est un "crime" de convivialité lorsque le champ et l'étiquette ne sont pas associés.
Ces "autres" sont incorrects. Ceci est l'intention de la balise HTML et de l'implémentation appropriée. Mis à part la nécessité d'accessibilité, c'est également un énorme avantage UX, en particulier avec des choses telles que les cases à cocher, où il est généralement plus facile d'appuyer sur l'étiquette que la minuscule case à cocher.
Si ces "autres" détestent ça, dites-leur d'arrêter de cliquer sur les étiquettes. ;)
Le comportement n'est pas courant dans les interfaces utilisateur, et il reflète probablement simplement le fonctionnement de label pour les cases à cocher et les boutons radio (cliquer sur l'étiquette bascule l'état et this correspond à la conception UX commune et est très utile). Pour les zones de texte, la fonctionnalité n'est ni particulièrement utile ni nuisible. Toute tentative pour l'empêcher avec JavaScript provoque probablement des problèmes au lieu de résoudre tout, et ne pas utiliser label est mauvais pour l'accessibilité (car le logiciel d'assistance fait autre utiliser pour le balisage label ).
C'est assez discutable.
Pour un appareil tactile, étendre la zone cliquable, en particulier dans le cas de la saisie de texte, peut en fait être contre-productif si l'intention de l'utilisateur est de faire défiler le formulaire au lieu de remplir l'entrée.