aria-role-name-present
Les rôles ARIA qui exigent un nom accessible en ont un
Vérifie que les rôles ARIA pour lesquels WAI-ARIA exige un nom accessible en exposent un non vide.
Applicabilité. S’applique aux éléments dont l’attribut role se résout en grid, meter, progressbar, radiogroup ou tree (son premier jeton désignant un rôle connu, sans tenir compte de la casse : role="foo tree" et role="TREE" comptent, role="link tree" non), et qui sont inclus dans l’arbre d’accessibilité. L’appartenance est déterminée par la caractéristique propre de WAI-ARIA « Accessible Name Required: True », et non par le simple fait qu’un rôle autorise un nom : tablist, toolbar, menu, menubar et scrollbar sont des rôles à nom fourni par l’auteur pour lesquels la spécification n’exige pas de nom, et sont hors périmètre. meter et progressbar sont aussi couverts par meter-name-present et progressbar-name-present, associés au critère 1.1.1 ; c’est cette règle qui apporte à ces deux rôles leur couverture 4.1.2. 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, est lui aussi dans le périmètre : c’est son rôle par défaut, et aucune autre règle ne le vérifie.
Attendu. L’élément a un aria-label non vide, un aria-labelledby qui se résout en texte non vide, ou un title non vide. Tous les rôles de l’ensemble tirent leur nom uniquement de l’auteur, donc le texte des descendants n’est pas accepté : sinon, un enfant libellé à l’intérieur d’un widget composite ferait réussir le conteneur qui n’a pas de nom propre. Le nom que l’élément HTML hôte se donne lui-même compte aussi, puisque le navigateur le calcule toujours sous ce rôle : le premier <legend> enfant d’un <fieldset>, le premier <caption> enfant d’une <table>, et un <label> associé sur un élément pouvant être libellé comme <progress> ou <meter>.
Ce que rapporte un constat.
role: le rôle qui exige un nom, parmigrid,meter,progressbar,radiogroupettree. Un contrat stable, contrairement au reste dedata.details.
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
<div role="grid" aria-label="Orders"></div>
role="grid" exige un nom accessible, et aria-label en fournit un.
<div role="grid"></div>
role="grid" exige un nom accessible ; aucun n’est présent.
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.
name_internals
- Inspectez l’élément personnalisé indiqué par le rapport et notez son rôle.
- Ouvrez le panneau Accessibilité des outils de développement du navigateur et lisez le nom accessible de l’élément.
- Avec un lecteur d’écran, placez-vous sur l’élément et écoutez le nom annoncé.
Réussite. L’arbre d’accessibilité montre un nom pour l’élément, défini par ses internals ou autrement, et le lecteur d’écran l’annonce.
Échec. L’élément n’a pas de nom dans l’arbre d’accessibilité et le lecteur d’écran n’annonce que son rôle, ce qui ne respecte pas le critère WCAG 4.1.2.