La balise <form> en HTML délimite une zone de saisie où l’utilisateur envoie des données vers un serveur ou les traite côté client. Comprendre son fonctionnement passe par la lecture de code concret, pas par la théorie seule. Cet article décompose des exemples de formulaires HTML commentés ligne par ligne, en progressant du mécanisme de base vers des points que les tutoriels classiques laissent souvent de côté : attributs de soumission, association label/input, et contraintes d’accessibilité devenues réglementaires.
Attributs action et method : ce que le formulaire envoie et où
Un formulaire HTML minimal repose sur trois informations : la destination des données, la méthode HTTP utilisée, et au moins un champ de saisie. Voici un exemple commenté :
A lire également : Faut-il internaliser sa MULTIMEDIA EXPERTISE ou la confier à une agence spécialisée ?
<form action="/traitement" method="post"> <input type="text" name="ville" /> <button type="submit">Envoyer</button></form>
L’attribut action définit l’URL qui recevra les données. Si on l’omet, le formulaire envoie les données à la page en cours. L’attribut method accepte deux valeurs principales : get et post.
Lire également : Nouvel étudiant à Nantes ? Tout comprendre sur webmail Nantes
Avec get, les données apparaissent dans l’URL sous forme de paramètres (?ville=Lyon). C’est adapté à une recherche ou un filtre, jamais à un mot de passe. Avec post, les données transitent dans le corps de la requête HTTP, invisibles dans la barre d’adresse.
Le piège fréquent : oublier l’attribut name sur un champ. Sans name, la valeur saisie n’est tout simplement pas transmise au serveur, même si le champ est visible à l’écran.
Balise label et attribut for : lier texte et champ de saisie
Un formulaire lisible associe chaque champ à une étiquette via la balise <label>. Le lien se fait grâce à l’attribut for du label, qui doit correspondre exactement à l’id du champ :
<label for="email">Adresse courriel</label><input type="email" id="email" name="email" />
Quand le for et l’id correspondent, un clic sur le texte du label active directement le champ. Sur mobile, cette zone cliquable élargie améliore la saisie. Pour les lecteurs d’écran, le label associé est lu à voix haute quand le champ reçoit le focus, ce qui rend le formulaire compréhensible sans vision.
Une erreur courante consiste à imbriquer le champ dans le label sans préciser l’attribut for. Certains navigateurs tolèrent cette syntaxe, mais elle pose des problèmes avec plusieurs technologies d’assistance. Mieux vaut toujours écrire le couple for/id explicitement.
Types d’input HTML : choisir le bon type pour chaque donnée
L’attribut type de la balise <input> déclenche un comportement natif du navigateur. Utiliser le bon type évite du JavaScript inutile et améliore l’expérience sur mobile (clavier adapté).
type="email": le navigateur vérifie la présence d’un@avant soumission, et les claviers mobiles affichent directement le symbole@type="tel": aucune validation native, mais le clavier numérique s’affiche sur smartphone, ce qui accélère la saisietype="number": limite la saisie aux chiffres et active les attributsmin,max,steppour borner les valeurs acceptéestype="date": affiche un sélecteur de date natif dans la majorité des navigateurs récents, sans bibliothèque externetype="password": masque les caractères saisis. Le champ reste en texte clair dans le DOM, la sécurité repose sur HTTPS et le traitement côté serveur
Exemple combiné avec validation native :
<form action="/inscription" method="post"> <label for="age">Âge</label> <input type="number" id="age" name="age" min="18" max="120" required /> <button type="submit">Valider</button></form>
L’attribut required empêche la soumission si le champ est vide. Le navigateur affiche un message d’erreur sans aucune ligne de JavaScript.
Formulaire HTML et accessibilité : une obligation réglementaire en France
Depuis la transposition de la directive européenne sur l’accessibilité (loi DDADUE 2023), la qualité du code de formulaire est une obligation légale, pas une option UX. Les entreprises concernées (notamment e-commerce, services bancaires et autres services numériques listés par la directive) doivent garantir que leurs formulaires fonctionnent avec un lecteur d’écran, une navigation clavier, des labels corrects et des messages d’erreur compréhensibles.
Le RGAA (Référentiel général d’amélioration de l’accessibilité) fixe les critères techniques en France. Sa version 5, annoncée pour fin 2026, élargira le périmètre aux applications mobiles et aux documents bureautiques, y compris les formulaires PDF.
En pratique, un formulaire accessible en HTML natif respecte trois règles de base :
- Chaque champ possède un
<label>explicite lié parfor/id, lisible par les technologies d’assistance - Les champs obligatoires sont signalés par l’attribut
requiredet par un texte visible (pas uniquement par la couleur rouge) - Les messages d’erreur identifient le champ concerné et décrivent le problème en texte clair, pas sous forme de code ou d’icône seule
Ce dernier point est souvent négligé. Un message comme « Erreur dans le champ 3 » ne suffit pas. Le message doit nommer le champ et expliquer ce qui est attendu : « L’adresse courriel doit contenir un @ ».
Balise textarea et élément select : au-delà du simple input
La balise <textarea> permet une saisie sur plusieurs lignes. Contrairement à <input>, son contenu par défaut se place entre les balises ouvrante et fermante :
<label for="message">Votre message</label><textarea id="message" name="message" rows="5" cols="40"></textarea>
Les attributs rows et cols définissent la taille visible initiale. Le redimensionnement par l’utilisateur peut être contrôlé en CSS avec la propriété resize.
Pour les choix fermés, la balise <select> génère une liste déroulante. Chaque option porte un attribut value transmis au serveur :
<label for="pays">Pays</label><select id="pays" name="pays"> <option value="">Choisir</option> <option value="fr">France</option> <option value="be">Belgique</option></select>
La première option sans valeur sert de placeholder. Elle force l’utilisateur à faire un choix actif, ce qui évite les soumissions accidentelles avec une valeur par défaut non souhaitée.
Un formulaire HTML bien structuré repose sur le choix du bon élément natif pour chaque type de donnée. Les navigateurs font déjà une grande partie du travail de validation et d’interface quand le code source utilise les attributs prévus par la spécification. Ajouter du JavaScript par-dessus un formulaire mal balisé revient à compenser un problème de fondation.
