La connexion d'un visiteur se coupe pendant le chargement de votre formulaire. Une extension Chrome casse votre JavaScript. Un ancien navigateur ne prend pas en charge le JavaScript que vous utilisez. Son lecteur d'écran ne peut pas parcourir votre formulaire parce que les libellés sont masqués en CSS.
Les formulaires sont des passages critiques. Les utilisateurs doivent pouvoir les envoyer. Le formulaire ne peut pas simplement planter. L'amélioration progressive est le principe qui consiste à construire des formulaires qui fonctionnent partout, puis à ajouter des améliorations pour les navigateurs qui les gèrent.
Cet article explique comment construire des formulaires qui se dégradent proprement, fonctionnent sans JavaScript et restent accessibles à tout le monde.
Qu'est-ce que l'amélioration progressive ?
L'amélioration progressive consiste à partir d'un formulaire de base qui fonctionne dans les plus anciens navigateurs et sans JavaScript, puis à ajouter des améliorations par couches pour les navigateurs modernes. La couche 1 (HTML) fournit un formulaire de base avec des champs, des libellés et un bouton d'envoi, qui n'a besoin d'aucun JavaScript et fonctionne partout. La couche 2 (CSS) met en forme le formulaire avec des couleurs, des espacements et une mise en page : si le CSS ne se charge pas, le formulaire fonctionne toujours, il est simplement moins joli. La couche 3 (JavaScript) ajoute la validation en temps réel, des animations fluides et l'envoi en AJAX : si le JavaScript échoue, le formulaire fonctionne toujours et s'envoie de façon classique. Si une couche échoue, l'utilisateur obtient quand même un formulaire qui fonctionne. C'est la résilience.
La base : un HTML qui fonctionne
Commencez par un HTML sémantique, avec de vrais libellés, des fieldsets et des éléments legend. Un formulaire de base ressemble à <form action="/submit" method="POST"> <label for="email">Email</label> <input type="email" id="email" name="email" required> <label for="message">Message</label> <textarea id="message" name="message" required></textarea> <button type="submit">Send</button> </form>. Ce formulaire fonctionne sans JavaScript, sans CSS, dans les anciens navigateurs, avec les lecteurs d'écran et avec la navigation au clavier. C'est votre base. Ne retirez jamais des éléments du DOM pour les remplacer par des éléments générés en JavaScript : si le JavaScript échoue, le formulaire casse. Gardez le HTML sémantique.
Une dégradation propre avec le CSS
Ajoutez les améliorations CSS par-dessus le HTML. Soignez l'apparence du formulaire. Mais si le CSS échoue, le formulaire doit toujours fonctionner.
Ne masquez pas les libellés en CSS pour ne garder que les textes d'exemple (placeholders) : certains CSS ne se chargent pas et les lecteurs d'écran ont besoin des libellés dans le HTML. N'utilisez pas le CSS pour masquer les indicateurs de champ obligatoire : si votre « étoile obligatoire » personnalisée ne se charge pas, les utilisateurs ne savent plus quels champs sont obligatoires. Utilisez plutôt l'attribut HTML required. Évitez de masquer visuellement le libellé pour afficher un placeholder à la place avec label { display: none; } et input::placeholder { content: 'Email'; }. Gardez plutôt le libellé dans le HTML et mettez-le en forme comme vous voulez avec label { font-weight: bold; color: #333; }.
Des améliorations JavaScript qui se dégradent proprement
Ajoutez des améliorations JavaScript, mais seulement si le formulaire fonctionne déjà. Utilisez la détection de fonctionnalités pour vérifier si le navigateur prend en charge ce dont vous avez besoin, avec if (window._blocked_) { // Use _blocked_ for AJAX submission } else { // Form submits traditionally }. Ne partez pas du principe que les fonctionnalités existent. Partez du principe qu'elles peuvent manquer. Détectez d'abord.
Validation en temps réel avec solution de repli
Utilisez la validation HTML comme base avec <input type="email" required> pour que le navigateur valide à l'envoi. Ajoutez ensuite une validation JavaScript en temps réel avec input.addEventListener('blur', () => { if (!isValid(input.value)) { input.classList.add('invalid'); showError(input, 'Invalid email'); } });. Elle affiche les erreurs pendant la saisie, et si le JavaScript échoue, la validation intégrée du navigateur fonctionne toujours. L'utilisateur profite d'un retour en temps réel, et si le JavaScript échoue, il obtient un retour à l'envoi de la part du navigateur. Dans les deux cas, la validation a lieu.
Envoi en AJAX avec repli classique
Construisez un formulaire classique qui s'envoie côté serveur, puis interceptez l'envoi pour utiliser AJAX à la place avec form.addEventListener('submit', async (e) => { e.preventDefault(); const response = await _blocked_('/submit', { method: 'POST', body: new FormData(form) }); if (response.ok) { showMessage('Success'); } });. Si le JavaScript échoue, preventDefault ne s'exécute jamais, le formulaire s'envoie de la façon classique, et l'utilisateur obtient un rechargement de page au lieu d'une expérience fluide. Mais le formulaire fonctionne.
L'accessibilité comme amélioration progressive
L'accessibilité n'est pas une fonction en plus. C'est la base. Construisez des formulaires accessibles.
Les libellés doivent être reliés aux champs avec les attributs for et id. Pas des data-attributes, pas des aria-labels qui peuvent passer inaperçus. De vrais libellés.
<label for="email">Email</label>
<input id="email">
Utilisez des éléments HTML sémantiques (fieldset, legend, button, input). Pas des div stylées pour ressembler à des boutons.
La navigation au clavier doit fonctionner. Tab pour parcourir tous les champs. Maj+Tab pour revenir en arrière. Entrée pour envoyer. Espace pour cocher une case. Cela fonctionne par défaut avec du HTML sémantique. Ne le cassez pas avec du JavaScript.
Une fois la base en place, ajoutez des libellés ARIA pour les lecteurs d'écran. Ajoutez des indicateurs de focus pour les personnes qui naviguent au clavier. Mais ce sont des améliorations qui s'ajoutent à un HTML accessible.
Tester la résilience
Testez votre formulaire avec JavaScript désactivé. Désactivez le JavaScript dans votre navigateur et essayez d'envoyer le formulaire. S'il casse, il n'est pas résilient.
Testez avec des réseaux lents. Limitez votre connexion à de la 2G. Si le formulaire met une éternité à se charger, les visiteurs avec une connexion capricieuse partiront.
Testez avec d'anciens navigateurs. Utilisez un service de test multi-navigateurs pour vérifier d'anciennes versions (si vous en avez encore besoin). Repérez les fonctionnalités non prises en charge.
Testez avec des lecteurs d'écran. Utilisez celui de Windows ou celui de Mac. Écoutez comment le formulaire est annoncé. Si cela n'a aucun sens pour un lecteur d'écran, corrigez.
Testez uniquement au clavier. N'utilisez pas la souris. Pouvez-vous parcourir le formulaire ? Pouvez-vous l'envoyer ?
Détecter les fonctionnalités, pas les navigateurs
Ne testez pas des navigateurs précis. Testez les fonctionnalités plutôt que d'utiliser une détection de navigateur comme if (navigator.userAgent.includes('Chrome')) { /* use _blocked_ */ }. Utilisez plutôt la détection de fonctionnalités comme if (window._blocked_) { /* use _blocked_ */ }. La détection de fonctionnalités est plus fiable : une mise à jour du navigateur qui ajoute la prise en charge de _blocked_ fonctionnera avec votre code, alors que la détection de navigateur ne suivra pas.
Comment WEMASY construit des formulaires résilients
Les formulaires WEMASY sont construits selon les principes de l'amélioration progressive : ils fonctionnent sans JavaScript, ont des libellés et un HTML sémantique en place, et des améliorations JavaScript facultatives. Les anciens navigateurs obtiennent un formulaire qui fonctionne et les navigateurs modernes des interactions fluides.
Découvrez les fonctions de résilience dans votre offre WEMASY.