Le vocabulaire UI qui transforme une idée vague en instruction fiable

Les mots « menu », « popup », « champ intelligent » ou « panneau » décrivent souvent plusieurs concepts. Avant de choisir une primitive, décomposez la demande. Le but explique ce que la personne essaie d’accomplir. Le concept donne un nom partagé. Le comportement décrit ce qui se passe. Les états montrent les variations. L’apparence règle la présentation sans redéfinir la fonction.

Cette séparation évite deux erreurs fréquentes : choisir un composant parce qu’il lui ressemble et demander à l’IA de recréer toute l’interface pour une modification locale. Un tooltip et un popover peuvent apparaître près d’un déclencheur, mais ils ne portent pas le même contenu ni la même interaction. Un drawer et une sidebar peuvent occuper le même bord, mais l’un est temporaire et l’autre structure durablement la page.

Lorsqu’un terme reste incertain, posez la question qui change le contrat. Le contenu doit-il être interactif ? La page derrière reste-t-elle utilisable ? La personne peut-elle saisir du texte ? Le choix déclenche-t-il une action ou sélectionne-t-il une valeur ? La surface est-elle permanente ou temporaire ?

Ces discriminants sont plus robustes qu’une description visuelle. Ils permettent également à l’agent de s’abstenir au lieu d’inventer un nom. Si plusieurs réponses restent possibles, demandez jusqu’à trois candidats avec leur différence principale avant toute implémentation.

Commencez par demander l’inspection de l’existant si l’agent travaille dans un dépôt. Nommez ensuite le changement local et les éléments à préserver. Décrivez le scénario utilisateur, puis le comportement attendu dans un ordre observable. Ajoutez les contraintes techniques uniquement lorsqu’elles sont vérifiées dans le projet.

Terminez par une checklist courte. Chaque critère doit pouvoir être observé dans l’interface ou démontré par un test. « L’expérience est intuitive » n’est pas vérifiable. « Échap ferme la surface et le focus revient au bouton d’ouverture » l’est.

Privilégiez d’abord les éléments HTML natifs lorsqu’ils portent déjà le comportement recherché. Les rôles ARIA décrivent une sémantique aux technologies d’assistance ; ils n’ajoutent pas automatiquement le clavier, le focus ou les états. L’ARIA Authoring Practices Guide propose des modèles et exemples utiles, mais précise qu’il ne s’agit ni d’un standard normatif complet ni d’un design system prêt pour la production.

Pour chaque surface interactive, vérifiez le nom accessible, l’ordre de tabulation, les touches attendues, le focus visible, la restauration du focus, l’annonce des changements et le comportement en contraste renforcé. L’apparence ne doit jamais être le seul signal d’un état sélectionné, invalide ou désactivé.

Relisez le résultat en trois passages. Le premier confirme la mission : la personne peut-elle accomplir la tâche ? Le deuxième inspecte le comportement : états, focus, fermeture, retour arrière, scroll et responsive. Le troisième vérifie l’intégration : composants existants réutilisés, périmètre de fichiers limité et tests pertinents.

Les captures sont utiles pour la composition visuelle, mais elles ne prouvent ni le clavier ni les états cachés. Combinez inspection statique, interactions réelles et assertions automatisées. Si un appareil, un navigateur ou une revue humaine n’a pas été exécuté, conservez ce point comme gate ouvert au lieu de le déduire d’un test voisin.