Une couche longtemps sous-estimée
L’arbre d’accessibilité a longtemps été abordé comme une question d’accessibilité au sens strict. C’est déjà une raison suffisante de le traiter sérieusement : les personnes qui utilisent des technologies d’assistance dépendent de cette couche pour comprendre et manipuler l’interface.
Mais à l’ère agentique, cette couche prend une portée supplémentaire.
Google explique dans Build agent-friendly websites que les agents modernes combinent plusieurs modalités : DOM, accessibility tree et rendu visuel. L’arbre d’accessibilité leur fournit une liste structurée des rôles, noms et états interactifs. Autrement dit, il agit comme une carte fonctionnelle de la page.
Ce que l’arbre révèle
Le rendu visuel dit : « voici ce qui apparaît à l’écran ».
Le DOM dit : « voici comment les éléments sont structurés ».
L’arbre d’accessibilité dit : « voici ce que les éléments sont censés faire ».
Cette troisième information est cruciale. Un agent peut voir une forme rectangulaire avec du texte. Mais si l’élément n’est pas exposé comme un bouton nommé, il doit inférer sa fonction. Et chaque inférence ajoute du risque.
Les noms accessibles sont des signaux d’intention
Un bouton nommé « Envoyer » est utilisable. Un bouton nommé « Envoyer la demande de diagnostic » est plus clair.
Un champ avec placeholder « Nom » peut être compris visuellement. Un champ relié à un vrai <label> est plus robuste.
Une icône cliquable sans nom accessible oblige à deviner. Une icône avec un nom explicite indique son action.
Ces détails déterminent la qualité de l’action. Ils ne sont pas cosmétiques.
Les erreurs les plus coûteuses
Dans les audits, les erreurs reviennent souvent :
- boutons sans nom accessible ;
- icônes cliquables non décrites ;
- champs sans label ;
- erreurs de formulaire non reliées aux champs ;
- menus dont l’état ouvert ou fermé n’est pas exposé ;
- modales sans rôle clair ni gestion de focus ;
- éléments cachés visuellement, mais encore présents dans l’arbre ;
- éléments visibles, mais absents de l’arbre.
Ces problèmes nuisent d’abord aux humains. Mais ils fragilisent aussi les agents qui s’appuient sur cette couche.
Pourquoi ce n’est pas une API officielle
L’arbre d’accessibilité n’est pas une API commerciale dédiée aux agents. Il ne faut pas l’instrumentaliser au détriment de l’accessibilité réelle.
Mais dans la pratique, il fonctionne comme une API implicite : une représentation structurée, produite par le navigateur, qui expose ce que l’interface permet de faire.
C’est pour cela qu’un site accessible est généralement plus facile à interpréter par des agents.
Comment l’intégrer dans une méthode
Dans l’audit de navigabilité agentique, l’arbre d’accessibilité est comparé à deux autres couches : le rendu visuel et le DOM hydraté.
La question n’est pas seulement : « l’arbre existe-t-il ? »
La question est : « l’arbre raconte-t-il la même interface que celle que l’humain voit et que le DOM expose ? »
C’est cette cohérence qui rend l’action plus fiable.
Conclusion
L’Accessibility Tree redevient stratégique parce qu’il force l’interface à être explicite.
À court terme, cela améliore l’accessibilité et la qualité front-end. À moyen terme, cela améliore la capacité des agents IA à comprendre et manipuler le site. Dans les deux cas, le résultat est le même : une interface plus lisible, plus fiable et plus responsable.