Entrées et étiquettes HTML: une histoire d'amour

La plupart des intrants ont quelque chose en commun - ils sont les plus heureux avec une étiquette compagnon! Et le bonheur ne s'arrête pas là. Les formulaires avec des entrées et des étiquettes appropriés sont beaucoup plus faciles à utiliser pour les gens et cela rend les gens heureux aussi.

Dans cet article, je veux me concentrer sur les situations où l'absence d'une étiquette sémantique et une combinaison d'entrée rend beaucoup plus difficile pour toutes sortes de personnes de remplir les formulaires. Étant donné que des millions de moyens de subsistance des personnes reposent sur des formulaires, passons aux meilleurs conseils que je connaisse pour créer une relation épanouissante et harmonieuse entre une entrée et une étiquette.

Avertissement de contenu: dans cet article, ce sont des thèmes de l'amour et des relations.

L'histoire d'amour commence ici! Couvrons les bases pour créer des étiquettes et des entrées heureuses.

Comment associer une étiquette et une entrée

Il y a deux façons d'associer une étiquette et une entrée. L'un est en emballage l'entrée dans une étiquette (implicite), et l'autre est en ajoutant un attribut pour l'étiquette et un ID à l'entrée (explicite).

Considérez une étiquette implicite comme étreignant une entrée et une étiquette explicite comme debout à côté d'une entrée et en tenant la main.

  
  Nom:
  <input type="text" name="name">
 label>

La valeur d'attribut d'une étiquette explicite doit correspondre à la valeur d'ID de sa saisie. Par exemple, si FOR a une valeur de nom, l'ID devrait également avoir une valeur de nom.

  name: 
<input type="text" name="name">

Malheureusement, une étiquette implicite n'est pas gérée correctement par toutes les technologies d'assistance, même si des attributs pour et ID sont utilisés. Par conséquent, c'est toujours la meilleure idée d' utiliser une étiquette explicite au lieu d'une étiquette implicite.

 
 
  Nom:
  <input type="text" name="name">
 label>


 Nom:  Label>
<input type="text" name="name">

Chaque élément d'entrée séparé ne doit être associé qu'à une seule étiquette. Et une étiquette ne doit être associée qu'à une seule entrée. Oui, les entrées et les étiquettes sont monogames. ♥ ️

Remarque: il y a une sorte d'exception à cette règle: lorsque nous travaillons avec un groupe d'entrées, disons plusieurs boutons radio ou cases à cocher. Dans ces cas, un élément est utilisé pour regrouper certains éléments d'entrée, tels que les boutons radio, et sert d'étiquette accessible pour l'ensemble du groupe.

Toutes les entrées n'ont pas besoin d'étiquettes

Une entrée avec un type = "soumettre" ou type = "bouton" n'a pas besoin d'une étiquette - l'attribut de valeur agit à la place comme le texte de l'étiquette accessible. Une entrée avec type = "Hidden" est également très bien sans étiquette. Mais toutes les autres entrées, y compris les éléments et <lect>, sont les plus heureuses avec un compagnon d'étiquette.</lect>

Ce qui se passe dans une étiquette

Le contenu qui va à l'intérieur d'une étiquette devrait:

• Décrivez son entrée compagnon. Une étiquette veut montrer à tout le monde qu'elle appartient à son partenaire d'entrée.
• Être visible. Une étiquette peut être cliquée ou tapotée pour concentrer son entrée. L'espace supplémentaire qu'il fournit pour interagir avec l'entrée est bénéfique car il augmente la cible Tap ou cliquez sur. Nous allons entrer un peu plus dans cela.
• Ne contiennent que du texte brut. N'ajoutez pas d'éléments comme des titres ou des liens. Encore une fois, nous allons entrer dans le «pourquoi» derrière cela plus loin.

Une chose utile que vous pouvez faire avec le contenu d'une étiquette est d'ajouter des conseils de mise en forme. Par exemple, l'étiquette pour sera comme nous nous attendons. Mais alors nous pouvons fournir un indice pour l'utilisateur que la date doit être saisie dans un format spécifique, disons DD-MM-Yyy, sous la forme d'un entre l'étiquette et l'entrée qui spécifie cette exigence. L'indice spécifie non seulement le format de date, mais a une valeur d'ID qui correspond à un attribut Aria-DescriptedBy sur l'entrée.

 >
 Date de début  label>

<span> (dd-mm-yyyy): </span>
<input type="date" aria-descridby="Date-Format" min="2021-03-01" max="2031-01-01">

De cette façon, nous bénéficions d'une étiquette claire qui décrit à quoi sert l'entrée et un indice de bonus à l'utilisateur que l'entrée doit être saisie dans un format spécifique.

Meilleures pratiques pour une relation saine

