label-in-name
Étiquette dans le nom : le nom accessible contient le texte visible
Vérifie que, lorsqu’un contrôle possède une étiquette textuelle visible, son nom accessible contient ce texte d’étiquette visible (WCAG 2.5.3).
Applicabilité. S’applique aux contrôles nommés par aria-label ou aria-labelledby, rendus visuellement, et dont le texte de libellé visible peut être extrait de façon déterministe par ce moteur, à partir d’un <label> associé, du texte rendu du contrôle lui-même, ou des éléments vers lesquels pointe aria-labelledby. Les candidats sont <button>, <a href>, <summary>, les contrôles de formulaire non masqués, et les éléments dont l’attribut role se résout (son premier jeton connu et non abstrait, sans tenir compte de la casse) en rôle button, link, checkbox, radio, switch, searchbox, tab, menuitem, menuitemcheckbox, menuitemradio, option, treeitem ou gridcell, ainsi qu’un <td> sans attribut role dans un grid ou un treegrid, un gridcell selon HTML-AAM, hors éléments masqués ou désactivés. Un <input> de type bouton (submit, reset, button) doté d’une value affiche cette valeur comme libellé ; sans value, il affiche la valeur par défaut du navigateur, qui ne peut pas être connue, et il est hors périmètre. Le libellé visible est le texte interne visible : le texte des éléments en ligne se joint tel qu’écrit (<b>Down</b>load se lit « Download »), une boîte de niveau bloc ou un <br> commence un nouveau mot, et le texte d’une boîte que personne ne peut voir (découpée, de 1x1 px ou entièrement transparente, comme le texte réservé aux lecteurs d’écran) est laissé de côté, de même que les options d’un <select> et le texte d’un <textarea>, qui sont la valeur d’un champ et non un texte de libellé. aria-hidden n’est pas exclu : il ne change rien à ce qui est rendu à l’écran, et c’est précisément l’objet de ce critère. Un aria-label vide une fois les espaces retirés, ou un aria-labelledby dont les ids ne pointent vers rien ou seulement vers des éléments sans texte, ne nomme rien : le nom accessible vient alors de la source suivante (le contenu, un <label>, title...), comme pour un contrôle qui n’en a pas, et le contrôle est donc hors périmètre. Un élément personnalisé auquel ses ElementInternals donnent l’un de ces rôles (this.attachInternals().role), sans attribut role qui en nomme un autre, compte comme un élément natif doté de ce rôle.
Attendu. Le nom accessible contient les mots du libellé visible, adjacents et dans l’ordre. La comparaison porte sur les mots et non sur les caractères : le texte entre parenthèses est ignoré, la casse est neutralisée, le texte est normalisé en NFKC, et tout caractère qui n’est ni une lettre, ni un chiffre, ni une marque combinante devient un séparateur, si bien que les différences de ponctuation et d’espacement ne décident jamais du résultat. Les caractères de mise en forme invisibles (un trait d’union conditionnel, une espace sans chasse) et une apostrophe à l’intérieur d’un mot sont au contraire supprimés, si bien que « Down­load » devient « Download » et « Don’t » devient « Dont ». Les accents ne sont pas neutralisés : « Déposer » reste un seul mot, et un nom qui perd un accent (« Deposer ») ne le contient pas. Quatre cas que le balisage ne peut pas trancher sont signalés comme cantTell au lieu de fail : un mot coupé différemment aux deux endroits ; un mot visible que l’auteur a peut-être abrégé, signalé par son point final ; un texte visible rendu au moyen d’une police d’icônes connue (le texte du DOM est fait de vrais mots, mais rien de lisible ne s’affiche) ; et un libellé visible entier d’exactement un caractère qui n’apparaît même pas dans le nom accessible, qui selon ACT 2ee8b8 peut être un « contenu non textuel » (p. ex. « X » pour « fermer ») plutôt qu’un texte littéral.
Ce que rapporte un constat.
visibleLabel,accessibleName: le texte du libellé visible et le nom accessible, tels que trouvés.normalized.visibleLabel,normalized.accessibleName: les deux mêmes textes tels que comparés : texte entre parenthèses retiré, casse uniformisée, Unicode normalisé.tokenized.visibleLabel,tokenized.accessibleName: les mots en lesquels chaque texte a été découpé, un mot par élément. Le nom doit contenir les mots du libellé côte à côte et dans l’ordre.labelSource: la provenance du libellé visible :label(un<label>associé),self(le texte propre du contrôle),value(la value d’un<input>de type bouton) ouaria-labelledby(les éléments vers lesquels il pointe).nameMechanism: ce qui donne le nom accessible :aria-labelouaria-labelledby.
Ces champs de data.details aident à lire et à reproduire un constat. À part reasonCode et les quelques champs que la page Schéma de sortie donne comme stables, ils ne constituent pas un contrat stable : un champ peut être renommé ou supprimé dans une version mineure, ne vous appuyez donc pas dessus.
Exemples
<button aria-label="Save changes">Save</button>
Le nom accessible (« Save changes ») contient le texte visible (« Save »).
<button aria-label="Submit form">Save</button>
Le nom accessible ne contient pas du tout le texte de l’étiquette visible.
Comment vérifier
Quand cette règle ne peut pas trancher, elle renvoie cantTell et laisse la question à une personne. Chaque question qu’elle peut poser figure ici sous son code de raison, avec les étapes pour y répondre. Un constat porte les mêmes étapes dans howToCheck, dans la langue de l’analyse. Voir Schéma de sortie.
HYPHENATION_DIFFERS
- Lisez l’étiquette visible du contrôle indiqué par le rapport.
- Ouvrez le panneau Accessibilité et lisez le nom accessible du contrôle.
- Comparez les deux : ils ne diffèrent que par la place des traits d’union (« e-mail » contre « email ») ; déterminez si une personne qui prononce l’étiquette visible dirait les mêmes mots.
- Si un logiciel de commande vocale est disponible, prononcez l’étiquette visible et voyez si elle active le contrôle.
Réussite. Le nom contient les mêmes mots que l’étiquette, seule la coupure par trait d’union différant : prononcer l’étiquette permet donc d’atteindre le contrôle.
Échec. Le trait d’union change les mots : le nom ne contient donc pas ce que montre l’étiquette, ce qui ne respecte pas le critère WCAG 2.5.3.
POSSIBLE_ABBREVIATION
- Lisez l’étiquette visible du contrôle indiqué par le rapport et notez le mot qui se termine par un point.
- Ouvrez le panneau Accessibilité et lisez le nom accessible du contrôle.
- Déterminez si le mot de l’étiquette est une abréviation courante du mot présent dans le nom (« Ave. » pour « Avenue ») qu’une personne lirait à voix haute comme le mot complet.
Réussite. L’abréviation est une abréviation conventionnelle, lue comme le mot complet que contient le nom.
Échec. Le mot de l’étiquette ne se lit pas comme le mot du nom : une personne qui prononce l’étiquette ne correspondrait pas au nom, ce qui ne respecte pas le critère WCAG 2.5.3.
POSSIBLE_ICON_FONT_GLYPH
- Regardez à l’écran le contrôle indiqué par le rapport et notez ce qu’il affiche : des mots lisibles ou une icône.
- Ouvrez le panneau Accessibilité et lisez le nom accessible du contrôle.
- Si le contrôle n’affiche qu’une icône, déterminez si le nom la décrit ; s’il affiche des mots lisibles, vérifiez que le nom les contient.
Réussite. Le contrôle affiche une icône plutôt qu’un texte lisible, ou le texte lisible qu’il affiche est contenu dans le nom.
Échec. Le contrôle affiche des mots lisibles que le nom accessible ne contient pas, ce qui ne respecte pas le critère WCAG 2.5.3.
POSSIBLE_SYMBOLIC_CHARACTER
- Regardez le caractère unique qu’affiche le contrôle indiqué par le rapport.
- Ouvrez le panneau Accessibilité et lisez le nom accessible du contrôle.
- Déterminez si ce caractère est un symbole représentant une action (un « X » pour fermer, une flèche) ou un texte littéral qu’un utilisateur prononcerait, comme un chiffre ou une lettre.
Réussite. Le caractère est un symbole, et le nom décrit ce qu’il fait.
Échec. Le caractère est un texte qu’un utilisateur prononcerait (un chiffre ou une lettre) et le nom ne le contient pas, ce qui ne respecte pas le critère WCAG 2.5.3.