La gestion des formulaires
Autre grosse tranche du HTML, la gestion des éléments formulaires. La base de réflexion du HTML5 s’est appuyée sur Web Forms 2.0, ce qui témoigne de l’importance croissante donnée aux interactions entre l’utilisateur et le contenu du web. Rappelons toutefois que les formulaires ne gèrent qu’une partie du processus global. En pratique, un formulaire repose sur une succession d’étapes : saisie des données, validation éventuelle côté client, transmission via HTTP, traitement côté serveur, et enfin intégration dans le système d’information. Dans cette première approche, nous nous concentrerons uniquement sur la structure HTML du formulaire, son balisage et sa configuration minimale.
- Remplissage du formulaire par l’internaute,
- Pré-validation des données avant l’envoi,
- Envoi des données par protocole HTTP,
- Récupération des données côté serveur,
- Injection des données dans le système d’information.
Tout formulaire repose sur une balise <form>, qui délimite l’ensemble du bloc à soumettre. Pour structurer visuellement et logiquement les différents ensembles de champs, nous pouvons utiliser des balises <fieldset>, accompagnées d’un <legend> pour nommer chaque groupe. Ce découpage facilite la lisibilité, mais aussi l’accessibilité, en guidant l’utilisateur dans sa progression. Rien n’interdit de regrouper plusieurs blocs thématiques au sein d’un même formulaire, du moment que la logique reste cohérente.
<form>
<fieldset>
<legend>Informations</legend>
<!-- / Contenu / -->
</fieldset>
<fieldset>
<legend>Inscription</legend>
<!-- / Contenu / -->
</fieldset>
</form>Au-delà du balisage pur, un formulaire doit rester lisible, structuré, logique. Il est souvent tentant d’empiler les champs au fil des besoins, mais cela nuit à la compréhension. Regrouper les éléments par thématique — identité, contact, préférences, options… — facilite le repérage visuel et l’enchaînement clavier. L’ordre des champs doit respecter une progression naturelle, sans surprise, et éviter les retours arrière. Cette cohérence profite à tous les utilisateurs, y compris ceux qui naviguent au clavier ou à l’aide d’un lecteur d’écran.
Les champs de saisie
Chaque champ de saisie doit être accompagné de son étiquette, pour des raisons de clarté comme d’accessibilité. En HTML, cela passe par une balise <label>, liée au champ correspondant grâce à l’attribut for, qui pointe vers l’identifiant (id) du champ. Cette association explicite permet aux lecteurs d’écran et aux technologies d’assistance d’annoncer correctement les libellés. Une autre méthode consiste à imbriquer directement le champ dans la balise <label>, ce qui établit également un lien fonctionnel. Dans tous les cas, l’objectif reste le même : rendre l’interface compréhensible, même sans la vue.
<label for="ch_nom">Nom : </label>
<input type="text" name="ch_nom" id="ch_nom">
<label>Nom : <input type="text" name="ch_nom"></label>Il existe donc trois sortes de champs de saisie, <input>, <textarea> et <select>. A eux trois, les possibilités couvrent quasiment l’ensemble des besoins de nos applications web.
Trois balises principales permettent de recueillir des saisies : <input>, <textarea> et <select>. À elles seules, elles couvrent une grande partie des besoins d’un formulaire web. La balise <input> sert aux saisies simples, en une seule ligne. Depuis HTML5, elle accepte une grande variété de types (text, email, number, date, etc.), chacun activant un comportement adapté selon le navigateur. Pour des contenus plus longs ou multilignes, on utilisera <textarea>, qui conserve une souplesse d’usage précieuse. Enfin, la balise <select>, associée à des <option>, permet de choisir dans une liste prédéfinie. Bien paramétrées, ces trois structures constituent une base fiable pour la plupart des interfaces utilisateur.
Certains champs <input> proposent des choix prédéfinis, en sélection unique ou multiple. Le type checkbox permet à l’utilisateur de cocher plusieurs cases dans un même groupe, tandis que le type radio impose un choix exclusif. Dans les deux cas, le regroupement s’effectue via l’attribut name : toutes les options partageant le même nom seront perçues comme appartenant à un même ensemble. Chaque bouton ou case devra avoir sa propre valeur via l’attribut value, pour que la donnée transmise soit exploitable côté serveur.
<fieldset>
<input type="checkbox" name="groupeA" value="Choix 1">
<input type="checkbox" name="groupeA" value="Choix 2">
</fieldset>
<fieldset>
<input type="radio" name="groupeB" value="Choix 1">
<input type="radio" name="groupeB" value="Choix 2">
</fieldset>Plusieurs méthodes permettent d’assister l’utilisateur dans ses choix, avec des logiques légèrement différentes. Certaines sont figées, d’autres plus souples, et toutes n’offrent pas le même niveau de contrôle. À ce jour, on peut distinguer trois approches principales :
- Le menu déroulant
<select>: propose une liste fermée de choix définis à l’avance. L’utilisateur doit sélectionner une des options proposées, sans possibilité d’en ajouter. - Le couple
<input>+<datalist>: affiche des suggestions associées à une liste d’options, mais laisse la liberté d’entrer une valeur non prévue. L’attributlistde l’input doit pointer vers l’identifiant de la datalist. - L’attribut
autocomplete: permet au navigateur de suggérer des valeurs issues des précédentes saisies de l’utilisateur, sans que le développeur ait à les prévoir.
Selon les usages, l’une ou l’autre de ces méthodes peut s’imposer. Il est donc utile de bien comprendre leurs différences avant de choisir laquelle mettre en œuvre.
<select>
<option>Choix 1</legend>
<option>Choix 2</legend>
<option>Choix 3</legend>
</select>
<input type="text" list="reference" />
<datalist id="reference">
<option>Choix 1</legend>
<option>Choix 2</legend>
<option>Choix 3</legend>
</datalist>
<input type="text" automplete="on" />Paramétrage et envoi du formulaire
Le paramétrage d’un formulaire repose sur quelques attributs fondamentaux de la balise <form>. Même si la logique serveur intervient en aval, une bonne préparation côté client permet de poser les bases d’un envoi propre et contrôlé. Plusieurs attributs jouent ici un rôle déterminant :
actionindique l’adresse vers laquelle les données doivent être envoyées. Il s’agit le plus souvent d’un fichier serveur (.php,.asp,.jsp, etc.). On peut aussi utiliser un lienmailto:, mais cela ne permet pas de joindre de fichiers, et le format reste rudimentaire.methoddétermine le mode de transmission des données.GETest toléré pour les formulaires simples sans enjeu de confidentialité, maisPOSTest préférable pour envoyer des données en volume ou sensibles.enctypeprécise le format des données envoyées :application/x-www-form-urlencodedest le plus courant et convient à tous les champs sauf les fichiers.multipart/form-dataest requis dès qu’un champ de typefileest présent.text/plainreste très marginal, réservé à des cas très spécifiques sans accent ni symbole.
novalidate, s’il est présent, désactive toute validation HTML5 côté navigateur. Cela peut être utile pour laisser JavaScript ou le serveur gérer les vérifications.autocomplete, enfin, active ou désactive les suggestions automatiques proposées par le navigateur. Placé suroff, il empêche la mémorisation des champs (nom, email, etc.). Son bon fonctionnement dépend aussi des réglages du navigateur de l’utilisateur.
La validation d’un formulaire est essentielle, à la fois pour guider l’utilisateur et pour préserver l’intégrité des données reçues. Elle peut intervenir à plusieurs niveaux, souvent de manière complémentaire.
- Côté HTML5, certains attributs permettent de poser des règles simples sans écrire une ligne de script. L’attribut
requiredrend un champ obligatoire, tandis que d’autres (type="email",min,max,pattern, etc.) affinent les contraintes. Pour que cette validation fonctionne, il suffit de ne pas inclure l’attributnovalidatedans la balise<form>. Ce mécanisme natif est pratique mais limité : il ne permet pas, par exemple, de comparer deux champs ou de vérifier la validité réelle d’une adresse mail. - Côté JavaScript, on peut aller plus loin avec des bibliothèques ou des scripts maison. Cela permet de personnaliser les messages d’erreur, d’ajouter des interactions progressives, ou de stopper l’envoi du formulaire tant que certains critères ne sont pas remplis. Des outils comme jQuery Validation étaient populaires, mais aujourd’hui on privilégie souvent des solutions plus légères ou intégrées à un framework.
- Côté serveur, la validation reste incontournable. C’est la seule qui puisse être considérée comme fiable, car elle ne dépend pas du navigateur de l’utilisateur. C’est elle qui vérifie que les données reçues sont bien conformes, cohérentes, et sécurisées avant d’être injectées dans le système d’information.
Dans un projet professionnel, ces trois niveaux sont rarement exclusifs. Mieux vaut combiner validation HTML et JavaScript pour le confort utilisateur, tout en gardant une couche serveur solide pour la sécurité.
Un formulaire peut être techniquement fonctionnel, mais difficile à utiliser pour une partie du public. L’accessibilité ne se limite pas à valider des balises ou à éviter les erreurs de saisie. Elle suppose une attention portée à la clarté des libellés, à l’ordre de navigation au clavier, à la présence de messages d’erreur compréhensibles, et à la compatibilité avec les lecteurs d’écran. Ces éléments peuvent sembler secondaires, mais ils conditionnent l’usage réel du formulaire par toutes et tous. Dans un second temps, des attributs supplémentaires comme ceux issus d’ARIA permettront d’affiner encore cette accessibilité.
Un formulaire doit toujours proposer au minimum un bouton d’envoi. En HTML, cela passe par un champ <input type="submit"> ou un bouton <button type="submit">. On peut y ajouter un bouton de réinitialisation (type="reset"), mais son usage reste discutable car il peut surprendre l’utilisateur en effaçant toutes les données. Enfin, un bouton standard de type button peut être couplé à une fonction JavaScript pour déclencher un traitement personnalisé. Le choix entre ces options dépend du contexte : interface simplifiée, validation asynchrone, ou envoi conditionnel.
<form action="fichier.php" method="post" enctype="application/x-www-form-urlencoded">
<input type="submit" value="Envoyer">
<input type="reset" value="RàZ">
</form>
<form action="fichier.php" method="post" enctype="application/x-www-form-urlencoded">
<input type="button" value="Envoyer" onClick="this.form.submit()">
</form>Accessibilité renforcée : les attributs ARIA et la lisibilité du formulaire
Un formulaire peut être bien balisé, validé et fonctionnel, tout en restant difficile à comprendre ou à utiliser pour une partie des utilisateurs. C’est particulièrement vrai pour les personnes naviguant au clavier, à l’aide d’un lecteur d’écran ou d’une technologie d’assistance. Les attributs ARIA (Accessible Rich Internet Applications) permettent de préciser le rôle, l’état ou les relations entre les éléments d’interface, afin d’améliorer la lisibilité globale du formulaire.
Pour une introduction aux concepts ARIA, on pourra se référer à l’article ARIA les bases… Rôles, repères, états et propriétés, ainsi qu’à la rubrique Accessibilité du site.
Informations et repères
L’utilisateur doit comprendre immédiatement à quoi sert le formulaire et quelles informations sont attendues. On utilise ici les attributs aria-labelledby et aria-describedby pour relier le formulaire à ses éléments de titre et de description. Ces repères sont vocalisés dès l’entrée dans le champ de formulaire.
<form aria-labelledby="titreForm" aria-describedby="descForm">
<h2 id="titreForm">Inscription à l'événement</h2>
<p id="descForm">Veuillez remplir les champs ci-dessous. Les champs marqués d’un astérisque sont obligatoires.</p>Champs à renseigner
Chaque champ doit être lisible, identifiable et associé à un libellé clair. Les attributs aria-required="true" renforcent l’indication de champ obligatoire, en complément de l’attribut HTML required. On peut également relier un champ à une aide contextuelle via aria-describedby.
<fieldset>
<legend>Informations personnelles</legend>
<label for="nom">Nom *</label>
<input type="text" id="nom" name="nom" required aria-required="true">
<label for="email">Adresse e-mail *</label>
<input type="email" id="email" name="email" required aria-required="true" aria-describedby="infoEmail">
<p id="infoEmail">Nous ne partagerons jamais votre adresse.</p>
</fieldset>Boutons d’action
La fin du formulaire doit proposer des boutons lisibles et accessibles, sans surprise. Le bouton submit permet l’envoi, tandis que le bouton reset efface les champs — à utiliser avec prudence pour éviter les effacements involontaires. Par défaut, les boutons HTML sont correctement interprétés par les technologies d’assistance. Il n’est donc pas nécessaire d’ajouter d’attributs ARIA dans un usage classique.
<!-- Bouton désactivé avec indication vocale -->
<button type="submit" disabled aria-disabled="true">Envoyer</button>
<!-- Bouton qui ouvre une section cachée -->
<button type="button" aria-expanded="false" aria-controls="infosComplementaires">
Afficher les informations complémentaires
</button>
<div id="infosComplementaires" hidden>
<!-- contenu complémentaire -->
</div>Enfin, si un CAPTCHA est intégré, il doit rester compréhensible et utilisable sans la souris. Il ne doit pas bloquer la navigation clavier ni être invisible pour les lecteurs d’écran. Des exemples concrets sont disponibles dans les articles Créer un CAPTCHA mathématique en PHP : côté client et Protection de base pour un formulaire.
Conclusion
Concevoir un formulaire HTML ne se limite pas à l’empilement de champs à remplir. Il s’agit de créer une interface structurée, lisible, intuitive, et réellement utilisable. Le balisage s’appuie sur des fondations robustes — <form>, <label>, <input>, <fieldset> — enrichies depuis HTML5 par des types de champs spécifiques et des attributs de validation. Mais pour répondre à tous les usages, l’accessibilité doit aussi guider les choix : structure logique, repères clairs, compatibilité avec les technologies d’assistance.
Les attributs ARIA complètent utilement le balisage HTML, sans le remplacer, et permettent d’adapter les formulaires à une grande diversité de situations. Mieux vaut les intégrer progressivement, en conservant une base propre, compréhensible et facile à maintenir.
