RGAA Lab

RGAA 4.1.2 · Formulaires · Critère 11.10

Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente (hors cas particuliers) ?

Un formulaire qui refuse une saisie sans dire lequel des douze champs pose problème, ni pourquoi, laisse l'utilisateur devant un mur — et ce mur tombe d'abord sur qui ne voit pas la bordure rouge.

Ce que dit le référentiel

Transcription du RGAA 4.1.2, sans interprétation. C’est ce texte qui fait foi, et celui que vous citez dans un rapport.

  1. 11.10.1
    Les indications du caractère obligatoire de la saisie des champs vérifient-elles une de ces conditions (hors cas particuliers) ?
    • Une indication de champ obligatoire est visible et permet d’identifier nommément le champ concerné préalablement à la validation du formulaire ;
    • Le champ obligatoire dispose de l’attribut aria-required="true" ou required préalablement à la validation du formulaire.
  2. 11.10.2
    Les champs obligatoires ayant l’attribut aria-required="true" ou required vérifient-ils une de ces conditions ?
    • Une indication de champ obligatoire est visible et située dans l’étiquette associée au champ préalablement à la validation du formulaire ;
    • Une indication de champ obligatoire est visible et située dans le passage de texte associé au champ préalablement à la validation du formulaire.
  3. 11.10.3
    Les messages d’erreur indiquant l’absence de saisie d’un champ obligatoire vérifient-ils une de ces conditions ?
    • Le message d’erreur indiquant l’absence de saisie d’un champ obligatoire est visible et permet d’identifier nommément le champ concerné ;
    • Le champ obligatoire dispose de l’attribut aria-invalid="true".
  4. 11.10.4
    Les champs obligatoires ayant l’attribut aria-invalid="true" vérifient-ils une de ces conditions ?
    • Le message d’erreur indiquant le caractère invalide de la saisie est visible et situé dans l’étiquette associée au champ ;
    • Le message d’erreur indiquant le caractère invalide de la saisie est visible et situé dans le passage de texte associé au champ.
  5. 11.10.5
    Les instructions et indications du type de données et/ou de format obligatoires vérifient-elles une de ces conditions ?
    • Une instruction ou une indication du type de données et/ou de format obligatoire est visible et permet d’identifier nommément le champ concerné préalablement à la validation du formulaire ;
    • Une instruction ou une indication du type de données et/ou de format obligatoire est visible dans l’étiquette ou le passage de texte associé au champ préalablement à la validation du formulaire.
  6. 11.10.6
    Les messages d’erreurs fournissant une instruction ou une indication du type de données et/ou de format obligatoire des champs vérifient-ils une de ces conditions ?
    • Le message d’erreur fournissant une instruction ou une indication du type de données et/ou de format obligatoires est visible et identifie le champ concerné ;
    • Le champ dispose de l’attribut aria-invalid="true".
  7. 11.10.7
    Les champs ayant l’attribut aria-invalid="true" dont la saisie requiert un type de données et/ou de format obligatoires vérifient-ils une de ces conditions ?
    • Une instruction ou une indication du type de données et/ou de format obligatoire est visible et située dans la balise <label> associée au champ ;
    • Une instruction ou une indication du type de données et/ou de format obligatoire est visible et située dans le passage de texte associé au champ.

Comment le vérifier

  1. Avant validation : vérifier que les champs obligatoires sont signalés visiblement et portent required ou aria-required="true", et que l'indication visible est dans l'étiquette ou le texte associé au champ.
  2. Vérifier de même les contraintes de format : le format attendu doit être annoncé avant la saisie, dans l'étiquette ou un passage lié au champ, pas seulement après l'erreur.
  3. Valider le formulaire avec des champs vides, puis avec des valeurs mal formées, et lire les messages : chacun doit nommer le champ concerné.
  4. Vérifier que les champs en erreur portent aria-invalid="true" et que le message correspondant est bien rattaché à l'étiquette ou au texte associé — sinon il flotte.

Ce que notre outil fait

Assisté

Le moteur repère les éléments concernés et vous pose la question. Il ne conclut pas à votre place.

La règle vérifie qu'un message d'erreur décrit bien la valeur attendue pour le champ qu'il vise, une fois l'erreur affichée. Les six autres tests du critère supposent de remplir le formulaire et de le soumettre : c'est vous qui provoquez les erreurs.

Règles ACT du W3C mises en œuvre : 36b590

Comment nous mesurons ce que l'outil sait faire · ce critère s'audite dans l'extension RGAA Lab.

Les pièges

Les erreurs qu’on rencontre vraiment, relevées au fil des audits.

  • Un astérisque rouge sans légende explicative n'indique rien : la convention n'est pas universelle, et la couleur seule ne porte pas l'information.
  • Un résumé d'erreurs en haut de page est une bonne pratique, mais il ne dispense pas de rattacher chaque message à son champ.
  • required sans indication visible échoue tout autant que l'indication visible sans required : le référentiel demande les deux.
  • Un message affiché puis retiré au bout de cinq secondes ne laisse pas le temps de le lire à qui parcourt la page au lecteur d'écran.

À lire avec