Rendre un formulaire métier plus accessible

Améliorez l’accessibilité des formulaires métier : libellés, clavier, messages d’erreur et conservation de la saisie, avec des vérifications concrètes.

Une personne remplit une demande, valide et voit plusieurs champs encadrés en rouge. Rien n’explique ce qui manque. Une autre utilise le clavier et ne parvient pas à ouvrir le sélecteur de date. Ces difficultés peuvent bloquer le travail même lorsque les champs correspondent au besoin métier.

L’accessibilité d’un formulaire se prépare avec sa structure et son comportement. Les vérifications proposées ici portent sur des situations courantes. Elles ne constituent pas un audit complet ni une garantie de conformité à toutes les exigences applicables au produit.

Donner un libellé stable à chaque champ

Le nom du champ doit rester visible lorsque l’utilisateur commence à saisir. Un texte indicatif à l’intérieur de la zone peut fournir un exemple, mais disparaît généralement pendant la saisie. Il ne remplace donc pas un libellé durable.

Le tutoriel W3C sur les libellés de formulaire décrit leur association avec les contrôles. En HTML, cette association doit être programmatique afin que les technologies d’assistance puissent identifier le champ. Le développeur peut vérifier le nom accessible calculé dans les outils du navigateur.

Choisissez des mots compréhensibles pour les utilisateurs. « Référence interne » reste ambigu si l’équipe manipule plusieurs références. Ajoutez un exemple ou une aide à proximité lorsque cela évite une confusion. Conservez les explications nécessaires dans un endroit accessible au clavier et aux lecteurs d’écran.

Expliquer les exigences avant la validation

Signalez les champs obligatoires de façon cohérente et expliquez la convention employée. Une couleur seule ne suffit pas à transmettre cette information. Indiquez les formats réellement imposés et évitez d’exiger un format étroit sans nécessité métier.

Pour un montant, précisez la devise et le contexte attendu. Pour une date, évitez les exemples qui peuvent être interprétés de deux façons. Un formulaire destiné à des utilisateurs francophones et arabophones demande aussi une vérification de l’ordre de lecture et du comportement des contenus mixtes.

Les instructions longues peuvent être placées dans une aide complémentaire, mais les exigences indispensables doivent être disponibles au moment de saisir. L’utilisateur ne devrait pas apprendre après soumission qu’un document devait respecter une taille ou un type particulier.

Vérifier le parcours au clavier

Parcourez le formulaire sans souris. L’ordre de passage doit suivre une progression compréhensible et l’élément actif doit être repérable. Testez les boutons secondaires, les menus et les commandes de téléchargement autant que les zones de saisie.

Les composants personnalisés demandent une attention particulière. Un menu visuellement élégant peut ne pas gérer les touches attendues. Privilégiez les contrôles natifs lorsqu’ils répondent au besoin ; si vous créez un composant spécifique, documentez et testez son interaction.

Essayez aussi de revenir en arrière pour corriger une valeur. Une fenêtre de confirmation ne doit pas retenir le focus sans moyen de sortie prévu. Après sa fermeture, l’utilisateur doit retrouver un point logique du parcours au lieu de recommencer la navigation depuis le haut de la page.

Rendre les erreurs compréhensibles et repérables

Un message utile identifie le problème et indique comment le corriger lorsque la solution est connue. « Saisie invalide » laisse trop d’interprétation. Dans un exemple fictif, « indiquez une quantité entière supérieure à zéro » donne une consigne vérifiable.

Le tutoriel W3C sur les notifications de formulaire présente des moyens de signaler les résultats et les erreurs. Selon le formulaire, une synthèse en tête avec des liens vers les champs concernés aide à retrouver les corrections nécessaires. Les messages doivent aussi être associés aux contrôles qu’ils décrivent.

Ne déclenchez pas une erreur agressive pendant que la personne est encore en train de composer une valeur. Définissez à quel moment la vérification devient utile : sortie du champ ou tentative de validation, selon le cas. Si le serveur refuse une donnée que le navigateur accepte, présentez ce refus de manière cohérente.

Conserver le travail après un échec

Une erreur de validation ne doit pas effacer inutilement les champs déjà remplis. Vérifiez les formulaires longs, les pièces jointes et les étapes successives. Certaines données sensibles demandent un traitement particulier ; leur comportement doit être conçu explicitement.

Si la session peut expirer, prévenez l’utilisateur de manière adaptée et examinez la possibilité de prolonger son travail. Quand un brouillon existe, indiquez s’il a réellement été enregistré. Un message optimiste affiché avant confirmation peut donner une fausse assurance.

Après soumission, distinguez une demande enregistrée d’une demande encore en cours de traitement. La confirmation doit permettre de savoir quoi faire ensuite et éviter une nouvelle soumission involontaire. Le retour visuel doit être accompagné d’une information accessible aux technologies d’assistance.

Préparer une séance de vérification courte

Utilisez un dossier fictif et exécutez un parcours complet. Faites volontairement une erreur puis corrigez-la. Répétez avec le clavier, un agrandissement de l’affichage et, avec les compétences nécessaires, un lecteur d’écran.

Ajoutez les défauts relevés au registre de recette utilisateur. Les outils automatiques peuvent repérer certains problèmes, mais la vérification du parcours et de la compréhension demande aussi une observation humaine. Conservez les cas réussis pour les rejouer lorsque le formulaire ou ses composants changent.