Les humbles <label>. C'est courant. C'est clair. C'est basique. C'est banal. Sur son visage, il n'y a rien de spécial à ce sujet. Souvent utilisé comme simple cible pour CSS pour styliser du texte. Que reste-t-il à savoir ? Frappez ce petit gars au-dessus de votre champ de formulaire et nous revenons au Javascript pour CSS pour rendre notre page dynamique et excitante, n'est-ce pas ?

Peut-être pas.

Préambule

Je parierais une somme pratique que presque tous les professionnels ayant accès à un serveur HTTP ont écrit sur les étiquettes. Il serait facile d'appeler cela battre un cheval mort, mais selon le rapport WebAIM Million de 2023 , sur le million de pages d'accueil les plus importantes sur Internet, 96,3 % d'entre elles avaient au moins une erreur d'accessibilité détectée, et de ces pages 45,9 % contenait des erreurs avec les étiquettes de formulaire. Cela le place au 4ème problème d'accessibilité le plus courant après un contraste de couleur insuffisant, des images sans texte alternatif et des liens sans nom accessible. Les deux chiffres ont eu tendance à baisser au cours des 5 dernières années, mais il reste encore beaucoup de travail à faire pour les faire baisser. Si ce message fait penser à au moins une personne "Woah, je ne le savais pas", je considérerai cela comme un succès retentissant

Le but d'une étiquette

Lorsque nous pensons à une étiquette dans le cadre d'une application Web, nous imaginons probablement un formulaire, adjacent à des éléments tels que des champs de texte, des boutons radio, des cases à cocher, etc. Ils transmettent des valeurs attendues comme des noms et des dates ou ce que d'autres sélections représentent. Visuellement, cela a du sens, mais il y a plus en jeu.

Pourquoi est-ce important

Lorsque nous épluchons le terme monolithique "utilisateurs", nous devons comprendre que les utilisateurs sont des personnes. Les gens sont uniques et complexes, et cela peut se perdre dans le monde trépidant du développement de logiciels. Concevoir avec l'inclusivité à l'esprit nécessite un changement mental ; lorsque nous n'imaginons que l'utilisateur "moyen" comme cible, nous courons le risque d'exclure des pans entiers de personnes de nos applications. Les personnes handicapées portent le poids de cette exclusion, mais il n'est pas nécessaire qu'il en soit ainsi.

Et la bonne nouvelle : les étiquettes accessibles sont faciles. Je dirais qu'il s'agit de l'une des « victoires » d'accessibilité les plus faciles qu'une équipe puisse obtenir. Plongeons-nous et apprenons ce qui rend une étiquette accessible et, tout aussi important, utilisable.

Rendons-le accessible

Imaginez deux personnes avec des situations différentes.

Jérémie a 41 ans. Il travaille comme conseiller financier dans une banque locale. Il aime nager, faire de la randonnée et camper avec ses amis et sa famille. Jeremy est également aveugle, à la suite de complications d'une opération au cerveau au début de la trentaine. Jeremy utilise un lecteur d'écran pour interagir avec la technologie à la fois en fonction de son travail et de ses loisirs.

Violette a 73 ans. Elle a pris sa retraite après une brillante carrière d'avocate. À sa retraite, elle a parcouru le monde pour visiter des sites historiques et les villes natales de ses parents, qui étaient des immigrants d'Europe de l'Est. Elle a récemment déménagé pour vivre plus près de ses petits-enfants. Violet a de l'arthrite dans les deux mains. Elle préfère utiliser un logiciel de reconnaissance vocale pour interagir avec son ordinateur et son téléphone afin d'éviter des douleurs inutiles.

Jeremy et Violet essaient tous deux d'utiliser la même page Web : un portail patient sur le site Web de leur fournisseur de soins de santé, qui offre la possibilité de payer des factures médicales, de mettre à jour leurs informations personnelles, de prendre des rendez-vous, etc.

Le problème de Jeremy :

"Je dois utiliser ma carte de crédit pour payer ma facture médicale, mais je ne peux pas dire à quoi correspondent les champs de la page de paiement."

