Quoi de neuf dans WCAG 2.1: étiquette dans le nom

WCAG 2.1, publié en 2018, a introduit plusieurs nouveaux critères de réussite, améliorant l'accessibilité Web. Cet article se concentre sur "Label in Name" (2.5.3), un aspect crucial de l'étiquetage des composants de l'interface utilisateur. Nous explorerons les pièges, les solutions et les meilleures pratiques courantes.

Comprendre les critères de réussite

Un critère de réussite est une déclaration testable et agnostique technologique définissant la conformité à l'accessibilité. "Label in Name" évalue si l'étiquette visuelle d'un composant correspond à son nom programmatique. Il fait partie de la catégorie "opérable" de WCAG 2.1, abordant spécifiquement les modalités d'entrée. Surtout, WCAG 2.1 est compatible en arrière avec WCAG 2.0.

Étiquette au nom: Visual vs programmatique

WCAG 2.5.3 (niveau A) déclare: "Pour les composants de l'interface utilisateur avec des étiquettes qui incluent du texte ou des images de texte, le nom contient le texte présenté visuellement."

Cela garantit la cohérence entre l'étiquette visuellement présentée et le nom programmatique du composant (nom accessible). Cette cohérence est vitale pour les utilisateurs de technologies d'assistance comme les lecteurs d'écran et les logiciels de reconnaissance vocale. Les noms visuels et programmatiques n'ont pas besoin d'être identiques, mais ils doivent partager un terme commun et associé (par exemple, "soumettre" et "soumettre le formulaire"). Les écarts créent une confusion et entraver l'accessibilité.

Implications de la technologie d'assistance

Considérez un formulaire de contact HTML. Un utilisateur utilisant la reconnaissance vocale peut rencontrer un bouton avec le texte visuel "envoyer" mais un nom programmatique de "soumettre". Ce décalage est un échec. L'utilisateur, en s'appuyant sur l'étiquette visuelle, ne peut pas activer le bouton à l'aide des commandes de la parole. La correspondance des noms visuels et programmatiques ("envoyer" dans les deux cas) résout ce problème. Si l' aria-label n'ajoute aucune valeur, le supprimer est préférable.

Les utilisateurs du lecteur d'écran bénéficient également d'un étiquetage cohérent. Entendre un texte similaire à ce qu'ils voient améliore la convivialité. À l'inverse, les étiquettes incompatibles peuvent conduire à une activation accidentelle des contrôles via une entrée vocale ou une confusion pour les utilisateurs qui naviguent via des lecteurs d'écran. Le critère ne s'applique pas aux composants dépourvus d'étiquettes visuelles.

Exemples de code: états de défaillance et corrections

L'article présente trois scénarios d'échec:

1. Une déconnexion entre les étiquettes parlées et visuelles.
2. Un décalage d'étiquette dû à une portée "accessiblement cachée" ajoutant du texte supplémentaire à l'étiquette parlée.
3. Une contribution avec un attribut aria-labelledby ne faisant pas d'établissement d'une corrélation entre les étiquettes parlées et visuelles.

Ces exemples mettent en évidence les erreurs courantes. L'article fournit ensuite des extraits de code corrigés pour chaque scénario.

Une étude de 2020 WebAiM a révélé que 55% des 4,2 millions d'entrées de formulaires étaient mal étiquetées.

Ajouter à un étiquette approprié en utilisant<label></label> Les éléments sont cruciaux, mais le nom programmatique (nom accessible) via aria-label est tout aussi important. Incohérences entre<label></label> Le texte et aria-label créent une surcharge cognitive pour les utilisateurs ayant des handicaps cognitifs et des utilisateurs d'entrée de la parole.

Placement d'étiquette et spécificité du texte

L'article précise que le texte n'est pas considéré comme une étiquette visuelle s'il est utilisé symboliquement plutôt que littéralement. Les éditeurs de texte riches, utilisant souvent des images comme texte, illustrent cela.

Pour la cohérence, l'étiquette visuellement proximée doit être considérée comme le texte de l'étiquette. Les directives de placement optimales comprennent:

• Gauche des entrées de texte et des caisses.
• Droits des cases à cocher et des boutons radio.
• Boutons ou onglets à l'intérieur, ou en dessous des boutons d'icônes.

Les variations mineures de ponctuation et de capitalisation sont acceptables sinon symboliques.

Les composants sans étiquettes visuelles sont exclus de ce critère de réussite.

Avantages d'un étiquetage approprié

L'étiquetage cohérent permet aux utilisateurs de l'entrée de la parole d'activer les contrôles de manière transparente, éliminant les conjectures. La conception inclusive profite à tous les utilisateurs, créant une expérience plus agréable et accessible.

Conclusion et test

L'article résume WCAG 2.5.3, mettant l'accent sur son importance malgré une simplicité. Il met en évidence l'exigence de conformité au niveau A: s'assurer que le nom programmatique contient le texte présenté visuellement.

Les tests peuvent être effectués à l'aide d'outils de développeur de navigateur (Chrome Devtools, outils de développeur Firefox) ou d'outils d'audit d'accessibilité comme Wave et AX. L'adhésion à ce critère, bien qu'apparemment mineur, améliore considérablement l'accessibilité pour tous les utilisateurs.

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!