# Documenter un patron d’interaction accessible réutilisable par toute une équipe > Décrire un patron d'interaction accessible comme une définition explicite, vérifiable par une machine, plutôt que comme une simple recommandation écrite qu'un agent générateur peut ignorer. - Auteur : WordPress Développement - Publié le : 2026-07-31 - Mis à jour le : 2026-07-31 - Catégorie : Accessibilité - URL : https://www.wpmoderne.fr/accessibilite/documenter-patron-interaction-accessible-equipe/ ## L’essentiel - Un patron documenté sous forme de texte seul reste facultatif dans la pratique - Une définition d'ability vérifiable rejette une génération non conforme avant publication - Le contrôle porte sur la structure de l'interaction, jamais sur le contenu généré La documentation officielle de WordPress décrit une « ability » comme une capacité déclarée, avec des entrées et des sorties définies, qu'un agent logiciel peut découvrir et invoquer de façon structurée. C'est cette même logique de contrat vérifiable qui a inspiré, sur un projet exposant plusieurs Abilities API à un assistant de génération d'interface interne, une manière radicalement différente de documenter un patron d'interaction accessible : non plus comme un texte de recommandation dans un wiki, mais comme une définition que le système peut vérifier lui-même avant d'accepter une génération. Le constat de départ était simple : une documentation textuelle d'un patron accessible — par exemple, « un menu déroulant doit se fermer avec Échap et rendre le focus à son déclencheur » — reste une bonne intention tant qu'aucun mécanisme ne vérifie qu'elle a été respectée. Un agent générateur d'interface, humain ou automatisé, peut très bien produire un menu déroulant syntaxiquement valide qui ignore complètement cette règle, sans qu'aucune alerte ne soit levée avant la mise en production. ## D'une recommandation écrite à une définition vérifiable La première étape a consisté à transformer chaque patron d'interaction jugé critique (menu déroulant, onglets, fenêtre modale, accordéon) en une structure de données décrivant ses propriétés attendues plutôt qu'en un paragraphe de prose : rôle ARIA attendu sur le conteneur, liste des touches de clavier qui doivent produire un effet, comportement de restitution du focus à la fermeture, présence obligatoire d'un nom accessible sur l'élément déclencheur. Cette structure de données devient alors le contrat de référence contre lequel toute génération, humaine ou assistée, peut être comparée automatiquement, plutôt que de dépendre de la mémoire ou de la bonne volonté du développeur au moment de l'implémentation. ## Où s'articule le contrôle avec l'Abilities API Sur ce projet, une ability nommée `verifier-patron-interaction` a été déclarée via l'Abilities API introduite avec WordPress 6.9 : elle prend en entrée la structure HTML générée pour un composant interactif donné, et retourne un verdict structuré indiquant si les propriétés attendues du patron correspondant sont respectées. Cette ability est invoquée systématiquement avant qu'une génération produite par l'assistant interne ne soit proposée à validation humaine, ce qui permet de rejeter automatiquement une proposition non conforme avant même qu'un relecteur humain n'ait à s'en préoccuper. > L'essentiel à retenir : Un patron documenté sous forme de texte seul reste facultatif dans la pratique ; Une définition d'ability vérifiable rejette une génération non conforme avant publication ; Le contrôle porte sur la structure de l'interaction, jamais sur le contenu généré ## Ce que le contrôle vérifie, et ce qu'il ignore volontairement Le contrôle porte exclusivement sur la structure de l'interaction : présence des attributs ARIA attendus, gestion effective des touches de clavier requises, comportement du focus à l'ouverture et à la fermeture. Il ne porte jamais sur le contenu généré à l'intérieur du composant — le texte d'un menu, les libellés d'un onglet — qui reste hors du périmètre de cette vérification et relève d'une tout autre question éditoriale. Cette séparation nette entre structure d'interaction et contenu est délibérée : elle évite de transformer un contrôle d'accessibilité technique en un filtre éditorial flou, dont les critères deviendraient rapidement subjectifs et contestables. ### Les six propriétés vérifiées pour un menu déroulant - Le conteneur du menu porte un rôle ARIA cohérent avec son comportement réel. - La touche Échap ferme le menu et rend le focus à son déclencheur. - Les flèches haut et bas déplacent le focus entre les options du menu. - Le déclencheur porte un attribut `aria-expanded` synchronisé avec l'état réel du menu. - Un clic en dehors du menu le referme sans piéger le focus. - Le déclencheur possède un nom accessible non vide. ## Faire vivre la définition dans le temps Une définition d'ability figée au moment de sa création perdrait rapidement sa pertinence à mesure que de nouveaux cas d'usage apparaissent. Chaque violation détectée par le contrôle mais jugée finalement acceptable après revue humaine (un cas limite légitime, par exemple un menu contextuel à comportement volontairement différent) déclenche une révision explicite de la définition elle-même, documentée dans l'historique de version du projet, plutôt qu'une simple exception ponctuelle non tracée. ## En résumé Documenter un patron d'interaction accessible sous forme de définition vérifiable, plutôt que de simple recommandation textuelle, déplace le contrôle d'une question de discipline individuelle vers une question de conformité automatiquement vérifiable — un changement d'autant plus utile à mesure que la génération d'interface s'appuie de plus en plus sur des agents logiciels plutôt que sur une saisie manuelle exclusive.