Si les étiquettes ne sont pas correctement associées aux éléments de formulaire, un lecteur d'écran ne lira que le type d'élément, et non le texte à proximité.

Le problème de Violette :

"J'ai besoin de changer mon adresse sur mon dossier mais peu importe ce que je dis à l'ordinateur, le bouton Enregistrer ne clique pas."

Comme dans l'exemple de lecteur d'écran ci-dessus, le logiciel de reconnaissance vocale s'appuie également sur une association d'étiquettes appropriée pour naviguer et activer les champs et les boutons du formulaire.

C'est exact. Ces deux problèmes sont causés par des éléments de formulaire mal étiquetés. Examinons un code qui produit généralement ces résultats.

Le problème de Jeremy dans le code

Examinons le formulaire de paiement :

<form>
  <label>Card Number</label>
  <input type=”text” id=”card-number” />
  <label>Expiration Date</label>
  <input type=”text” id=”expiration-date”/>
  <label>Security Code</label>
  <input type=”text” id=”security-code”/>
  <button type=”submit” id=”submit”>Submit</button>
</form>

L' forattribut

Le plus simple est d'utiliser l' forattribut. C'est un attribut natif de l' <label>élément. Sa valeur attendue est l' idattribut de l'élément de formulaire cible. Dans notre exemple, nous avons trois entrées avec ids : card-number, expiration-dateet security-code. Nous pouvons ajouter l' forattribut aux étiquettes et définir leur valeur sur l'ID d'entrée correspondant. Voyons à quoi ça ressemble.

<form>
  <label for=”card-number”>Card Number</label>
  <input type=”text” id=”card-number” />
  <label for=”expiration-date”>Expiration Date</label>
  <input type=”text” id=”expiration-date”/>
  <label for=”security-code”>Security Code</label>
  <input type=”text” id=”security-code”/>
  <button type=”submit” id=”submit”>Submit</button>
</form>

Certaines choses à garder à l'esprit

• L' forattribut doit être sur l' <label>élément, pas sur l'entrée.
• L'élément d'entrée doit avoir un idattribut. Le <label>peut toujours avoir son propre idattribut, mais il n'est pas pertinent ici.
• La relation entre l'étiquette et l'entrée est un à un.

Utiliser ARIA

ARIA est un ensemble puissant d'attributs qui peuvent être ajoutés aux éléments pour informer les technologies d'assistance du nom, de l'état et du rôle d'un élément. Dans notre cas, nous pouvons utiliser l'attribut aria-labelledby pour associer une étiquette à une entrée. Regardons comment cela fonctionne.

<form>
  <label id="card-number-label">Card Number</label>
  <input type="text" aria-labelledby="card-number-label" />
  <label id="expiration-date-label">Expiration Date</label>
  <input type="text" aria-labelledby="expiration-date-label"/>
  <label id="security-code-label">Security Code</label>
  <input type="text" aria-labelledby="security-code-label"/>
  <button type="submit" id="submit">Submit</button>
</form>

<form>
 <label id=”card-number-label”>Card Number</label>
 <label id=”card-number-instructions”>Enter the 16 digit number on the front of your card</label>
 <input type=”text” id=”card-number” aria-labelledby=”card-number-label card-number-instructions”/>
 ...
</form>

Maintenant que nous avons résolu le problème auquel Jeremy était confronté, examinons ce qui ne va pas avec la page utilisée par Violet.

Le problème de Violet dans le code

La page que Violet utilise contient des champs de formulaire pour ses informations de contact et des boutons dans une barre d'outils pour exécuter des fonctions d'enregistrement et d'annulation. Ces deux boutons sont représentés uniquement par des icônes, sans étiquette textuelle visible. Cela en soi peut être amélioré, mais dans le monde réel, c'est une situation courante à rencontrer.

Voici notre code avec le problème.

