EXPÉRIENCES
OUVERTES

UX WRITING · FORMULAIRE & RÉCEPTION

« Message envoyé » : votre demande est-elle vraiment reçue ?

Comprendre les erreurs, reprendre sa saisie et vérifier la réception : essayez les états d’un formulaire.

Envoyez le formulaire vide. Comparez ensuite les mots, à règles identiques.

Votre demande fictive

Démonstration avec données fictives. Aucun message n’est envoyé à Edikka.

Les quatre champs sont obligatoires.

Le formulaire reste inactif jusqu’au démarrage de JavaScript.

Votre demande fictive

De 1 à 100 caractères. Accents, apostrophes et traits d’union acceptés.

De 1 à 100 caractères. Aucune restriction sur la forme du nom.

Une adresse fictive, par exemple camille@example.test. 254 caractères maximum.

De 10 à 2 000 caractères. Utilisez uniquement des données fictives.

Aucun envoi effectué.

Les mêmes messages apparaissent dans le résumé et près des champs. La validation commence à la soumission, puis se met à jour à la sortie du champ.

Exporter une preuve sans les champs

L’export exclut les valeurs saisies et leurs empreintes. Le lien ne conserve que la langue et le scénario.

EDIKKA · MÉTHODE & LIMITES

Des mots à la mesure de ce qui est connu.

Quatre expériences bornées, deux modes, une même règle : ne confirmer que ce qu’une réponse établit.

Un prolongement du Protocole UX writing

L’archive Edikka du 3 septembre 2026 (v1.0.1) documente deux corrections rédactionnelles sur le contact : UXW07 et UXW08. UXW09 à UXW12 étaient déjà satisfaits. UXW06 appartient au test agents IA et reste « À tester ». Ces observations ne sont pas réécrites par la présente démo.

Simulation publique, laboratoire HTTP réel

Sur GitHub Pages, aucun champ ne quitte le navigateur. Le laboratoire local réserve et stocke réellement en mémoire sur 127.0.0.1 ; le scénario C ferme la connexion après stockage. Les deux modes partagent validation et contrat. Une panne simulée dans le navigateur n’est pas une coupure HTTP réelle.

Clavier, erreurs et annonces

Le résumé reçoit le focus après une soumission invalide. Ses liens ciblent les champs. Les aides restent associées. Une région de statut annonce les réponses sans déplacer le focus ; le résumé ne cumule pas focus et alerte live. Les observations DOM ne prouvent pas ce qu’un lecteur d’écran annonce.

Quatre scénarios documentés

  1. Comprendre et corriger

    Envoyez le formulaire vide. Comparez ensuite les mots, à règles identiques.

  2. Reprendre après un refus

    Le premier envoi valide est refusé avant stockage. La reprise est autorisée et peut réussir.

  3. Réponse perdue

    Le service enregistre, puis la réponse est perdue. Que peut affirmer le formulaire ?

  4. Attendre sans doublon

    Le service attend 4 secondes avant l’enregistrement. Réactivez la commande, puis rejouez la même demande.

Exemple expliqué : après une réponse perdue, une demande peut déjà être enregistrée. Le message reste incertain jusqu’à une réponse de vérification. Reprendre avec la même clé retrouve le même enregistrement.

Aucune conformité globale, étude utilisateurs ou amélioration de conversion déduite. Aucun e-mail livré, aucun contact transmis, aucun stockage durable.

Sources et reproduction

WAI · Forms notifications · WCAG 3.3.1 · WCAG 3.3.3 · WCAG 4.1.3 · GOV.UK · Error summary · GOV.UK · Error message

Commencer une autre demande ?

L’ancienne demande peut encore être traitée. Une nouvelle clé correspond à une autre intention et peut créer un autre enregistrement. Votre saisie actuelle ne sera pas envoyée automatiquement.