missing-error-messages
Critique WCAG 3.3.1Description
Lorsqu’un formulaire est soumis avec des données invalides ou manquantes, aucun message d’erreur n’est affiché nulle part dans le DOM. La soumission échoue silencieusement, laissant les utilisateurs sans indication de ce qui s’est mal passé ou comment corriger.Importance
Sans retour d’erreur, les utilisateurs ne peuvent pas compléter le formulaire. Cela bloque directement l’accomplissement des tâches pour tous les utilisateurs — et pour les utilisateurs de lecteurs d’écran, même un message d’erreur générique est critique car ils ne peuvent pas analyser visuellement le formulaire pour les indicateurs d’erreur visuels.Comment QAOS le détecte
L’agent soumet des formulaires avec des champs obligatoires laissés vides ou avec des données invalides, puis analyse le DOM pour tout élément de message d’erreur — y compris les messages dans des éléments<div> séparés, les attributs data-validation-message ou les régions ARIA live.
Exemples
Comment corriger
Affichez au moins un message d’erreur lorsque la validation du formulaire échoue. Le message doit indiquer quels champs sont invalides et ce que l’utilisateur doit faire :error-not-visible
Critique WCAG 3.3.1Description
Des éléments de message d’erreur existent dans le DOM après une soumission échouée, mais ils sont masqués via CSS (display: none, visibility: hidden, opacity: 0 ou positionnement hors écran) et n’apparaissent jamais à l’utilisateur.
Importance
Il s’agit d’un état d’échec particulièrement déroutant : l’application génère des informations d’erreur mais les supprime. Les utilisateurs ne voient rien, n’ont aucun moyen de corriger leur saisie et ne peuvent pas compléter le formulaire.Comment QAOS le détecte
Après avoir soumis un formulaire avec des données invalides, l’agent vérifie si des éléments liés aux erreurs existent dans le DOM mais sont masqués par des propriétés CSS qui les empêchent d’être visibles.Comment corriger
Assurez-vous que les éléments de message d’erreur sont visibles lorsque la validation échoue :required-field-not-marked
Moyen WCAG 3.3.2Description
Les champs de formulaire qui sont obligatoires (via l’attributrequired ou la validation côté serveur) ne sont pas visuellement indiqués comme obligatoires — pas d’astérisque, pas d’étiquette, pas d’indice visuel qui aide les utilisateurs à comprendre quels champs doivent être remplis avant la soumission.
Importance
Les utilisateurs qui ne réalisent pas qu’un champ est obligatoire le sautent souvent, rencontrent des erreurs de validation et se sentent frustrés. Des indicateurs clairs de champs obligatoires réduisent l’abandon de formulaires.Comment QAOS le détecte
L’agent identifie les<input required> ou les champs validés qui manquent d’indicateur visuel (astérisque dans l’étiquette, texte « obligatoire » ou convention similaire).
Exemples
Comment corriger
Marquez les champs obligatoires visuellement avec un indicateur cohérent (typiquement*). Incluez une légende près du haut du formulaire expliquant la convention. Utilisez aria-required="true" sur le champ de saisie pour les utilisateurs de lecteurs d’écran.
error-not-associated
Faible WCAG 1.3.1Description
Des messages d’erreur sont affichés après une soumission échouée mais ne sont pas liés programmatiquement au champ qu’ils décrivent. Le message apparaît visuellement près du champ mais manque de liaisonaria-describedby ou aria-errormessage.
Importance
Les lecteurs d’écran annoncent les champs de saisie en lisant leur étiquette et toute description programmatiquement associée. Sansaria-describedby, un utilisateur de lecteur d’écran se concentrant sur un champ n’entendra pas le message d’erreur associé à moins qu’il ne navigue pour le trouver.
Comment QAOS le détecte
Après avoir soumis des données invalides, l’agent vérifie si les champs avec des messages d’erreur visibles ont des attributsaria-describedby ou aria-errormessage correspondants pointant vers l’élément d’erreur.
Comment corriger
Liez les messages d’erreur à leurs champs en utilisantaria-describedby :
placeholder-as-label
Moyen WCAG 1.3.1Description
Un champ de saisie dépend uniquement du texte d’espace réservé pour communiquer son purpose. Il n’y a pas d’élément<label> visible, d’attribut aria-label ou aria-labelledby associé au champ.
Importance
Le texte d’espace réservé disparaît dès que l’utilisateur commence à taper, laissant le champ sans étiquette du tout. Les utilisateurs qui reviennent à un formulaire partiellement rempli voient des champs sans étiquette et ne se souviennent pas de ce qu’ils ont saisi. Les lecteurs d’écran gèrent également les espaces réservés de manière inconsistante — certains les annoncent, d’autres non.Comment QAOS le détecte
L’agent identifie les champs de saisie qui ont un attribut placeholder mais aucune association d’étiquette programmatique.Exemples
Comment corriger
Fournissez toujours une étiquette visible persistante. Utilisez le texte d’espace réservé uniquement comme indice supplémentaire, jamais comme étiquette principale.form-no-submit-button
MoyenDescription
Un élément de formulaire ne contient pas de bouton de soumission visible ou équivalent (<button type="submit"> ou <input type="submit">), rendant impossible la soumission via le clavier sans dépendre de la touche Entrée dans un champ de texte.
Importance
Les utilisateurs au clavier uniquement et les utilisateurs de technologies d’assistance s’attendent à une action clairement étiquetée pour soumettre un formulaire. Un formulaire sans bouton de soumission est également non standard et peut dérouter les utilisateurs qui ne connaissent pas le raccourci Entrée.Comment QAOS le détecte
L’agent analyse les éléments de formulaire pour l’absence de tout bouton de soumission ou contrôle interactif équivalent qui soumettrait le formulaire.Comment corriger
Chaque formulaire doit avoir un bouton de soumission explicite :select-missing-label
Moyen WCAG 1.3.1Description
Un élément<select> n’a pas d’étiquette associée — ni <label for="...">, aria-label ni aria-labelledby — rendant son purpose opaque pour les lecteurs d’écran.
Importance
Les lecteurs d’écran annoncent les contrôles de formulaire en lisant leur étiquette. Un<select> sans étiquette est annoncé seulement comme « combo box » ou « list box » sans indication de ce que l’utilisateur sélectionne.
Comment QAOS le détecte
L’agent analyse le DOM pour les éléments<select> sans étiquette programmatiquement associée.
Exemples
Comment corriger
Associez chaque<select> à une étiquette visible via <label for="...">. Si une étiquette visible n’est pas possible, utilisez aria-label :
copy-paste-blocked
MoyenDescription
Un champ de saisie (généralement un champ de confirmation de mot de passe ou de code OTP) bloque les opérations de collage, forçant les utilisateurs à taper le contenu manuellement même quand ils l’ont copié dans le presse-papiers.Importance
Bloquer le collage décourage l’utilisation des gestionnaires de mots de passe (qui collent des mots de passe forts et uniques), force les utilisateurs à retaper des identifiants complexes (augmentant les erreurs) et n’offre aucun avantage de sécurité réel. Les directives NIST recommandent explicitement d’autoriser le collage dans les champs de mot de passe.Comment QAOS le détecte
L’agent tente de coller dans les champs de saisie via le clavier et des méthodes programmatiques et vérifie si le collage est supprimé.Comment corriger
Supprimez toutonpaste="return false" ou écouteur d’événement paste qui appelle preventDefault() :