invalid-field-error-message
Les champs marqués comme invalides devraient avoir un message d’erreur affiché
Vérifie qu’un élément doté d’aria-invalid a un message d’erreur sous forme de texte : son aria-errormessage devrait nommer un élément affiché qui contient du texte, et un champ sans message lié donne lieu à une question.
Applicabilité. Éléments que la page affiche, présents dans l’arbre d’accessibilité et non désactivés, dont l’aria-invalid indique qu’ils sont invalides : true, ou une valeur qu’ARIA lit comme true (toute valeur autre que false, grammar, spelling ou vide). grammar et spelling marquent du texte, pas une valeur saisie par l’utilisateur.
Attendu. L’erreur est identifiée et décrite à l’utilisateur sous forme de texte (WCAG 3.3.1).
aria-errormessagenomme un élément affiché qui contient du texte : pass.aria-errormessagene nomme que des éléments masqués (ERROR_MESSAGE_HIDDEN) : cantTell, penchant vers fail. ARIA exige que le message soit affiché tant que le champ est invalide, et la page indique qu’il ne l’est pas ; mais, comme pour un message vide, l’erreur peut quand même être indiquée dans le libellé ou à côté du champ, ce qui satisfait au critère 3.3.1.aria-errormessagene nomme que des éléments affichés sans texte (ERROR_MESSAGE_EMPTY) : cantTell. ARIA ne fixe aucune obligation (MUST) sur le texte du message, et l’erreur peut être indiquée dans le libellé ou à côté du champ, ce qui satisfait au critère 3.3.1. Lorsque l’aria-describedbydu champ donne une description, l’erreur peut s’y trouver : cantTell (ERROR_MESSAGE_NOT_SHOWN_DESCRIBED).aria-errormessagene nomme aucun élément de la page : cantTell (ERROR_MESSAGE_TARGET_MISSING) ; un script peut l’ajouter.- Pas d’
aria-errormessage, etaria-describedbydonne une description : pass. - Ni l’un ni l’autre : cantTell (
NO_ERROR_MESSAGE). L’erreur peut se trouver dans le libellé ou dans un texte à côté du champ, que le balisage ne lui associe pas ; vérifiez que l’utilisateur est informé, sous forme de texte, du champ en erreur et de ce qui ne va pas. aria-errormessagenomme un message qui est lui-mêmearia-hiddenou qui se trouve dans un élémentaria-hidden: cantTell, penchant vers fail (ERROR_MESSAGE_HIDDEN, avechiddenBy: 'aria-hidden'). ARIA considère un tel élément comme masqué, et exige qu’un message d’erreur pertinent ne le soit pas.aria-errormessagenomme un message affiché dont tout le texte se trouve dans des élémentsaria-hidden, alors que le message lui-même ne l’est pas : cantTell (ERROR_MESSAGE_ARIA_HIDDEN). Les personnes qui le voient sont informées ; les personnes qui utilisent un lecteur d’écran peuvent ne pas l’être.
Un élément compte comme masqué lorsque personne ne le voit : display: none, visibility: hidden, hidden, un <details> fermé ou content-visibility: hidden sur lui ou sur un ancêtre ; un message masqué avec visibility: hidden dont le texte est rendu visible avec visibility: visible est affiché. Le texte est ce que lit le calcul du nom accessible : l’alt d’une image compte, et un texte masqué à l’intérieur du message ne compte pas. Le message peut être nommé par id ou défini par script comme élément (ariaErrorMessageElements).
Ce que rapporte un constat.
ariaInvalid: la valeur de l’attribut.hiddenBy(ERROR_MESSAGE_HIDDEN) :aria-hiddenlorsque seul aria-hidden masque le message ; absent lorsque personne ne le voit.errorMessageIds: les ids que nommearia-errormessage, ou [] s’il n’y en a aucun.
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
<label for="email">Email</label><input id="email" aria-invalid="true" aria-errormessage="email-error"><p id="email-error">Enter an email address, like name@example.com.</p>
Le champ est marqué comme invalide, et le message que nomme aria-errormessage est affiché et indique ce qui ne va pas.
<label for="email">Email</label><input id="email" aria-invalid="true" aria-errormessage="email-error"><p id="email-error" hidden>Enter an email address, like name@example.com.</p>
Le champ est marqué comme invalide, mais son message d’erreur est masqué. Le résultat penche vers fail : le message associé au champ ne peut être ni vu ni entendu, même si l’erreur peut encore être indiquée dans le libellé ou à côté du champ.
<label for="age">Age</label><input id="age" aria-invalid="true"><p>Age must be a number.</p>
Aucun message n’est associé au champ. Le texte placé à côté peut décrire l’erreur ; une personne vérifie que l’utilisateur est informé, sous forme de texte, du champ en erreur et de la raison.
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.
ERROR_MESSAGE_ARIA_HIDDEN
- Repérez le champ indiqué par le rapport et confirmez que son message d’erreur est visible à l’écran.
- Inspectez l’élément de message vers lequel pointe aria-errormessage et notez lesquels de ses enfants portent aria-hidden="true".
- Donnez le focus au champ avec un lecteur d’écran en marche, ou lisez son message d’erreur et sa description dans le panneau Accessibilité.
- Notez si les mots de l’erreur parviennent au lecteur d’écran par un moyen quelconque.
Réussite. L’utilisateur de lecteur d’écran reçoit le même texte d’erreur que celui affiché à l’écran, par exemple par la description ou le label du champ.
Échec. L’erreur est visible mais masquée aux technologies d’assistance : les utilisateurs de lecteur d’écran n’apprennent pas ce qui ne va pas, ce qui ne respecte pas le critère WCAG 3.3.1.
ERROR_MESSAGE_EMPTY
- Repérez le champ indiqué par le rapport et déclenchez son état d’erreur (soumettez le formulaire ou saisissez une valeur non valide) s’il n’est pas déjà affiché.
- Inspectez le champ et trouvez l’élément vers lequel pointe son attribut aria-errormessage ; confirmez qu’il est vide.
- Cherchez dans le label du champ et dans le texte voisin des mots qui indiquent quel champ est en erreur et ce qui ne va pas.
- Donnez le focus au champ avec un lecteur d’écran en marche, ou vérifiez son nom et sa description dans le panneau Accessibilité, et notez si l’erreur est transmise.
Réussite. Un texte de la page, comme le label ou un message à côté du champ, indique quel champ est en erreur et ce qui ne va pas.
Échec. Aucun texte n’indique à l’utilisateur quel champ est en erreur ni ce qui ne va pas, ce qui ne respecte pas le critère WCAG 3.3.1.
ERROR_MESSAGE_HIDDEN
- Rendez le champ non valide comme le ferait un utilisateur (soumettez le formulaire vide, ou saisissez une valeur erronée).
- Cherchez le message d’erreur vers lequel pointe le champ (son aria-errormessage), et vérifiez s’il apparaît à l’écran.
- Sinon, cherchez tout texte qui indique ce qui ne va pas : dans le label, à côté du champ ou dans un récapitulatif en haut du formulaire.
- Avec un lecteur d’écran, placez-vous sur le champ et écoutez si l’erreur est annoncée.
Réussite. L’erreur est indiquée par un texte, et annoncée, à un endroit rattaché au champ, même si ce n’est pas dans le message que désigne aria-errormessage.
Échec. Aucun texte n’indique quel champ est erroné ni pourquoi, ou l’utilisateur de lecteur d’écran n’en est pas informé, ce qui ne respecte pas le critère WCAG 3.3.1.
ERROR_MESSAGE_NOT_SHOWN_DESCRIBED
- Repérez le champ indiqué par le rapport et déclenchez son état d’erreur s’il n’est pas déjà affiché.
- Ouvrez le panneau Accessibilité pour le champ et lisez sa description (issue de aria-describedby).
- Comparez cette description avec l’erreur : déterminez si elle dit ce qui ne va pas, ou si ce n’est qu’un texte d’aide comme un format de saisie.
- Vérifiez que le même texte d’erreur est visible à l’écran près du champ.
Réussite. La description du champ, ou un autre texte visible, énonce l’erreur en toutes lettres : les utilisateurs voyants comme ceux de lecteur d’écran apprennent ce qui ne va pas.
Échec. La description n’est qu’un texte d’aide et aucun texte visible ne décrit l’erreur, ce qui ne respecte pas le critère WCAG 3.3.1.
ERROR_MESSAGE_TARGET_MISSING
- Repérez le champ indiqué par le rapport et notez l’id présent dans son attribut aria-errormessage.
- Déclenchez l’erreur (soumettez le formulaire ou saisissez une valeur non valide) et cherchez dans le panneau Éléments un élément portant cet id.
- Si l’élément apparaît, vérifiez qu’il est affiché et qu’il contient un texte décrivant l’erreur.
- S’il n’apparaît jamais, cherchez près du champ ou dans son label un autre texte visible qui dit ce qui ne va pas.
Réussite. Une fois le champ en erreur, un message affiché portant cet id, ou un autre texte visible, décrit l’erreur.
Échec. Le champ est marqué comme non valide mais aucun texte ne décrit l’erreur, ce qui ne respecte pas le critère WCAG 3.3.1.
NO_ERROR_MESSAGE
- Repérez le champ indiqué par le rapport ; il est marqué aria-invalid.
- Vérifiez si le champ est réellement en erreur à ce moment ; s’il est marqué non valide avant que l’utilisateur ait saisi quoi que ce soit, saisissez une valeur valide et voyez si la marque disparaît.
- Cherchez dans le label du champ, dans le texte voisin et dans tout récapitulatif d’erreurs de la page des mots qui nomment ce champ et disent ce qui ne va pas.
- Donnez le focus au champ avec un lecteur d’écran en marche et notez si l’erreur est annoncée.
Réussite. Un texte visible identifie le champ en erreur et décrit ce qui ne va pas, ou le champ n’est pas réellement en erreur.
Échec. Le champ est en erreur mais aucun texte ne l’identifie ni ne décrit le problème, ce qui ne respecte pas le critère WCAG 3.3.1.