Formulaires accessibles : concevoir, tester et corriger le parcours

Un formulaire réussit lorsque la personne comprend ce qui est demandé, peut corriger une erreur et sait si son message est arrivé. Le nombre de champs ne suffit pas à juger sa qualité : une demande de devis et une inscription n’ont pas les mêmes besoins.

Partir de la tâche à accomplir

Écrivez le résultat attendu avant de dessiner les champs. Pour un artisan, il peut s’agir de comprendre le type de travaux, la commune et le moyen de rappeler le client. Une pièce jointe peut aider, mais ne devrait pas empêcher une première prise de contact si elle n’est pas indispensable.

Indiquez quels champs sont facultatifs. Donnez les consignes avant la saisie : types de fichiers acceptés, informations utiles dans le message et prochaine étape. Le guide du devis de site internet peut servir à préparer ce cadrage.

Exemple réel : publier une actualité avec MAHVU

Dans le projet MAHVU, le besoin décisif concernait la publication d’articles par des membres aveugles. J’ai développé un formulaire accessible depuis le site, pour éviter de leur imposer l’administration WordPress. Le parcours a été testé avec plusieurs lecteurs d’écran puis essayé par les membres.

La leçon est concrète : tester uniquement la page d’accueil n’aurait pas validé leur autonomie. Il fallait parcourir toute la tâche de publication. Ces essais d’usage sont documentés dans l’étude de cas ; ils ne constituent pas un audit RGAA officiel ni une garantie de conformité générale.

Rendre les champs compréhensibles

Associez un label visible à chaque champ. Un placeholder peut fournir un exemple mais disparaît lorsque la personne écrit. Regroupez les choix liés, donnez un nom explicite au bouton et utilisez les types de saisie adaptés. Ces bases sont décrites dans le tutoriel formulaires du W3C.

<label for="email">Votre adresse email</label>
<p id="email-help">Elle servira à répondre à votre demande.</p>
<input id="email" name="email" type="email"
       autocomplete="email" aria-describedby="email-help" required>
<button type="submit">Envoyer ma demande</button>

Ce fragment illustre le lien entre champ et consigne. Il ne remplace pas le traitement de l’envoi, les contrôles serveur ni les informations sur les données collectées.

Prévoir les erreurs avant le succès

Testez un champ vide, une adresse incorrecte et un fichier trop volumineux. Le message doit dire ce qui est à corriger, rester associé au champ et ne pas reposer uniquement sur une couleur. Conservez les valeurs déjà saisies.

Au moment de l’envoi, affichez un état d’attente sans supprimer tout le formulaire. En cas de coupure réseau, indiquez que l’envoi n’a pas été confirmé et permettez un nouvel essai. N’affichez pas « message envoyé » avant d’avoir reçu une confirmation du serveur.

Après le succès, annoncez clairement ce qui suit : demande reçue, réponse par email ou réservation encore à confirmer. Distinguez une demande de rendez-vous d’un créneau réellement réservé.

Contrôler la sécurité sans rendre le parcours impraticable

La validation navigateur facilite la saisie ; le serveur doit vérifier les données indépendamment. Limitez la taille et les formats des fichiers, contrôlez les autorisations et évitez de publier les pièces jointes dans un dossier accessible à tous.

Une protection anti-spam doit aussi être testée avec le clavier et les technologies d’assistance. Un champ piège seul ne garantit pas l’absence de spam. Mesurez les abus avant d’imposer une vérification complexe à tous les visiteurs. Le guide de sécurité complète ces points.

Un scénario de recette à conserver

1. Parcourir le formulaire avec Tab, Majuscule + Tab et Entrée, sans souris.
2. Vérifier l’ordre des champs, les intitulés et le focus visible.
3. Envoyer volontairement des données incomplètes et corriger les erreurs.
4. Refaire le parcours sur mobile avec le clavier ouvert et du texte agrandi.
5. Tester une panne réseau et un second envoi, sans créer de doublon.
6. Vérifier la réception réelle du message sur un environnement de test et l’annonce de confirmation.

Notez le navigateur, les aides techniques utilisées et les limites observées. Cette recette sert ensuite aux mises à jour. Pour un parcours de réservation ou de publication particulier, mes prestations d’accessibilité commencent par l’identification de la tâche et de ses utilisateurs.