Concepts

Arbre d'accessibilité

Voir aussi : a11y tree, accessibility object model, AOM

La structure de données interne que les navigateurs et systèmes d'exploitation construisent à partir du DOM, associant chaque élément à un rôle, un nom, un état et des relations — les données que les lecteurs d'écran et autres technologies d'assistance parcourent réellement.

L’arbre d’accessibilité est la structure de données au niveau du système d’exploitation que les lecteurs d’écran et autres technologies d’assistance consomment réellement. Lorsqu’une page est ouverte dans un navigateur, celui-ci construit deux arborescences : l’arbre DOM (la hiérarchie HTML standard) et l’arbre d’accessibilité, une structure parallèle dérivée du DOM mais contenant des métadonnées d’accessibilité.

Comprendre l’arbre d’accessibilité explique environ 80 % des comportements autrement déroutants d’ARIA, des lecteurs d’écran et des sessions de débogage du type « pourquoi est-ce que ça n’annonce pas ? ».

Ce qu’il contient

Chaque nœud de l’arbre d’accessibilité possède :

  • Rôle — ce qu’est l’élément : button, link, heading, navigation, dialog. Issu du type d’élément HTML ou d’un role="..." ARIA explicite.
  • Nom — comment l’élément s’appelle. Issu du texte d’étiquette, de l’attribut alt, de aria-label, d’aria-labelledby ou du contenu texte calculé.
  • Description — contexte supplémentaire. Issu d’aria-describedby ou des attributs title.
  • État — état actuel : pressed, expanded, checked, busy. Issu d’attributs HTML (disabled, required) ou d’ARIA (aria-pressed, aria-expanded).
  • Propriétés — relations et métadonnées : aria-controls, aria-owns, aria-haspopup.

Les lecteurs d’écran parcourent cet arbre et annoncent chaque nœud en fonction de ces champs. La navigation au clavier (Tab et touches fléchées) s’effectue dans l’arbre, pas dans le DOM.

Pourquoi le contenu purement visuel disparaît

Un <div onclick="..."> stylisé pour ressembler à un bouton n’a aucun rôle dans l’arbre d’accessibilité — le navigateur voit un <div> générique et l’enregistre comme role="generic" (effectivement invisible pour les technologies d’assistance). Le gestionnaire onclick ne s’insère pas dans l’arbre d’accessibilité car celui-ci ne reflète que ce que le navigateur déduit de l’élément d’après son rôle HTML.

C’est pourquoi le HTML sémantique est important au niveau le plus fondamental : non pas pour des raisons de style ou de convention, mais parce que les éléments HTML sémantiques peuplent automatiquement l’arbre d’accessibilité avec les bons rôles. Le balisage non sémantique crée une arborescence de <div> que les lecteurs d’écran ne peuvent pas interpréter.

Le rôle d’ARIA dans l’arbre

ARIA existe précisément pour peupler l’arbre d’accessibilité dans les cas où le HTML natif ne dispose pas d’un élément correspondant. role="combobox" indique au navigateur d’insérer un nœud combobox dans l’arbre pour un élément qui serait autrement apparu comme générique. aria-expanded="true" définit une propriété d’état sur ce nœud.

ARIA ne modifie PAS le DOM. Il modifie ce que le navigateur écrit dans l’arbre d’accessibilité.

Comment l’inspecter

Les outils de développement des navigateurs exposent désormais directement l’arbre d’accessibilité :

  • Chrome / Edge DevTools — panneau Elements → onglet Accessibility (colonne de droite) affiche les propriétés d’accessibilité calculées pour le nœud sélectionné. La bascule « Full-page accessibility tree » (option Chrome dans certaines versions) affiche l’arbre dans une barre latérale.
  • Firefox DevTools — panneau Accessibility (icône dans la barre d’outils) affiche une vue de l’arbre d’accessibilité dédiée, similaire à la vue Elements mais rendue en termes d’arbre d’accessibilité.
  • Safari Web Inspector — onglet Audit / Accessibility offre une inspection comparable.

Lorsque l’arbre d’accessibilité est visible, il est possible de répondre empiriquement à la question « pourquoi est-ce que ça n’annonce pas ? ». La réponse est presque toujours : le nœud dans l’arbre d’accessibilité a un rôle différent de celui attendu, ou son nom est vide, ou son état est incorrect.

Pourquoi « arbre d’accessibilité » est un meilleur modèle mental qu’« ARIA »

Les développeurs qui apprennent ARIA sans comprendre l’arbre d’accessibilité finissent par ajouter des attributs ARIA au hasard en espérant que les lecteurs d’écran les détecteront. Ceux qui comprennent l’arbre d’accessibilité savent que le rôle d’ARIA est d’écrire des champs spécifiques dans des nœuds d’arbre spécifiques, et que l’inspection directe de l’arbre est plus rapide que les suppositions.