<form>
  <label for=”address1">Address 1</label>
  <input type=”text” id=”address1" />
  <label for=”address2">Address 2</label>
  <input type=”text” id=”address2"/>
  <button type=”button” id=”save” class=”icon-only”></button>
  <button type=”button” id=”cancel” class=”icon-only”></button>
</form>

Utiliser ARIA (encore)

L' aria-labelattribut peut être utilisé pour fournir directement un nom accessible à la plupart des éléments HTML. Sa valeur est le texte qui est exposé aux technologies d'assistance. Cela devrait être un langage humain, car les lecteurs d'écran annonceront le texte de l'étiquette aria et les utilisateurs du logiciel de reconnaissance vocale l'utiliseront pour interagir avec l'élément.

<form>
  <label for=”address1">Address 1</label>
  <input type=”text” id=”address1" />
  <label for=”address2">Address 2</label>
  <input type=”text” id=”address2"/>
  <button type=”button” id=”save” class=”icon-only” aria-label=”Save”></button>
  <button type=”button” id=”cancel” class=”icon-only” aria-label=”Cancel”></button>
</form>

Il y a beaucoup de nuances avec aria-label mais elles méritent leur propre article. Pour notre exemple simple, cela suffira. Veillez simplement à ne pas abuser aria-label when d' or aria-labelledby would do the same job.

Nous sommes accessibles maintenant !

Avec ces simples changements, Jeremy et Violet peuvent accomplir la tâche qu'ils se sont fixés sur leurs pages respectives. Grâce à ces techniques, nous nous sommes assurés que les éléments du formulaire sont correctement identifiés par les technologies d'assistance et que les informations sont transmises aux personnes qui les utilisent. Collez-y un autocollant Accessible™ et arrêtez-vous.

… Mais nous pouvons faire mieux

Nous ne devons jamais nous arrêter au point où nous cochons simplement la case à côté des critères de réussite WCAG 2.1. WCAG établit une base de référence pour éliminer les obstacles pour les personnes handicapées lors de l'utilisation du Web, mais nous devons toujours nous efforcer de faire mieux que simplement "possible à utiliser" et viser "agréable à utiliser". L'accessibilité et la convivialité vont de pair, et il existe une technique très simple que nous pouvons déployer pour améliorer considérablement l'expérience des utilisateurs qui remplissent des formulaires.

Notre nouveau personnage

Imaginons quelqu'un auquel vous ne pensez peut-être pas immédiatement lorsque vous entendez le mot « accessibilité ».

Mia est une étudiante de première année à l'Université de Floride centrale qui poursuit un diplôme en astrophysique. C'est une étudiante très brillante et une travailleuse assidue. Son souci du détail et son sens aigu de la mode font d'elle l'experte incontournable lorsque l'une de ses amies met à jour sa garde-robe. En emménageant dans son dortoir et en déballant une boîte, elle a accidentellement tranché l'index de sa main dominante avec un cutter.

Certains handicaps sont temporaires. Même une petite blessure peut réduire l'amplitude de mouvement d'une personne, rendant les tâches qu'elle tenait pour acquises considérablement plus difficiles. Avec son doigt coupé dans un bandage de gaze, Mia doit utiliser son téléphone d'une manière à laquelle elle n'est pas habituée.

Le problème de Mia

"Je dois entrer mes informations de santé sur le site de ce médecin, mais je coche les mauvaises cases car mon téléphone est difficile à utiliser !"

Il peut être difficile d'interagir avec des champs tels que les cases à cocher et les boutons radio sur les téléphones dans le meilleur des cas, mais même avec une blessure courante, cela peut rapidement dégénérer en frustration. Mia doit cocher des cases à côté des médicaments thyroïdiens qu'elle prend pour fournir ses antécédents médicaux, mais devoir le faire avec son autre main ou un autre doigt s'avère difficile en raison de la petite taille de l'élément.

Le problème de Mia dans le code

Regardons les cases à cocher. À première vue, ils semblent accessibles, avec des associations d'étiquettes appropriées. Mais regardons de plus près.

