Cours HTML / Valider un formulaire : required, longueur et limites de valeurs

La validation de formulaire intégrée à HTML peut vérifier les valeurs manquantes, la longueur du texte, les plages numériques et certains formats de saisie avant l'envoi. Des attributs tels que required, minlength et max aident le navigateur à guider les utilisateurs. Ils ne remplacent pas la validation côté serveur.

Exiger une valeur et limiter sa longueur

<form method="get">
  <label for="nickname">Pseudonyme (2 à 20 caractères)</label>
  <input id="nickname" name="nickname" type="text"
         required minlength="2" maxlength="20">
  <button type="submit">Vérifier</button>
</form>

Essayez de soumettre un champ vide, puis un caractère, puis deux caractères. required vérifie la présence d'une valeur, tandis que minlength vérifie la longueur du texte fourni par l'utilisateur ; aucun des deux n'implique l'autre. Le message exact du navigateur varie selon le navigateur, le système d'exploitation et la langue. Informez les utilisateurs de la règle avant qu'ils ne soumettent plutôt que de compter uniquement sur un message d'erreur. Les contraintes de longueur peuvent se comporter différemment pour les valeurs remplies par script, donc testez l'entrée programmée séparément si votre formulaire l'utilise.

maxlength="20" empêche généralement les utilisateurs de taper plus que sa limite. HTML mesure cette limite en unités de code UTF-16, qui ne correspondent pas toujours au nombre de caractères visibles — par exemple, avec certains emoji. Si vous autorisez de tels caractères, testez ensemble l'entrée réelle et la règle de longueur du serveur. Voir la référence MDN maxlength.

Vérifiez une plage ou un format de base

<form method="get">
  <label for="people">Participants (1–10)</label>
  <input id="people" name="people" type="number"
         min="1" max="10" step="1" required>

  <label for="email">Adresse e-mail</label>
  <input id="email" name="email" type="email" required>
  <button type="submit">Vérifier</button>
</form>

min et max définissent la plage ; step définit l'incrément autorisé. Saisissez manuellement 0, 11 et 2,5, puis comparez avec les boutons d’incrémentation. Le séparateur décimal dépend de la langue du navigateur : utilisez 2.5 si 2,5 n’est pas accepté. Le fait qu'une valeur soit visible dans l'entrée ne signifie pas qu'elle est valide pour la soumission. type="email" vérifie un format d'adresse de base, pas si la boîte aux lettres existe réellement. Choisissez les types d'entrée en fonction de la signification de la valeur dans Choisir les types d'entrée pour Email, Nombres, Dates et Choix.

Il s'agit d'un formulaire GET soumis à l'URL actuelle pour s'entraîner. Utilisez une valeur de test telle que nom@example.com, et non une vraie adresse personnelle. Une fois que les valeurs passent la validation du navigateur, vous pouvez inspecter people et email dans la chaîne de requête de l'URL. Cet exemple n'inclut pas de serveur qui reçoit ou stocke les données.

Rédigez des conseils d'erreur exploitables

Ne vous contentez pas d'identifier les erreurs uniquement par la couleur. « Entrez un nombre entier de 1 à 10 » fournit plus d’informations aux utilisateurs que « Entrée invalide ». Si vous créez des messages personnalisés, reliez chaque message au contrôle pertinent et vérifiez que les utilisateurs au clavier peuvent y revenir. L'attribut novalidate sur form ignore la validation interactive intégrée lors de la soumission ; ne l’ajoutez pas simplement pour masquer un problème. Gardez les conditions visibles et reliez-les au contrôle en utilisant les instructions de Ajouter un texte indicatif aux champs de formulaire.

Une personne peut contourner les vérifications du navigateur avec les outils de développement ou une requête directe. Validez toujours les données importantes sur le serveur, en particulier les valeurs utilisées pour les comptes, les paiements ou les enregistrements stockés. Les vérifications côté navigateur aident les utilisateurs à corriger leurs erreurs ; les vérifications côté serveur protègent l'application. Consultez le guide MDN sur la validation des contraintes.

Avant d'ajouter une interface d'erreur personnalisée, appliquez également les vérifications d'accessibilité pour l'utilisation du clavier, la focus et les noms.

Comparez les valeurs limites avec les échecs attendus

Le champ des participants utilise min="1" max="10" step="1" required. Tapez chaque valeur et essayez de soumettre, en gardant un e-mail de test correctement formaté afin que l'erreur d'un autre champ ne masque pas le résultat.

La formulation exacte des erreurs intégrées varie. Le tableau distingue les contraintes échouées plutôt que de prescrire une chaîne de message. Une quantité valide de 2 ne rend pas le formulaire entier valide si un autre champ échoue toujours.

Les indications intégrées suivent les contraintes HTML. Une interface d'erreur personnalisée doit relier les messages à leurs contrôles et gérer les changements d'états et le focus. Cela nécessite une mise en œuvre et des tests supplémentaires ; aria-describedby seul ne crée pas de validation.

Testez vous-même les règles

1. Soumettez avec chaque champ obligatoire vide.
2. Essayez des valeurs juste en dehors et à l'intérieur de chaque limite indiquée.
3. Utilisez uniquement le clavier pour atteindre les champs, lire les erreurs, les corriger et soumettre à nouveau.