Les conseils suivants vont au-delà des bases pour expliquer comment s'assurer qu'une étiquette et une entrée sont aussi heureuses que possible.

Faire: ajouter une étiquette au bon endroit

Il existe un critère de réussite WCAG qui indique que l'ordre visuel d'une page doit suivre l'ordre dans lequel les éléments apparaissent dans le DOM. C'est parce que:

Un utilisateur à basse vision qui utilise une loupe d'écran en combinaison avec un lecteur d'écran peut être confus lorsque l'ordre de lecture semble sauter à l'écran. Un utilisateur de clavier peut avoir du mal à prédire où la mise au point ira ensuite lorsque l'ordre source ne correspond pas à l'ordre visuel.

Pensez-y. Si nous avons un HTML standard où l'étiquette est avant l'entrée:

  Orange 
<input type="checkbox" name="orange">

Cela place l'étiquette avant l'entrée dans le DOM. Mais maintenant, disons que notre étiquette et notre formulaire sont à l'intérieur d'un conteneur flexible et que nous utilisons l'ordre CSS pour inverser les choses où l'entrée est visuellement avant l'étiquette:

 étiquette {Ordre: 2; }
entrée {Ordre: 1; }

Un utilisateur du lecteur d'écran, qui navigue entre les éléments, pourrait s'attendre à ce que l'entrée se concentre avant l'étiquette car l'entrée est en premier visuellement. Mais ce qui se passe vraiment, c'est que l'étiquette se concentre à la place. Voir ici pour la différence entre la navigation avec un lecteur d'écran et un clavier.

Donc, nous devrions en être conscients. Il est conventionnel de placer l'étiquette sur le côté droit de l'entrée pour les cases à cocher et les boutons radio. Cela peut être fait en plaçant l'étiquette après l'entrée dans le HTML, en garantissant le DOM et la commande visuelle.

 <formulaire cochez avec l droite>
  <span>
    <input type="checkbox" name="orange">
     Orange 
  </span>
  
  <span>
    <input type="radio" name="banana">
     banane étique>
  </span>
  
  <span>
     Comment les aimez-vous les pommes? 
    <input type="text" name="Apple">
  </span>
 form></formulaire>

Faire: vérifier les entrées avec un lecteur d'écran

Qu'une entrée soit écrite à partir de zéro ou générée avec une bibliothèque, c'est une bonne idée de vérifier votre travail à l'aide d'un lecteur d'écran. C'est pour s'assurer que:

• Tous les attributs pertinents existent - en particulier les valeurs d'appariement des attributs FOR et ID.
• Le DOM correspond à l'ordre visuel.
• Le texte de l'étiquette semble clair. Par exemple, «dd-mm-yyyy» est lu différemment de son équivalent majuscule (dd-mm-yyy).

Au cours des dernières années, j'ai utilisé des bibliothèques JavaScript, comme Downshift, pour construire des éléments de formulaire complexes tels que la saisie semi-automatique ou les comboboxes sur des éléments HTML natifs, comme les entrées ou les sélections. La plupart des bibliothèques rendent ces éléments complexes accessibles en ajoutant des attributs Aria avec JavaScript.

Cependant, les avantages des éléments HTML natifs améliorés à l'aide de JavaScript sont totalement perdus si JavaScript est cassé ou désactivé, ce qui les rend inaccessibles. Vérifiez donc cela et fournissez une alternative sans serrage et sans javascript en tant que secours sûr.

Consultez ces tests de formulaire de base pour déterminer comment une entrée et son étiquette ou légende complémentaire doivent être écrites et annoncées par différents lecteurs d'écran.

Faire: rendre l'étiquette visible

La connexion d'une étiquette et une entrée est importante, mais tout aussi important est de garder l'étiquette visible. Cliquez sur ou appuyant sur une étiquette visible concentre son partenaire d'entrée. Il s'agit d'un comportement HTML natif qui profite à un grand nombre de personnes.

Imaginez un label qui souhaite montrer fièrement son association avec une contribution:

Cela dit, il y aura des moments où une conception appelle une étiquette cachée. Donc, si une étiquette doit être cachée, il est crucial de le faire de manière accessible. Une erreur courante consiste à utiliser l'affichage: Aucune ou visibilité: cachée pour masquer une étiquette. Ces propriétés d'affichage CSS cachent complètement un élément - non seulement visuellement mais aussi à partir des lecteurs d'écran.

Envisagez d'utiliser le code suivant pour masquer visuellement les étiquettes:

 / * Pour les éléments non indicables. Pour les éléments nativement focalisés * /
