En bref. WAI-ARIA fournit la sémantique de l’interface que les navigateurs exposent par leurs API d’accessibilité et que des outils tels que Playwright MCP utilisent dans des instantanés structurés.
Définition : WAI-ARIA (Accessible Rich Internet Applications) fournit des rôles, qui identifient les types de composants d’interface, et des attributs qui décrivent les éléments aux logiciels d’assistance tels que les lecteurs d’écran. L’arbre d’accessibilité (accessibility tree) est une hiérarchie d’objets accessibles par laquelle un navigateur expose les informations de l’interface, notamment le rôle d’un élément et son nom accessible, c’est-à-dire son libellé destiné aux technologies d’assistance.
Points clés
- La spécification WAI-ARIA du W3C décrit l’arbre d’accessibilité et le Document Object Model (DOM), la représentation de la page sous forme d’objets, comme des structures parallèles.
- Les recommandations du W3C sur les noms accessibles préconisent d’utiliser le texte visible pour les noms accessibles lorsqu’un texte approprié existe.
- Le guide Read Me First du W3C explique que l’ajout d’un rôle ARIA ne fournit ni comportement au clavier ni mise en forme.
- Au 17 octobre 2026, la documentation de Playwright MCP de Microsoft décrit l’automatisation du navigateur au moyen d’instantanés d’accessibilité structurés.
Comment le navigateur expose-t-il les rôles et les états ?
La recommandation WAI-ARIA décrit la transmission d’informations par les navigateurs à l’API d’accessibilité du système d’exploitation, l’interface par laquelle les logiciels d’assistance les lisent. Les objets accessibles exposent des états et des propriétés ; par exemple, aria-pressed indique l’état enfoncé d’un bouton à bascule.
La spécification recommande d’utiliser une fonctionnalité native du langage dès lors qu’elle offre une accessibilité équivalente. En HTML, cela implique de conserver les éléments natifs appropriés lors de l’ajout d’ARIA. Pour un élément personnalisé doté d’un rôle de bouton, l’auteur doit implémenter les interactions attendues : l’Authoring Practices Guide mentionne expressément la gestion du clavier en JavaScript parmi ces responsabilités.
Comment les libellés deviennent-ils des noms accessibles ?
Le guide du W3C sur les noms et les descriptions accessibles distingue le nom d’un élément de sa description. Une description ajoute des informations, telles que des consignes de saisie ; le nom indique la fonction de la commande.
Le guide fournit cet exemple :
<button type="button" aria-label="Close">X</button>
Le nom accessible est Close. Sur un bouton, aria-label remplace le contenu des descendants comme source du nom. Un libellé textuel visible est préférable lorsqu’un texte approprié peut être intégré à l’interface. Le guide documente également aria-labelledby, qui fait référence à d’autres éléments et prime sur aria-label dans le calcul du nom.
Les états transmettent des informations distinctes. Le guide Read Me First présente ce bouton natif doté d’un état ARIA :
<button aria-pressed="false">Mute</button>
Ici, Mute fournit le nom et aria-pressed="false" fournit l’état du bouton à bascule.
Comment un agent logiciel peut-il utiliser ces informations ?
La documentation du serveur Playwright MCP de Microsoft fournit un exemple concret : un serveur d’automatisation du navigateur permet aux modèles de langage d’interagir avec les pages au moyen d’instantanés d’accessibilité structurés. Son outil browser_snapshot capture l’instantané d’accessibilité de la page courante. Son outil de clic accepte comme cible une référence exacte à un élément issue d’un instantané de la page.
Dans ce fonctionnement, la sémantique exposée de l’interface sert de donnée d’entrée à l’automatisation du navigateur. Le nom accessible d’un bouton aide à décrire la commande que rencontre un agent. Il s’agit d’un usage documenté des informations d’accessibilité par un outil particulier.
Comment inspecter l’arbre d’accessibilité ?
La documentation de référence sur l’accessibilité dans Chrome DevTools de Google, mise à jour le 28 mai 2026, décrit l’inspection depuis le panneau Elements. La sélection d’un élément puis l’ouverture de l’onglet Accessibility affichent ses attributs ARIA et ses propriétés d’accessibilité calculées.
Le bouton Show accessibility tree remplace la vue DOM par l’arbre d’accessibilité de la page entière. Le développement et la sélection des nœuds révèlent leurs détails sous Computed properties. Cette vue permet d’inspecter les informations d’accessibilité résultantes en regard de l’élément sous-jacent.
Termes associés
Questions fréquentes
Chaque bouton a-t-il besoin d’un libellé ARIA explicite ?
Le guide du W3C sur les noms accessibles classe les boutons parmi les éléments dont le nom provient par défaut du contenu de leurs descendants. Vous pouvez utiliser comme nom un texte visible approprié sur le bouton.
aria-hidden affecte-t-il les descendants ?
La spécification WAI-ARIA indique que les navigateurs devraient exclure de l’arbre d’accessibilité les éléments portant aria-hidden="true" ainsi que leurs descendants. Définir aria-hidden="false" sur un descendant ne prend pas le pas sur ce réglage de l’ancêtre.
L’inspection de l’arbre suffit-elle pour tester l’accessibilité ?
Le guide Read Me First du W3C préconise des tests d’interopérabilité avec les combinaisons de navigateurs et de technologies d’assistance pertinentes pour le public concerné. Vous devez tester ces combinaisons lorsque vous implémentez les modèles du guide.
Sources
- W3C, « Accessible Rich Internet Applications (WAI-ARIA) 1.2 », 6 juin 2023
- W3C WAI, « Providing Accessible Names and Descriptions », sans date
- W3C WAI, « Read Me First », sans date
- Microsoft, « Playwright MCP », sans date
- Google, « Accessibility features reference », 28 mai 2026
Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO