Ce que promet le système
Le formulaire doit recueillir assez de contexte pour répondre utilement, sans exiger un cahier des charges. Partez de la prochaine décision : adéquation de la demande, personne chargée de l'examiner, incertitude à discuter. Chaque champ obligatoire doit servir l'une de ces décisions.
Comparer les options pratiques
Nom, adresse de réponse et description simple peuvent suffire. Type de projet ou fourchette budgétaire aident si les options sont compréhensibles et autorisent l'incertitude. N'imposez pas de téléphone par habitude. Le guide W3C décrit libellés, instructions et retours comme des éléments fonctionnels.
Tester le parcours complet
Une fondatrice a par exemple une idée sans échéance. Proposez une réponse honnête plutôt qu'une date inventée. Si l'adresse est invalide, identifiez le champ, expliquez la correction et conservez le texte du projet. Après envoi, distinguez demande enregistrée et erreur de transmission. Personne ne devrait deviner si un nouveau clic crée un doublon.
Rendre la reprise visible
Un texte indicatif ne remplace pas un libellé ; la couleur seule ne suffit pas pour une erreur. Placez les erreurs près des champs et ajoutez un résumé accessible si nécessaire. Testez clavier, zoom, longs libellés traduits et réseau lent. Le succès doit refléter une réception durable et une suite réelle, sans promesse de délai inventée.
Revoir le formulaire comme conversation et transaction
Notez pourquoi chaque champ est nécessaire maintenant, son lecteur et le traitement d'une réponse inconnue. Si le budget oriente l'échange, utilisez les fourchettes réelles de l'équipe et une option indécise. N'imposez pas taille, architecture ou date inventées pour passer. Le contexte complémentaire peut venir après une réponse, lorsque son but est plus clair.
Testez la correction avec un formulaire rempli : long projet, adresse erronée, envoi. Le message explique simplement, garde les données valides et facilite l'accès au champ. Gérez le focus du résumé d'erreurs avec soin et annoncez sans interruptions répétées. Recommencez avec lecteur d'écran et texte agrandi ; proximité visuelle ne suffit pas à relier message et champ.
Vérifiez le serveur. Une réponse perdue après sauvegarde diffère d'une demande jamais arrivée. La reprise doit retrouver le même dossier et confirmer sa réception durable. L'entrée dans une file ne prouve pas l'envoi du message. Expliquez la suite et l'accès à l'aide. Utilisez coordonnées fictives et destination locale ; inspectez demande stockée, notification et confirmation.
Preuves d'acceptation du formulaire
| Situation | Expérience attendue |
|---|---|
| Réponse inconnue | Une option indécise ou un champ facultatif permet de rester honnête. |
| Champ invalide | L'erreur le nomme, explique la correction et préserve le reste. |
| Connexion perdue après stockage | Une reprise sûre retrouve la même demande sans doublon. |
| Notification retardée | La demande reste reçue ; aucune livraison mensongère ni ressaisie totale exigée. |
Exemples pour la revue
Quelles réponses changent l'action suivante ? Une personne non technique peut-elle répondre aux questions obligatoires ? La reprise après coupure est-elle sûre ? Examinez un envoi normal et un échec comme parcours complets, pas seulement le formulaire vide.