La plupart des sites et applications contiennent un formulaire Web. Les sites de blagues (comme DoSites<form>.
L'élément <form> HTML identifie un point de repère de document contenant des commandes interactives pour l'envoi d'informations. Imbriqués dans un <form>, vous trouverez toutes les commandes de formulaire interactives (et non interactives) qui le composent.
Le langage HTML est puissant. Cette section se concentre sur la puissance du HTML et explique ce qu'il peut faire sans ajouter JavaScript. L'utilisation de données de formulaire côté client pour mettre à jour l'interface utilisateur implique généralement CSS ou JavaScript, qui n'est pas abordé dans cet article. Il existe un cours complet Learn Forms. Nous ne dupliquerons pas cette section ici, mais nous présenterons plusieurs commandes de formulaire et les attributs HTML qui leur permettent de les utiliser.
Grâce aux formulaires, vous pouvez permettre aux utilisateurs d'interagir avec votre site Web ou votre application, de valider les informations saisies et de les envoyer à un serveur. Grâce aux attributs HTML, vous pouvez demander à l'utilisateur de sélectionner des commandes de formulaire ou de saisir une valeur. Les attributs HTML peuvent définir des critères spécifiques auxquels la valeur doit correspondre pour être valide. Lorsque l'utilisateur tente d'envoyer le formulaire, toutes les valeurs de contrôle de formulaire passent par la validation des contraintes côté client et peuvent empêcher l'envoi tant que les données ne répondent pas aux critères requis, le tout sans JavaScript. Vous pouvez également désactiver cette fonctionnalité: définir l'attribut novalidate sur <form> ou, plus souvent, formnovalidate sur un bouton, enregistrer les données du formulaire pour un remplissage ultérieur empêche la validation.
Envoi de formulaires
Les formulaires sont envoyés lorsque l'utilisateur active un bouton d'envoi imbriqué dans le formulaire. Lorsque vous utilisez <input> pour des boutons, la "valeur" est le libellé du bouton et s'affiche dans le bouton. Lorsque vous utilisez <button>, le libellé est le texte situé entre les balises d'ouverture et de fermeture <button>. Il existe deux façons d'écrire un bouton d'envoi:
<input type="submit" value="Submit Form">
<button type="submit">Submit Form</button>
Pour un formulaire très simple, vous avez besoin d'un élément <form> contenant des entrées de formulaire et d'un bouton "Envoyer". Toutefois, l'envoi d'un formulaire ne se limite pas à cela.
Les attributs de l'élément <form> définissent la méthode HTTP via laquelle le formulaire est envoyé et l'URL qui traite l'envoi du formulaire. Oui, il est possible d'envoyer et de traiter des formulaires, et de charger une nouvelle page sans code JavaScript. L'élément <form> est très puissant.
Les valeurs des attributs action et method de l'élément <form> définissent respectivement l'URL qui traite les données du formulaire et la méthode HTTP utilisée pour les envoyer.
Par défaut, les données du formulaire sont envoyées à la page active. Sinon, définissez l'attribut action sur l'URL de la page vers laquelle les données doivent être envoyées.
Les données envoyées sont constituées des paires nom/valeur des différentes commandes de formulaire du formulaire. Par défaut, cela inclut toutes les commandes de formulaire imbriquées dans le formulaire qui ont un name. Toutefois, avec l'attribut form, il est possible d'inclure des commandes de formulaire en dehors de <form> et d'omettre les commandes de formulaire imbriquées dans <form>. Compatible avec les commandes de formulaire et <fieldset>, la valeur de l'attribut form correspond au id de la commande à laquelle il est associé, et pas nécessairement à la forme dans laquelle il est imbriqué. Cela signifie que les commandes de formulaire n'ont pas besoin d'être physiquement imbriquées dans un <form>.
L'attribut method définit le protocole HTTP de la requête: généralement GET ou POST. Avec GET, les données du formulaire sont envoyées sous la forme d'une chaîne de paramètre de paires name=value, ajoutée à l'URL de action.
Avec POST, les données sont ajoutées au corps de la requête HTTP. Lorsque vous envoyez des données sécurisées, telles que des mots de passe et des informations de carte de crédit, utilisez toujours POST.
Il existe également une méthode DIALOG. Si un <form method="dialog"> se trouve dans un <dialog>, l'envoi du formulaire ferme la boîte de dialogue. Il y a un événement d'envoi bien que les données ne soient ni effacées, ni envoyées. Là encore, sans JavaScript. Ce point est abordé dans la section de la boîte de dialogue. Étant donné que le formulaire ne sera pas envoyé, vous souhaiterez probablement inclure formmethod="dialog" et formnovalidate sur le bouton "Envoyer".
Les boutons de formulaire peuvent contenir d'autres attributs que ceux décrits au début de cette section. Si le bouton inclut un attribut formaction, formenctype, formmethod, formnovalidate ou formtarget, les valeurs définies sur le bouton qui active l'envoi du formulaire sont prioritaires sur les valeurs action, enctype, method et target définies sur <form>. La validation des contraintes a lieu avant l'envoi du formulaire, mais uniquement s'il n'y a pas de formnovalidate sur le bouton "Envoyer" activé ni d'novalidate sur le <form>.
Pour identifier le bouton utilisé pour envoyer un formulaire, attribuez-lui une name. Les boutons sans nom ni valeur ne sont pas envoyés avec les données du formulaire lors de l'envoi du formulaire.
Après avoir envoyé le formulaire
Lorsque l'utilisateur remplit un formulaire en ligne, le nom et les valeurs des commandes correspondantes sont transmis. Le nom correspond à la valeur de l'attribut name. Ces valeurs proviennent du contenu de l'attribut value, ou de la valeur saisie ou sélectionnée par l'utilisateur. La valeur d'un <textarea> correspond à son texte interne.
La valeur d'un élément <select> est la valeur value de l'élément <option> sélectionné. Si l'élément <option> n'inclut pas d'attribut value, la valeur est le texte interne de l'option sélectionnée.
<form method="GET">
<label for="student">Pick a student:</label>
<select name="student" id="student">
<option value="hoover">Hoover Sukhdeep</option>
<option>Blendan Smooth</option>
<option value="toasty">Toasty McToastface</option>
</select>
<input type="submit" value="Submit Form">
</form>
Sélectionnez "Hoover Sukhdeep" (ou ne faites rien, car le navigateur s'affiche et sélectionne donc la première valeur par défaut), puis cliquez sur le bouton "Envoyer" pour actualiser cette page et définir l'URL sur:
https://web.dev/learn/html/forms?student=hoover
Comme la deuxième option ne comporte pas d'attribut value, le texte interne est envoyé en tant que valeur. Sélectionnez "Blendan Smooth" et cliquez sur le bouton "Submit" (Envoyer) pour actualiser la page. L'URL sera alors définie sur:
https://web.dev/learn/html/forms?student=Blendan+Smooth
Lors de l'envoi d'un formulaire, les informations envoyées incluent les noms et les valeurs de toutes les commandes de formulaire nommées qui ont un name, à l'exception des cases à cocher et des cases d'option non sélectionnées, ainsi que les noms et valeurs de tous les boutons autres que ceux qui ont envoyé le formulaire. Pour toutes les autres commandes de formulaire, si la commande de formulaire a un nom, mais qu'aucune valeur n'a été saisie ou définie par défaut, son name est envoyé avec une valeur vide.
Il existe 22 types d'entrées. Nous ne pouvons donc pas tous les couvrir.
Sachez simplement que l'ajout d'une valeur est facultatif, et souvent une mauvaise idée, lorsque vous souhaitez que l'utilisateur entre des informations.
Pour les éléments <input> dont l'utilisateur ne peut pas modifier la valeur, vous devez toujours inclure une valeur, y compris pour les éléments d'entrée de type hidden, radio, checkbox, submit, button ou reset.
L'utilisation de name uniques pour les contrôles de formulaire simplifie le traitement des données côté serveur. Elle est recommandée, les cases à cocher et les cases d'option étant des exceptions à cette règle.
Cases d'option
Lorsque vous sélectionnez une case d'option dans un groupe de cases d'option, vous ne pouvez en sélectionner qu'une seule à la fois, en raison de l'attribut name. Cet effet est créé en attribuant la même case d'option name à chaque case d'option d'un groupe.
Un name doit être unique au groupe: si vous utilisez accidentellement le même name pour deux groupes distincts, la sélection d'une case d'option dans le deuxième groupe désélectionne toute sélection effectuée dans le premier groupe avec le même name.
Le name et le value de la case d'option sélectionnée sont envoyés avec le formulaire. Assurez-vous que chaque case d'option est associée à un value pertinent (et généralement unique). Les valeurs des cases d'option non sélectionnées ne sont pas envoyées.
Vous pouvez avoir autant de groupes d'options que vous le souhaitez sur une page, chacun travaillant indépendamment, à condition que chacun possède un name propre au groupe.
Si vous souhaitez charger la page avec l'une des cases d'option d'un groupe portant le même nom sélectionné, incluez l'attribut checked.
Cette case d'option correspond à la pseudo-classe CSS :default, même si l'utilisateur sélectionne une autre case d'option. La case d'option actuellement sélectionnée correspond à la pseudo-classe :checked.
Si l'utilisateur doit sélectionner une case d'option parmi un groupe de cases d'option, ajoutez l'attribut required à au moins l'une d'entre elles. L'inclusion de required sur une case d'option dans un groupe rend une sélection obligatoire pour l'envoi de formulaire, mais il ne doit pas nécessairement s'agir de la case d'option avec l'attribut sélectionné pour être valide. Indiquez également clairement dans <legend> que la commande de formulaire est requise. L'étiquetage des groupes de cases d'option avec chaque bouton individuel est décrit ultérieurement.
Cases à cocher
Toutes les cases à cocher d'un groupe peuvent avoir le même name. Seules les cases name et value sont envoyées avec le formulaire. Si vous avez sélectionné plusieurs cases à cocher portant le même nom, le même nom sera envoyé avec, espérons-le, des valeurs différentes. Si plusieurs commandes de formulaire portent le même nom, elles sont toutes envoyées, séparées par une esperluette, même s'il ne s'agit pas de cases à cocher.
Si vous n'incluez pas d'value dans une case à cocher, la valeur des cases à cocher sélectionnées sera on par défaut, ce qui n'est probablement pas utile. Si vous avez trois cases nommées chk et qu'elles sont toutes cochées, l'envoi du formulaire ne sera pas déchiffrable:
https://web.dev/learn/html/forms?chk=on&chk=on&chk=on
Pour rendre une case à cocher obligatoire, ajoutez l'attribut required. Informez toujours l'utilisateur lorsqu'une case doit être cochée ou lorsqu'un contrôle de formulaire est requis. L'ajout de required à une case à cocher ne fait que rendre cette case obligatoire. Cela n'a aucune incidence sur les autres cases portant le même nom.
Libellés et ensembles de champs
Pour que les utilisateurs sachent comment remplir un formulaire, celui-ci doit être accessible. Chaque commande de formulaire doit être associée à un libellé.
Vous pouvez également appliquer des libellés à des groupes de contrôles de formulaire. Alors que les zones d'entrée, de sélection et de texte individuelles sont libellées avec <label>, les groupes de commandes de formulaire sont étiquetés par le contenu de <legend> du <fieldset> qui les regroupe.
Dans les exemples précédents, vous avez peut-être remarqué que chaque commande de formulaire, à l'exception du bouton "Envoyer", comportait un élément <label>. Les libellés fournissent des commandes de formulaire avec des noms accessibles. Le nom accessible des boutons provient de leur contenu ou de leur valeur. Toutes les autres commandes de formulaire nécessitent un <label> associé. Si aucun libellé n'est associé, le navigateur affiche quand même vos commandes de formulaire, mais les utilisateurs ne sauront pas quelles informations sont attendues.
Pour associer explicitement une commande de formulaire à un <label>, ajoutez l'attribut for à <label>: la valeur correspond au id de la commande de formulaire à laquelle elle est associée.
<label for="full_name">Your name</label>
<input type="text" id="full_name" name="name">
L'association de libellés aux commandes de formulaire présente plusieurs avantages. Les étiquettes rendent les commandes de formulaire accessibles aux utilisateurs de lecteurs d'écran en fournissant à la commande un nom accessible. Les libellés sont également des "zones d'interaction" : en agrandissant la zone, ils rendent le site plus facile à utiliser pour les utilisateurs souffrant de problèmes de dextérité. Si vous utilisez une souris, essayez de cliquer n'importe où sur le libellé "Votre nom". Cela permet de mettre l'accent sur l'entrée.
Pour fournir des libellés implicites, incluez la commande de formulaire entre les balises d'ouverture et de fermeture <label>. Elle est également accessible du point de vue du lecteur d'écran et de l'appareil de pointeur, mais elle ne fournit pas le crochet de style comme le libellé explicite.
<label>Your name
<input type="text" name="name">
</label>
Les libellés étant des "zones d'appel", n'incluez pas d'éléments interactifs dans un libellé explicite, ni tout autre composant interactif autre que la commande de formulaire avec libellé dans un libellé implicite. Par exemple, si vous incluez un lien dans un libellé, alors que le navigateur affiche le code HTML, vos utilisateurs seront désorientés s'ils cliquent sur le libellé pour saisir une commande de formulaire, mais sont redirigés vers une nouvelle page.
En général, <label> est placé avant la commande de formulaire, sauf dans le cas des cases d'option et des cases à cocher. Ce n'est pas obligatoire.
C’est juste le modèle UX courant. La série "Apprendre les formulaires" contient des informations sur la conception des formulaires.
Pour les groupes de cases d'option et de cases à cocher, le libellé fournit le nom accessible de la commande de formulaire à laquelle il est associé. Toutefois, le groupe de commandes et leurs libellés ont également besoin d'un libellé. Pour ajouter un libellé au groupe, regroupez tous les éléments dans un élément <fieldset>, où <legend> fournit le libellé du groupe.
<fieldset>
<legend>Who is your favorite student?</legend>
<ul>
<li>
<label>
<input type="radio" value="blendan" name="machine"> Blendan Smooth
</label>
</li>
<li>
<label>
<input type="radio" value="hoover" name="machine"> Hoover Sukhdeep
</label>
</li>
<li>
<label>
<input type="radio" value="toasty" name="machine"> Toasty McToastface
</label>
</li>
</ul>
</fieldset>
Dans cet exemple, les <label> implicites libèrent chacun une case d'option, et <legend> fournit le libellé du groupe de cases d'option.
L'imbrication d'un <fieldset> dans un autre <fieldset> est une pratique courante. Par exemple, si un formulaire est une enquête composée de nombreuses questions réparties en groupes de questions connexes, l'élément <fieldset> "élève favori" peut être imbriqué dans un autre élément <fieldset> intitulé "Vos favoris":
<fieldset>
<legend>Your favorites:</legend>
<ul start="6">
<li>
<fieldset>
<legend>Who is your favorite student?</legend>
<ul>
<li>
<!-- the rest of the code here -->
L'apparence par défaut de ces éléments a conduit à leur sous-utilisation, mais <legend> et <fieldset> peuvent être stylisés avec du CSS.
En plus de tous les attributs globaux, <fieldset> est également compatible avec les attributs name, disabled et form.
Lorsque vous désactivez un ensemble de champs, toutes les commandes des formulaires imbriqués sont désactivées. Ni les attributs name, ni les attributs form n'ont beaucoup d'utilisation sur <fieldset>. name permet d'accéder à l'ensemble de champs avec JavaScript, mais l'ensemble de champs lui-même n'est pas inclus dans les données envoyées (les commandes de formulaire nommées qui sont imbriquées dans le sont sont incluses).
Types de saisie et clavier dynamique
Comme indiqué précédemment, il existe 22 types d'entrées différents.
Dans certains cas, lorsqu'un utilisateur utilise un appareil équipé d'un clavier dynamique qui ne s'affiche que si nécessaire (un téléphone, par exemple), le type de saisie utilisé détermine le type de clavier affiché. Le clavier par défaut affiché peut être optimisé pour le type de saisie requis.
Par exemple, si vous saisissez tel, le clavier est optimisé pour la saisie de numéros de téléphone ; email inclut @ et ., et le clavier dynamique url comprend un deux-points et une barre oblique. Malheureusement, l'iPhone n'inclut toujours pas : dans le clavier dynamique par défaut pour les types de saisie url.
Claviers pour <input type="tel"> sur iPhone et sur deux téléphones Android différents:
Claviers pour <input type="email"> sur iPhone et sur deux téléphones Android différents:
Accéder au micro et à la caméra
Le type d'entrée de fichier <input type="file"> permet d'importer des fichiers via des formulaires. Les fichiers peuvent être de n'importe quel type, définis et limités par l'attribut accept. La liste des types de fichiers acceptés peut être une liste d'extensions de fichiers séparées par une virgule, un type global ou une combinaison de types et d'extensions globaux. Par exemple, accept="video/*, .gif" accepte tous les fichiers vidéo ou GIF animés.
Utilisez "audio/*" pour les fichiers audio, "video/*" pour les fichiers vidéo et "image/*" pour les fichiers image.
L'attribut énuméré capture, défini dans les spécifications de capture multimédia, peut être utilisé si un fichier multimédia doit être créé à l'aide de l'appareil photo ou du micro de l'utilisateur. Vous pouvez définir la valeur sur user pour les périphériques d'entrée visibles par l'utilisateur ou sur environment pour la caméra arrière ou le micro du téléphone. En règle générale, l'utilisation de capture sans valeur fonctionne, car l'utilisateur choisit le périphérique d'entrée qu'il souhaite utiliser.
<label for="avatar">A recent photo of yourself:</label>
<input type="file" capture="user" accept="image/*" name="avatar" id="avatar">
Validation intégrée
Là encore, sans inclure de code JavaScript, le code HTML peut empêcher l'envoi de formulaires dont les valeurs sont incorrectes.
Certains sélecteurs CSS correspondent aux commandes de formulaire en fonction de la présence d'attributs HTML, y compris :required et :optional si la valeur booléenne required est définie ou non, :default si checked est codé en dur, et :enabled ou :disabled :disabled, selon que l'élément est interactif, et selon que l'attribut est , , et selon que l'élément est interactif, selon que l'attribut est présent ou non , , selon que l'attribut est présent ou non ; :default si checked est codé en dur.disabled La pseudo-classe :read-write met en correspondance les éléments dont les commandes de formulaire et contenteditable sont définies par défaut et modifiables par défaut, comme les types d'entrée number, password et text (mais pas les cases à cocher, les cases d'option ni le type hidden). Si l'attribut readonly est défini pour un élément normalement accessible en écriture, il correspondra à :read-only à la place.
Lorsque l'utilisateur saisit des informations dans les commandes du formulaire, les sélecteurs de l'UI CSS, y compris :valid, :invalid, :in-range et :out-of-range, s'activent ou se désactivent en fonction de l'état. Lorsque l'utilisateur quitte une commande de formulaire, la pseudo-classe :user-invalid ou :user-valid, qui n'est pas encore entièrement compatible, correspond.
Vous pouvez utiliser le CSS pour indiquer si des commandes de formulaire sont requises et valides lorsque l'utilisateur interagit avec le formulaire. Vous pouvez même utiliser un CSS pour empêcher les utilisateurs de cliquer sur le bouton "Envoyer" tant que le formulaire n'est pas valide:
form:invalid [type="submit"] {
opacity: 50%;
pointer-events: none;
}
Cet extrait CSS est un anti-modèle. Bien que votre interface utilisateur puisse sembler intuitive et claire, de nombreux utilisateurs tentent d'envoyer un formulaire pour activer les messages d'erreur. Faire apparaître un bouton d'envoi désactivé de cette manière ne permet pas de valider les contraintes, une fonctionnalité sur laquelle de nombreux utilisateurs s'appuient.
Les CSS appliqués sont mis à jour en permanence en fonction de l'état actuel de l'interface utilisateur. Par exemple, lorsque vous incluez des types d'entrée avec des contraintes, tels que email, number, url et des types de date, si la valeur n'est pas nulle (non vide) et que la valeur actuelle n'est pas une adresse e-mail, un nombre, une URL, une date ou une heure valides, la pseudo-classe CSS est une correspondance.:invalid Cette mise à jour constante diffère de la validation des contraintes HTML intégrée, qui ne se produit que lorsque l'utilisateur tente d'envoyer le formulaire.
La validation des contraintes intégrée ne s'applique qu'aux contraintes définies avec des attributs HTML. Bien que vous puissiez styliser un élément en fonction des pseudo-classes :required et :valid/:invalid, les messages d'erreur fournis par le navigateur issus d'erreurs basées sur les attributs required, pattern, min, max et même type sont envoyés lors de l'envoi du formulaire.
Lorsque nous essayons d'envoyer le formulaire sans choisir l'élève favori requis, la validation des contraintes empêche l'envoi du formulaire en raison d'une erreur validityState.valueMissing.
Si l'une des propriétés validityState renvoie true, l'envoi est bloqué et le navigateur affiche un message d'erreur dans la première commande de formulaire incorrecte, le mettant alors en surbrillance. Lorsque l'utilisateur active l'envoi d'un formulaire et qu'il existe des valeurs non valides, la première commande de formulaire non valide affiche un message d'erreur et est sélectionnée. Si aucune valeur n'est définie pour une commande requise, si une valeur numérique est hors plage ou si une valeur n'est pas du type requis par l'attribut type, le formulaire n'est pas validé, n'est pas envoyé et un message d'erreur s'affiche.
Si une valeur number, de date ou d'heure est inférieure au min minimal défini ou au-dessus de la valeur max maximale définie, la commande sera :out-of-range (et :invalid), et l'utilisateur sera informé de l'erreur valididityState.rangeUnderflow, validityState.rangeOverflow lorsqu'il essaie d'envoyer le formulaire. Si la valeur n'est pas en rapport avec la valeur step, qu'elle soit définie explicitement ou définie par défaut sur 1, la commande sera :out-of-range (et :invalid), et une erreur validityState.stepMismatch se produira. L'erreur s'affiche sous forme de bulle et fournit par défaut des informations utiles pour la corriger.
Il existe des attributs similaires pour la longueur des valeurs: minlength et maxlength alertent l'utilisateur en cas d'erreur avec validityState.tooLong ou validityState.tooShort lors de l'envoi.
Le maxlength empêche également l'utilisateur de saisir trop de caractères.
L'utilisation de l'attribut maxlength peut nuire à l'expérience utilisateur. Il est généralement préférable de permettre à l'utilisateur de saisir un nombre de caractères supérieur au nombre maximal de caractères autorisé, en fournissant un compteur, éventuellement sous la forme d'un élément <output>, qui n'est pas envoyé avec le formulaire. Il peut ainsi modifier le texte jusqu'à ce que le résultat indique que la longueur maximale autorisée n'a pas été dépassée. Vous pouvez inclure l'élément maxlength dans votre code HTML. Comme nous l'avons vu précédemment, il fonctionne sans JavaScript. Ensuite, lors du chargement, la valeur de l'attribut maxlength peut être utilisée pour créer ce compteur de caractères en JavaScript.
Certains types d'entrées semblent avoir des contraintes par défaut, mais pas du tout. Par exemple, le type d'entrée tel fournit un clavier téléphonique numérique sur les appareils équipés de claviers dynamiques, mais ne limite pas les valeurs valides. Pour cela et pour d'autres types d'entrée, il existe l'attribut pattern. Vous pouvez spécifier une expression régulière à laquelle la valeur doit correspondre pour être considérée comme valide.
Si une valeur est la chaîne vide et que la valeur n'est pas obligatoire, cela ne générera pas d'erreur validityState.patternMismatch. Si ce champ est obligatoire et vide, le message d'erreur par défaut pour validityState.valueMissing sera présenté à l'utilisateur au lieu de patternMismatch.
Pour les e-mails, validityState.typeMismatch est probablement trop adapté à vos besoins. Vous souhaiterez probablement inclure l'attribut pattern pour que les adresses e-mail intranet sans TLD ne soient pas acceptées comme valides.
L'attribut motif permet de fournir une expression régulière à laquelle la valeur doit correspondre. Lorsque vous exigez une correspondance de structure, assurez-vous que l'action attendue est très claire pour l'utilisateur.
Tout cela peut être fait sans une seule ligne de JavaScript. Toutefois, en tant qu'API HTML, vous pouvez utiliser JavaScript pour inclure des messages personnalisés lors de la validation des contraintes. Vous pouvez également utiliser JavaScript pour mettre à jour le nombre de caractères restants, afficher une barre de progression pour contrôler le niveau de sécurité du mot de passe ou toute autre méthode permettant d'améliorer dynamiquement la saisie semi-automatique.
Exemple
Cet exemple présente un formulaire dans un <dialog> avec un <form> imbriqué avec trois commandes de formulaire et deux boutons d'envoi, avec des libellés et des instructions clairs.
Le premier bouton "Envoyer" ferme la boîte de dialogue. Utilisez formmethod="dialog" pour remplacer la méthode par défaut du formulaire, puis fermez <dialog> sans envoyer les données ni les effacer. Vous devez également inclure formnovalidate, sinon le navigateur essaiera de valider la vérification que tous les champs obligatoires ont une valeur. L'utilisateur peut vouloir fermer la boîte de dialogue et le formulaire sans saisir de données. La validation l'empêcherait. Incluez aria-label="close", car "X" est un repère visuel connu, mais n'est pas une étiquette descriptive.
Les commandes de formulaire comportent toutes des libellés implicites. Vous n'avez donc pas besoin d'inclure les attributs id ou for. Les éléments d'entrée possèdent tous les deux l'attribut requis, ce qui les rend obligatoires. La valeur step saisie est explicitement définie pour montrer comment step est inclus. Étant donné que step est défini par défaut sur 1, cet attribut peut être omis.
<select> possède une valeur par défaut, ce qui rend l'attribut required inutile. Au lieu d'inclure l'attribut value pour chaque option, la valeur par défaut est le texte interne.
Le bouton "Envoyer" à la fin définit la méthode des formulaires sur POST. Lorsque vous cliquez dessus, la validité de chaque valeur est vérifiée. Si toutes les valeurs sont valides, les données du formulaire sont envoyées, la boîte de dialogue se ferme, et la page peut rediriger vers thankyou.php, qui est l'URL d'action. Si des valeurs sont manquantes, ou si la valeur numérique présente une incohérence d'étape ou est hors plage, un message d'erreur défini par le navigateur correspondant s'affiche. Le formulaire n'est pas envoyé, et la boîte de dialogue ne se ferme pas.
Les messages d'erreur par défaut peuvent être personnalisés avec la méthode validityState.setCustomValidity('message here'). Notez simplement que si vous définissez un message personnalisé, il doit être explicitement défini sur la chaîne vide lorsque tout est valide, sans quoi le formulaire ne sera pas envoyé.
Autres points à prendre en compte
Toute une section est dédiée à aider vos utilisateurs à saisir les bonnes données dans les formulaires. Pour une bonne expérience utilisateur, il est important d'empêcher les utilisateurs de faire des erreurs en incluant des instructions et en fournissant des indications si nécessaire. Bien que cette section explique comment le code HTML seul peut effectuer une validation côté client, la validation doit être à la fois côté client et côté serveur. La validation peut être effectuée de manière discrète lorsque vous remplissez le formulaire, par exemple en ajoutant une coche lorsque la valeur est correcte. Toutefois, n'envoyez pas de message d'erreur avant la fin du contrôle du formulaire. Si l'utilisateur fait une erreur, informez-le de l'origine de l'erreur et de ce qu'il a subi.
Lorsque vous concevez des formulaires, il est important de tenir compte du fait que tout le monde n'est pas comme vous. Un individu peut avoir une seule lettre de nom de famille (ou pas de nom de famille), peut ne pas avoir de code postal, peut avoir une adresse postale sur trois lignes ou ne pas avoir d'adresse postale. Ils consultent peut-être une version traduite de votre formulaire.
Les commandes de formulaire, leurs libellés et les messages d'erreur doivent être visibles à l'écran, précis, pertinents, déterminables par programmation et associés de manière programmatique à l'élément ou au groupe de formulaire approprié. L'attribut autocomplete peut et doit être utilisé pour accélérer le remplissage des formulaires et améliorer l'accessibilité.
Le langage HTML fournit tous les outils permettant d'accéder aux commandes de base des formulaires. Plus un élément ou un processus de formulaire est interactif, plus l'accessibilité doit être importante pour la gestion de la sélection, la définition et la mise à jour des noms, rôles et valeurs ARIA (si nécessaire) et les annonces ARIA en direct si nécessaire. Toutefois, comme nous l'avons vu ici, en utilisant uniquement le langage HTML, vous pouvez atteindre votre objectif d'accessibilité et de validité sans avoir à utiliser les flux ARIA ou JavaScript.
Testez vos connaissances
Testez vos connaissances sur les formulaires.
Comment faire pour que les cases d'option appartiennent au même groupe ?
name.id.Quel élément HTML permet d'indiquer à l'utilisateur à quoi sert ce champ de formulaire ?
<h1><title><label>