aria-conditional-attr
aria-errormessage exige qu’aria-invalid ait une valeur autre que false
Vérifie que les éléments dotés d’aria-errormessage ont aussi aria-invalid défini à « true », « grammar » ou « spelling » ; sinon, le message d’erreur disparaît de l’arbre d’accessibilité.
Applicabilité. Éléments dotés d’un attribut aria-errormessage non vide.
Attendu. Selon la spécification ARIA, aria-errormessage n’est exposé aux technologies d’assistance que si aria-invalid est présent avec une valeur autre que "false" (c.-à-d. "true", "grammar" ou "spelling"). Un élément doté d’aria-errormessage mais sans aria-invalid, ou avec "false", fait disparaître silencieusement le message d’erreur de l’arbre d’accessibilité, alors que les auteurs veulent presque toujours qu’il soit exposé. Signalé en cantTell plutôt qu’en fail : aria-errormessage n’est exposé qu’une fois aria-invalid défini, donc la référence est pour l’instant inerte. Que l’utilisateur y perde ou non dépend de la transmission éventuelle du message par un autre moyen (texte visible à côté du champ, aria-describedby), ce que le balisage statique ne permet pas de trancher.
Ce que rapporte un constat.
ariaInvalid: la valeuraria-invalidde l’élément, en minuscules ; une chaîne vide lorsque l’attribut est absent.
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
<input type="text" aria-invalid="true" aria-errormessage="err1"><span id="err1">Enter a valid email address.</span>
Avec aria-invalid="true", aria-errormessage est réellement exposé aux technologies d’assistance.
<input type="text" aria-errormessage="err1"><span id="err1">Enter a valid email address.</span>
Sans aria-invalid défini à une valeur autre que "false", aria-errormessage n’est jamais exposé : la référence est pour l’instant inerte.
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.
ARIA_ERRORMESSAGE_WITHOUT_TRUTHY_INVALID
- Inspectez le champ indiqué par le rapport et notez l’id présent dans son aria-errormessage.
- Saisissez une valeur non valide (ou laissez vide un champ obligatoire) puis soumettez le formulaire ou quittez le champ, afin que l’erreur éventuelle s’affiche.
- Regardez si l’élément portant cet id affiche maintenant un texte d’erreur, et inspectez de nouveau le champ pour voir s’il a aria-invalid="true".
- Avec un lecteur d’écran, revenez sur le champ et écoutez si le message d’erreur est annoncé.
- Si vous n’entendez pas l’erreur sur le champ, vérifiez si la page la lit autrement, par exemple dès que le message apparaît, sans que vous déplaciez le focus. Cela ne compte que si le lecteur d’écran annonce le message en entier.
Réussite. Quand l’erreur s’affiche, le lecteur d’écran l’annonce, soit sur le champ (aria-invalid="true" ou le message dans aria-describedby), soit dès qu’elle apparaît ; sans erreur affichée, rien n’est à exposer.
Échec. Le texte d’erreur est visible mais aria-invalid reste absent ou à false, et le lecteur d’écran n’annonce le message ni sur le champ ni à son apparition, ce qui ne respecte pas le critère WCAG 3.3.1 / 4.1.2 (voir ARIA21).