aria-braille-equivalent
aria-braillelabel/aria-brailleroledescription doivent avoir un équivalent non braille
Vérifie que les éléments qui utilisent aria-braillelabel ont aussi un nom accessible ordinaire, et que ceux qui utilisent aria-brailleroledescription ont aussi aria-roledescription.
Applicabilité. Éléments dotés d’un attribut aria-braillelabel non vide et/ou d’un attribut aria-brailleroledescription non vide.
Attendu. Selon la spécification ARIA, aria-braillelabel est un COMPLÉMENT propre au braille (et non un remplacement) du nom accessible ordinaire de l’élément, et aria-brailleroledescription est un complément à aria-roledescription. Un élément doit donc aussi avoir :
- un nom accessible non vide issu d’un mécanisme non braille, s’il déclare
aria-braillelabel; - un
aria-roledescriptionnon vide, s’il déclarearia-brailleroledescription.
Utiliser l’un de ces attributs propres au braille comme SEUL mécanisme de nommage laisse les technologies d’assistance non braille (la plupart des lecteurs d’écran, la commande vocale, etc.) sans aucun nom accessible ni description de rôle. Signalé en cantTell plutôt qu’en fail : aria-brailleroledescription sans aria-roledescription n’atteint aucun utilisateur, et un nom accessible manquant relève des règles de nommage pour les rôles qui en exigent un. Un attribut braille non apparié mérite d’être signalé, mais ce n’est pas en soi un critère en échec.
Ce que rapporte un constat.
attr: l’attribut braille qui n’a pas d’équivalent :aria-braillelabelouaria-brailleroledescription.requires: ce dont l’élément a aussi besoin : « an accessible name » (un nom accessible) pouraria-braillelabel,aria-roledescriptionpouraria-brailleroledescription.
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-braillelabel="SAVE">Save changes</button>
Le libellé braille complète un vrai nom accessible (« Save changes ») ; les technologies d’assistance non braille obtiennent quand même un nom.
<button aria-braillelabel="SAVE"></button>
aria-braillelabel est le seul mécanisme de nommage présent ; les technologies d’assistance non braille n’obtiennent aucun nom accessible.
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.
BRAILLE_ATTR_WITHOUT_EQUIVALENT
- Inspectez l’élément indiqué par le rapport et notez s’il possède aria-braillelabel ou aria-brailleroledescription.
- S’il possède aria-braillelabel, ouvrez le panneau Accessibilité des outils de développement du navigateur et lisez le nom accessible de l’élément.
- Si son rôle exige un nom (bouton, lien, image, case à cocher, etc.), confirmez qu’un nom existe en plus de l’étiquette braille ; avec un lecteur d’écran en mode vocal, écoutez-le.
- S’il possède aria-brailleroledescription, vérifiez s’il a aussi aria-roledescription ; sinon, confirmez que le rôle natif est toujours annoncé et que rien d’autre n’était voulu.
Réussite. L’élément a un nom prononcé (et une roledescription lorsqu’une description braille est fournie), ou son rôle n’exige pas de nom et rien n’est perdu.
Échec. Un contrôle ou une image n’a qu’une étiquette braille : les utilisateurs de la synthèse vocale n’obtiennent aucun nom, ce qui ne respecte pas le critère WCAG 4.1.2.