Skip to main content
Les problèmes d’utilisabilité des formulaires frustrent les utilisateurs et entraînent des abandons. Les problèmes d’accessibilité dans les formulaires les rendent complètement inutilisables pour les utilisateurs de lecteurs d’écran. Les deux catégories ont un impact direct sur les affaires.

missing-error-messages

Critique WCAG 3.3.1

Description

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

<!-- Formulaire sans gestion des erreurs — échoue silencieusement -->
<form>
  <input type="email" required name="email">
  <button type="submit">S'abonner</button>
</form>
<!-- Après une soumission invalide : page inchangée, aucun message affiché -->

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 :
<!-- Erreur de résumé générique -->
<div role="alert" id="form-errors">
  Veuillez corriger les erreurs suivantes avant de continuer.
</div>

<!-- Erreur inline par champ -->
<label for="email">Email</label>
<input type="email" id="email" aria-describedby="email-error">
<span id="email-error" role="alert">Veuillez saisir une adresse email valide</span>

error-not-visible

Critique WCAG 3.3.1

Description

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 :
/* Au lieu de basculer display:none */
.error-message {
  display: block; /* Afficher lors d'une erreur */
}

/* Ou utiliser visibility */
.field-error {
  visibility: visible;
  height: auto;
}
Utilisez JavaScript ou la réactivité du framework pour afficher conditionnellement les messages d’erreur plutôt que de masquer ceux pré-rendus :
// Exemple React
{errors.email && <span role="alert">{errors.email.message}</span>}

required-field-not-marked

Moyen WCAG 3.3.2

Description

Les champs de formulaire qui sont obligatoires (via l’attribut required 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

<!-- Indicateur visuel obligatoire manquant -->
<label for="phone">Téléphone</label>
<input type="tel" id="phone" required>

<!-- Correct : indicateur astérisque -->
<label for="phone">Téléphone <span aria-hidden="true">*</span></label>
<input type="tel" id="phone" required aria-required="true">

<!-- Inclure une légende expliquant l'indicateur -->
<p>Les champs marqués d'un <span aria-hidden="true">*</span> sont obligatoires.</p>

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.1

Description

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 liaison aria-describedby ou aria-errormessage.

Importance

Les lecteurs d’écran annoncent les champs de saisie en lisant leur étiquette et toute description programmatiquement associée. Sans aria-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 attributs aria-describedby ou aria-errormessage correspondants pointant vers l’élément d’erreur.

Comment corriger

Liez les messages d’erreur à leurs champs en utilisant aria-describedby :
<label for="email">Email</label>
<input
  type="email"
  id="email"
  aria-describedby="email-error"
  aria-invalid="true"
>
<span id="email-error" role="alert">
  Veuillez saisir une adresse email valide
</span>

placeholder-as-label

Moyen WCAG 1.3.1

Description

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

<!-- Placeholder uniquement — l'étiquette disparaît lors de la frappe -->
<input type="email" placeholder="Adresse email">

<!-- Correct : étiquette visible + placeholder comme indice -->
<label for="email">Adresse email</label>
<input type="email" id="email" placeholder="vous@example.com">

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

Moyen

Description

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 :
<form>
  <label for="email">Email</label>
  <input type="email" id="email" name="email">
  <button type="submit">S'abonner</button>
</form>

select-missing-label

Moyen WCAG 1.3.1

Description

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

<!-- Select sans étiquette -->
<select name="country">
  <option>États-Unis</option>
</select>

<!-- Correct : étiquette associée -->
<label for="country">Pays</label>
<select id="country" name="country">
  <option>États-Unis</option>
</select>

Comment corriger

Associez chaque <select> à une étiquette visible via <label for="...">. Si une étiquette visible n’est pas possible, utilisez aria-label :
<select aria-label="Sélectionnez votre pays" name="country">

copy-paste-blocked

Moyen

Description

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 tout onpaste="return false" ou écouteur d’événement paste qui appelle preventDefault() :
// Supprimer ceci
input.addEventListener('paste', (e) => e.preventDefault())

// Autoriser le collage — c'est le comportement par défaut, aucun code nécessaire