Concevoir un formulaire de projet aux champs et erreurs clairs

Un long formulaire de projet se révise plus précisément lorsque l’étape de travail suivante est claire. Déterminez d’abord les informations dont l’équipe a réellement besoin. Planifiez ensuite ensemble les libellés, la validation et les retours.

Partir de l’étape de travail suivante

Dans le portail fictif ci-dessous, l’équipe doit classer une première demande logicielle et poser des questions par e-mail. Titre du projet, objectif et e-mail sont donc obligatoires. Le téléphone reste facultatif. Adresse de facturation et numéro client interne ne sont pas exigés pour cette première demande. Cette décision concerne le parcours d’exemple.

W3C WAI recommande de ne demander que les informations nécessaires au processus concerné. Chaque question conservée doit avoir un but compréhensible.

Garder les libellés visibles

Les libellés restent visibles pendant la saisie et sont associés techniquement aux champs. Un texte indicatif dans un champ vide ne remplace pas le libellé : il disparaît pendant la saisie. Le but et le caractère facultatif sont donc précisés à côté du champ.

« Facultatif » doit correspondre à la validation lors de l’envoi. Un champ de téléphone laissé vide ne doit pas provoquer d’erreur dans ce parcours.

Relier l’erreur à la situation précise

Pour ce formulaire, la validation est prévue lors de l’envoi. Information absente, saisie incomplète et transmission non confirmée reçoivent des retours différents.

Un contrôle de format ne confirme pas que la boîte est joignable. Un problème de transmission n’est pas présenté comme une erreur de saisie de l’e-mail.

Corriger sans perdre les données

Après une erreur de saisie, le modèle prévoit un récapitulatif qui reçoit le focus clavier et contient un lien vers le champ concerné. Le même message compréhensible figure près du champ ; les technologies d’assistance doivent pouvoir l’y associer. Les valeurs déjà saisies restent présentes, y compris celle à corriger.

Le message de succès suit uniquement la confirmation de réception par le serveur. Si le résultat est incertain, le parcours de renvoi doit préciser comment reconnaître une demande peut-être déjà reçue.

Vérifier une tâche complète

Faites remplir la demande d’exemple sans téléphone. Vérifiez aussi le parcours d’erreur avec un e-mail incomplet : peut-on trouver le message, corriger l’adresse et terminer la demande tout en conservant l’objectif du projet ? Incluez clavier, écran étroit et technologies d’assistance utilisées. Notez où la personne a besoin d’aide et si la réception est effectivement confirmée à la fin.

Sources

• W3C WAI — Forms Tutorial

• W3C WAI — Form Instructions

• W3C WAI — User Notification

• GOV.UK — Recover from validation errors

• GOV.UK — Email addresses

• GOV.UK — Moderated usability testing