/ * Utiliser. Visuellement caché: pas (: focus): pas (: actif) * /
. visuellement caché {
  largeur des frontières: 0! IMPORTANT;
  Clip: rect (1px, 1px, 1px, 1px)! IMPORTANT;
  Hauteur: 1px! IMPORTANT;
  débordement: caché! IMPORTANT;
  rembourrage: 0! IMPORTANT;
  Position: Absolu! IMPORTANT;
  Espace blanc: Nowrap! IMPORTANT;
  Largeur: 1px! IMPORTANT;
}

Kitty Giraudel explique en profondeur comment masquer le contenu de manière responsable.

Que éviter

Pour préserver et maintenir une relation saine entre les intrants et les étiquettes, il y a certaines choses à ne pas faire lors de leur jumelage. Passons à ce que ce sont et comment les empêcher.

Ne faites pas: attendez-vous à ce que votre contribution soit la même dans chaque navigateur

Il existe certains types d'entrées qui ne sont pas pris en charge dans certains anciens navigateurs de bureau. Par exemple, une entrée de type = "Date" n'est pas prise en charge dans Internet Explorer (IE) 11, ou même dans Safari 14 ¹ (publié en septembre 2020). Une entrée comme celle-ci retombe sur type = "texte". Si une entrée de date n'a pas d'étiquette claire et qu'elle retombe automatiquement à une entrée de texte dans les navigateurs plus âgés, les gens peuvent être confus.

Ne pas: remplacer une étiquette avec un espace réservé

Voici pourquoi un attribut d'espace réservé sur une entrée ne doit pas être utilisé à la place d'une étiquette:

• Tous les lecteurs d'écran n'annoncent pas les espaces réservés.
• La valeur d'un espace réservé risque d'être coupé sur des appareils plus petits, ou lorsqu'une page est traduite dans le navigateur. En revanche, le contenu du texte d'une étiquette peut facilement s'envelopper sur une nouvelle ligne.
• Ce n'est pas parce qu'un développeur peut voir le texte d'espace réservé gris pâle sur son grand écran de rétine, dans une pièce bien éclairée, dans un environnement sans distraction, que tout le monde le peut. Un espace réservé peut faire en sorte que même ceux qui ont une bonne vision se frappent les yeux et finissent par abandonner une forme.

• Une fois qu'un personnage est entré dans une entrée, son espace réservé devient invisible - à la fois visuellement et à l'écran des lecteurs. Si quelqu'un doit être en arrière pour revoir les informations qu'il a saisies sous un formulaire, il devrait supprimer ce qui a été entré juste pour revoir l'espace réservé.
• L'attribut de placement n'est pas pris en charge dans IE 9 et ci-dessous, et disparaît lorsqu'une entrée est axée dans IE 11. Une autre chose à noter: la couleur d'espace réservé est incapable d'être personnalisée avec CSS dans IE 11.

Les espaces réservés sont comme l'ami qui se présente quand tout est parfait, mais disparaît lorsque vous en avez le plus besoin. Associez plutôt une entrée avec une belle étiquette à contraste élevé. Les étiquettes ne sont pas squameuses et sont fidèles aux entrées 100% du temps.

Le groupe Nielsen Norman a un article approfondi qui explique pourquoi les espaces réservés dans les champs de forme sont nuisibles.

Ne pas: remplacer une étiquette avec un autre attribut ou élément

Lorsqu'aucune étiquette n'est présente, certains lecteurs d'écran rechercheront du texte adjacent et l'annonceront à la place. Il s'agit d'une approche de délit de fuite car il est possible qu'un lecteur d'écran ne trouve aucun texte à annoncer.

L'échantillon de code ci-dessous provient d'un vrai site Web. L'étiquette a été remplacée par un élément qui n'est pas connecté sémantiquement à l'entrée.

 <div>
  <span> Numéro de carte </span>
  <div>
    <input type="text" value="" name="cardnumber" maxlength="40">
  </div>
</div>

Le code ci-dessus doit être réécrit pour garantir l'accessibilité en remplaçant la portée par une étiquette par pour = "cardnumber" dessus. Il s'agit de loin de la solution la plus simple et la plus robuste qui profite à la plupart des gens.

Bien qu'une étiquette puisse être substituée par une portée qui a un ID avec une valeur correspondant à l'attribut Aria-LarredBy de l'entrée, les gens ne pourront pas cliquer sur la portée pour concentrer l'entrée de la même manière qu'une étiquette le permet. Il est toujours préférable d' exploiter la puissance des éléments HTML natifs au lieu de les réinventer. L'histoire d'amour entre les éléments d'entrée native et d'étiquette n'a pas besoin d'être réécrite! C'est super tel quel.

Ne pas: mettre des éléments interactifs à l'intérieur des étiquettes

