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.
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
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
Le contenu qui va à l'intérieur d'une étiquette devrait:
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.
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.
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>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:
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.
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.
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.
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 1 (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.
Voici pourquoi un attribut d'espace réservé sur une entrée ne doit pas être utilisé à la place d'une étiquette:
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.
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.
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>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.
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:
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.
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:
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.
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!
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!
Application de plateforme de trading Ouyi
Méthode d'implémentation de la fonction de lecture en ligne Python
Que comprend le stockage par cryptage des données ?
Le rôle de la fonction de validation
Récupération de données sur disque SSD
Quelle est la différence entre webstorm et idée ?
Méthode de requête de nom de domaine de deuxième niveau
Quelle est la limite de transfert d'Alipay ?
Que dois-je faire si eDonkey Search ne parvient pas à se connecter au serveur ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
