UX writing : protocole vérifiable appliqué à trois interfaces réelles Edikka

Un libellé n’est pas « bon » parce qu’il paraît fluide. Il est utile lorsqu’il nomme l’action, l’objet, le prochain état et le niveau de certitude sans demander au lecteur d’interpréter le système. Sur une interface critique, cette promesse doit aussi rester vraie dans le nom accessible, le résumé d’erreurs, le message dynamique et la version anglaise.

Edikka a appliqué cette définition à trois interfaces publiques : le test de préparation aux agents IA, le formulaire de contact et les actions de cet article. Le protocole compte seize contrôles stables. Quinze sont satisfaits après correction ; le seizième reste volontairement « À tester » tant qu’un contre-test VoiceOver et NVDA n’est pas publié.

Le test comparait Edikka à deux concurrents. Access42 était lisible et obtenait 42/45 contre 40/45 pour Edikka. Claude.ai ne livrait qu’un résultat partiel, 10/45, explicitement non décisif. L’ancienne interface résumait pourtant l’ensemble par « Retard apparent, à confirmer ». La précaution appliquée au scan faible contaminait la comparaison fiable.

Le correctif ne cherche pas une formulation plus positive. Il sépare les ensembles de preuve : « Retard confirmé face à 1 concurrent ; 1 résultat non décisif. » L’écart confirmé reste de deux points. Le résultat faible demeure visible, mais ne crée ni n’efface un avantage.

Lors d’une soumission vide, le formulaire identifiait déjà les erreurs par écrit, plaçait le focus sur le résumé, reliait les liens aux champs et exposait aria-invalid ainsi que aria-describedby. Quatre mécanismes utiles étaient donc présents. Le défaut se trouvait dans la précision des mots : le titre du résumé restait générique et ses liens paraphrasaient parfois le message affiché près du champ.

La version corrigée annonce « 4 champs à corriger avant d’envoyer votre demande. » puis reprend chaque message exactement. Si un seul champ échoue, le singulier est utilisé. Cette identité n’est pas esthétique : elle évite qu’un même problème porte deux formulations selon l’endroit où l’utilisateur le rencontre.

Le panneau d’action générique proposait un diagnostic et une checklist sans nommer l’actif de cette page. La nouvelle édition donne la priorité à deux sorties concrètes : « Télécharger la grille UX writing (XLSX) » et « Auditer une interface ». Le format est visible avant le clic et la destination commerciale annonce son périmètre.

La réécriture conserve ce qui était déjà conforme : les liens restent natifs, leur nom accessible contient le libellé visible, la version anglaise conserve la même intention et le téléchargement porte un nom de mesure stable. La mise à jour est datée dans ce changelog afin de ne pas masquer qu’un CTA d’insight a changé pendant la fenêtre d’observation MIA-FR.

Quatre tests techniques bornent cette méthode. D’abord, le nom accessible d’un contrôle contient son libellé visible : une personne qui commande à la voix peut donc prononcer les mots qu’elle voit. Ensuite, une erreur est identifiée par du texte et reliée au champ. Troisièmement, le résumé permet de rejoindre l’erreur sans remplacer son message en ligne. Enfin, un résultat injecté dynamiquement est exposé comme message de statut lorsque le changement de contexte ne doit pas déplacer le focus.

Ces tests sont nécessaires, mais leur présence dans le DOM ne prouve pas l’expérience complète. C’est pourquoi UXW06 reste « À tester ». La prochaine révision doit publier le système, le navigateur, la version de VoiceOver ou NVDA, les étapes et l’annonce réellement entendue. La méthode préfère un résultat incomplet mais exact à un 16/16 déduit du code.

Ce document n’est ni un classement indépendant, ni une étude utilisateur, ni une certification. Les critères d’intégrité de preuve sont une doctrine éditoriale Edikka ; ils ne sont pas attribués au W3C. Les contrôles WCAG cités portent uniquement sur les propriétés qu’ils couvrent.

La sélection des trois interfaces privilégie des états où le texte change une décision, une correction ou un engagement. Elle n’échantillonne pas l’ensemble du site. Les captures documentent un contexte donné ; elles ne remplacent pas le DOM, le fichier source ni le contre-test. Toute objection reproductible peut être intégrée au changelog avec son auteur et la correction retenue ou refusée.