Seul le texte brut doit être inclus à l'intérieur d'une étiquette. Évitez d'insérer des éléments tels que des titres ou des éléments interactifs tels que des liens. Tous les lecteurs d'écran n'annonceront pas correctement une étiquette s'il contient autre chose que du texte brut. De plus, si quelqu'un veut concentrer une entrée en cliquant sur son étiquette, mais que cette étiquette contient un lien, il peut cliquer sur le lien par erreur.

 <formulaire>
    
    <input type="checkbox" name="name">
     J'accepte le <a href="https://link.com"> termes et conditions </a>  / labe>
  
  <div>
    
    <input type="checkbox" name="name">
     J'accepte les termes et conditions. étique>
    <span> lire <a href="https://link.com"> termes et conditions </a> </span>
  </div>
 form></formulaire>

Exemples réels

Je trouve toujours que les exemples réels m'aident à comprendre correctement quelque chose. J'ai recherché le Web et trouvé des exemples d'étiquettes et d'entrées d'une bibliothèque et d'un site Web populaires. Ci-dessous, j'explique où les éléments échouent et comment ils peuvent être améliorés pour assurer un meilleur appariement.

Bibliothèque de composants: Matériel

MaterialUi est une bibliothèque de composants React basée sur le système de conception de Google. Il comprend un composant d'entrée de texte avec un modèle d'étiquette flottante qui est devenu un incontournable populaire pour de nombreux concepteurs et développeurs:

Cliquer sur l'entrée est fluide et a fière allure. Mais c'est le problème. Ses qualités sont principalement superficielles.

Au moment de la rédaction de cet article, certains problèmes que j'ai trouvés avec ce composant comprennent:

• Il n'y a pas d'option d'avoir l'étiquette en dehors de l'entrée afin d'offrir une zone interactive accrue pour concentrer l'entrée.
• Il y a une option pour ajouter un indice comme nous l'avons vu plus tôt. Malheureusement, l'indice n'est associé qu'à l'entrée par proximité et non par un ID correspondant et un ARIA décrit par. Cela signifie que tous les lecteurs d'écran ne pourront pas associer le message d'aide à l'entrée.
• L'étiquette est derrière l'entrée dans le DOM, ce qui rend l'ordre visuel est incorrect.
• L'entrée vide semble être déjà remplie, du moins tant qu'elle n'est pas active.
• L'étiquette glisse lorsque l'entrée est cliquée, ce qui le rend inapproprié pour ceux qui préfèrent le mouvement réduit.

Adam Silver explique également pourquoi les étiquettes flottantes sont problématiques et entrent dans une critique détaillée de la conception des entrées de texte de Material.

Site Web: HuffPost

Le site Web de HuffPost dispose d'articles contenant un formulaire d'abonnement à la newsletter:

Au moment de la rédaction de cet article de blog, l'entrée par e-mail utilisée par HuffPost pourrait bénéficier d'un certain nombre d'améliorations:

• L'absence d'une étiquette signifie une cible de clic ou de robinet plus petite. Au lieu d'une étiquette, il y a un attribut Aria-Babel sur l'entrée.
• La taille de la police de l'espace réservé et les valeurs d'entrée est un minuscule 11px, qui peut être difficile à lire.
• L'entrée entière disparaît sans JavaScript, ce qui signifie que les gens n'ont aucun moyen de s'inscrire à la newsletter si JavaScript est désactivé ou cassé.

Remarques de clôture

Un nombre surprenant de personnes ont du mal à saisir des informations dans des intrants mal construits. Cette liste comprend des personnes ayant des troubles cognitifs, moteurs et physiques, des troubles du spectre de l'autisme, des lésions cérébrales et une mauvaise vision. D'autres personnes qui ont du mal incluent celles pressées, sur une mauvaise connexion, sur un petit appareil, sur un ancien appareil et ne connaissant pas les formes numériques, entre autres.

De plus, il existe de nombreuses raisons pour lesquelles le JavaScript pourrait se casser ou être éteint dans un navigateur, ce qui signifie que les entrées deviennent dysfonctionnelles ou complètement inaccessibles. Il y a aussi des gens qui sont pleinement capables de consulter une page Web mais qui peut choisir d'utiliser un clavier avec un lecteur d'écran.

Le message que je veux faire passer est que les paires d'étiquettes et d'entrée heureuses sont cruciales . Peu importe si votre forme est belle si elle est inutilisable. Je peux parier que presque tout le monde préfère remplir une forme laide mais facile à utiliser plutôt qu'une jolie qui cause des problèmes.

Merci

Je tiens à remercier chaleureusement les personnes suivantes de m'avoir aidé avec ce post: Eric Eggert, Adam Silver, Dion Dajka et Kitty Giraudel. Leurs connaissances en accessibilité combinées sont une force avec laquelle il faut compter!

Notes de bas de page

• ¹ Le Datepicker est en fait bien soutenu dans iOS 14 et très agréable. On pourrait imaginer qu'une version macOS doit être à l'horizon. ⮑

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!