<form>
  <label for=”synthroid”>Synthroid</label>
  <input type=”checkbox” id=”synthroid” name=”medications” value=”synthroid”/>
  <label for=”levothroid”>Levothroid</label>
  <input type=”checkbox” id=”levothroid” name=”medications” value=”levothroid”/>
  <label for=”levoxyl”>Levoxyl</label>
  <input type=”checkbox” id=”levoxyl” name=”medications” value=”levoxyl”/>
</form>

Il existe une technique très simple que nous pouvons utiliser lorsque les contrôles de formulaire ont des étiquettes visibles pour augmenter leur zone cliquable ou tappable, également appelée taille cible . Tout ce que nous avons à faire est de placer le contrôle de formulaire à l'intérieur de l' <label>élément. Si un contrôle de formulaire est l'enfant d'un, <label>cliquer ou appuyer sur l'étiquette activera son champ de formulaire associé. Regardons ce changement maintenant.

<form>
  <label for=”synthroid”>
  Synthroid
  <input type=”checkbox” id=”synthroid” name=”medications” value=”synthroid”/>
  </label>
  <label for=”levothroid”>
  Levothroid
  <input type=”checkbox” id=”levothroid” name=”medications” value=”levothroid”/>
  </label>
  <label for=”levoxyl”>
  Levoxyl
  <input type=”checkbox” id=”levoxyl” name=”medications” value=”levoxyl”/>
  </label>
</form>

Quelques détails sur cette technique particulière

• C'est une caractéristique de l' <label>élément natif. Si vous étiquetez des champs de formulaire avec des éléments comme <span>(et vous ne devriez pas l'être !), vous n'obtenez pas cette fonctionnalité gratuitement et vous devrez l'implémenter manuellement.
• Cette fonctionnalité n'est applicable que si l' <label><élément encapsule son champ de formulaire. L'utilisation aria-labelledbyne vous donne pas automatiquement le même comportement.
• L' <label>élément doit toujours contenir l' forattribut et il doit correspondre à l' idattribut du champ de formulaire.
• N'enveloppez pas plusieurs entrées dans une seule étiquette.

Avant de partir

Rencontrons un autre personnage. Encore une fois, probablement pas quelqu'un à qui vous penseriez lorsque vous envisagez l'accessibilité.

Ben est architecte logiciel dans une startup technologique à San Francisco. Son entreprise travaille à la création du gaufrier du futur. Parfaitement croustillant à chaque fois, et vous aide également à faire vos impôts. Il est amoureux du projet et passe la majeure partie de sa journée éveillée à réfléchir à la façon dont il peut l'améliorer encore. Ben prend un bus pour se rendre en ville lorsqu'il doit se rendre au bureau. Il n'a aucun handicap.

Ben, avec son esprit blazer concentré sur le gaufrier, a oublié qu'il devait remplir le même formulaire que Mia pour son propre rendez-vous chez le médecin. Lui aussi utilise son téléphone pour remplir le formulaire. La circulation est discontinue, de sorte que le bus avance de manière inattendue pendant qu'il travaille.

Étant donné que les tailles cibles ont été agrandies dans les champs du formulaire de médicaments, Ben peut facilement remplir le formulaire. Il n'a pas à s'inquiéter de cliquer sur la mauvaise case à cocher ou d'appuyer sur le mauvais bouton radio. La pensée ne lui vient même pas à l'esprit. Il est capable de terminer le formulaire et de se remettre à penser aux gaufres.

Maintenant, nous concevons universellement !!

Dans cet article, nous avons vu comment un simple formulaire peut présenter des obstacles pour les personnes handicapées et comment nous pouvons utiliser l'élément <label> pour supprimer ces obstacles. Nous avons également vu comment un simple changement peut rendre le formulaire plus facile à utiliser pour les personnes handicapées et non handicapées. C'est l'essence de la conception universelle. En tenant compte des besoins des personnes handicapées, nous pouvons améliorer nos applications pour tout le monde.

Merci pour la lecture. J'espère que vous avez appris quelque chose de nouveau ou que vous vous êtes souvenu de quelque chose que vous avez peut-être oublié.