Les outils pour les développeurs Chrome lancent une arborescence complète d'accessibilité qui permet aux développeurs d'obtenir plus facilement une vue d'ensemble de l'arborescence. Dans cet article, découvrez comment créer cet arbre et comment l'utiliser dans votre travail.
Qu'est-ce que l'arborescence d'accessibilité ?
Les technologies d'assistance telles que les lecteurs d'écran utilisent l'API d'accessibilité de Chromium pour interagir avec le contenu Web. Le modèle sous-jacent de cette API est l'arborescence d'accessibilité: une arborescence d'objets d'accessibilité que les technologies d'assistance peuvent interroger pour rechercher des attributs et des propriétés, et sur lesquels effectuer des actions. Les développeurs Web façonnent et manipulent l'arborescence d'accessibilité principalement via des propriétés DOM telles que les attributs ARIA pour le HTML.
Dans Chrome DevTools, nous fournissons le volet d'accessibilité pour aider les développeurs à comprendre comment leur contenu est exposé aux technologies d'assistance. Concrètement, lorsqu'un nœud est sélectionné dans l'arborescence DOM, les propriétés du nœud d'accessibilité correspondant s'affichent dans le volet, ainsi qu'une vue des ancêtres du nœud et de ses enfants immédiats.
Comment l'arbre est-il créé ?
Avant de voir à quoi ressemble cette nouvelle arborescence complète des outils de développement, examinons brièvement l'arborescence d'accessibilité, de façon plus concrète. L'arborescence d'accessibilité est un dérivé de l'arborescence DOM. Sa structure est à peu près identique, mais elle est simplifiée pour supprimer les nœuds sans contenu sémantique, comme un élément <div> uniquement utilisé pour le style. Chaque nœud de l'arborescence possède un rôle tel que Button ou Heading, et souvent un nom qui peut provenir d'attributs ARIA ou être dérivé du contenu du nœud. Si nous examinons un document HTML :
<html>
<head>
<title>How old are you?</title>
</head>
<body>
<label for="age">Age</label>
<input id="age" type="number" name="age" value="42">
<div>
<button>Back</button>
<button>Next</button>
</div>
</body>
</html>
Le moteur de rendu de Chromium, appelé Blink, génère une arborescence d'accessibilité interne à peu près comme suit.
role='rootWebArea' focusable name='How old are you?'
role='genericContainer' ignored
role='genericContainer' ignored
role='labelText'
role='staticText' name='Age'
role='spinButton' editable focusable name='Age' value='42'
role='genericContainer' editable
role='staticText' editable name='42'
role='genericContainer'
role='button' focusable name='Back'
role='staticText' name='Back'
role='button' focusable name='Next'
role='staticText' name='Next'
Notez que cette représentation contient plusieurs nœuds superflus avec le rôle genericContainer, ce qui semble contredire l'affirmation ci-dessus selon laquelle l'arborescence d'accessibilité est un dérivé simplifié de l'arborescence DOM. Pourtant, la plupart de ces nœuds ne se produisent que dans l'arborescence interne et ne seraient pas exposés aux technologies d'assistance. Étant donné que les outils de développement collectent leurs informations d'accessibilité directement à partir du processus du moteur de rendu, il s'agit de la représentation sous forme d'arborescence qu'ils gèrent.
Arborescence d'accessibilité complète dans les outils de développement
La nouvelle arborescence d'accessibilité complète est synchronisée avec l'arborescence DOM afin que les développeurs puissent passer d'une arborescence à l'autre. Nous espérons que cette nouvelle arborescence sera plus facile à explorer, plus utile et plus facile à utiliser.
Maintenant que vous savez comment fonctionne l'arborescence d'accessibilité, vous pouvez utiliser les outils de développement pour voir à quoi ressemble la nouvelle vue arborescente. Le document HTML suivant, qui comporte un titre, un en-tête et deux boutons, permet d'afficher l'arborescence.
<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
<button>Back</button>
<button>Next</button>
</div>
L'ancienne vue arborescente ne vous permettait d'explorer qu'un seul nœud et ses ancêtres.
Désormais, lorsque vous activez la nouvelle arborescence, celle-ci remplace l'arborescence DOM et vous permet d'afficher l'arborescence d'accessibilité complète de la page:
Construction d'arbres paresseux
Pour que l'arborescence soit performante même pour les sites plus volumineux, elle est construite de manière paresseuse côté client à mesure qu'elle est explorée. Une fois qu'un nœud est développé dans l'arborescence, ses enfants sont récupérés via le protocole Chrome DevTools (CDP), puis l'arborescence est recréée.
En direct
La nouvelle vue arborescente est active et se met à jour de manière dynamique si l'arborescence d'accessibilité change dans le moteur de rendu. Il s'appuie sur les mêmes mécanismes qui informent la technologie d'assistance des modifications apportées à l'arborescence, et les utilise pour émettre des événements dans l'interface frontale de DevTools avec des nœuds mis à jour. En pratique, le backend CDP écoute les mises à jour de l'arborescence, suit les nœuds qui ont déjà été demandés et envoie des événements au frontend DevTools si l'un de ces nœuds change.
L'histoire de nombreux arbres
Dans la description de l'arborescence d'accessibilité, vous avez appris comment Blink construit une arborescence d'accessibilité pour le DOM qu'il affiche, et comment DevTools extrait cette arborescence via CDP. C'est vrai, mais nous avons omis certaines complications dans cette description. En réalité, il existe de nombreuses façons différentes d'utiliser l'arborescence d'accessibilité dans Chromium. Lors de la conception de la nouvelle arborescence des outils de développement, nous avons choisi la partie des fonctionnalités d'accessibilité internes de Chromium que nous voulions mettre en avant.
Plates-formes
Chaque plate-forme possède une API d'accessibilité différente et, bien que la forme de l'arbre soit la même sur toutes les plates-formes, l'API d'interaction avec l'arborescence est différente et les noms des attributs peuvent différer. Les outils de développement affichent l'arborescence interne de Chromium, où les rôles et les attributs tendent à correspondre à ceux définis dans la spécification ARIA.
Plusieurs cadres et isolation de sites
Comme Chromium place non seulement le contenu de chaque onglet dans différents processus de rendu, mais aussi isole les documents intersites dans différents processus de rendu, nous devons nous connecter séparément à chaque document enfant hors processus via CDP et extraire son arbre d'accessibilité. Nous assemblons ensuite ces sous-arbres sur le frontend pour donner l'illusion d'un arbre cohérent, bien qu'ils résident dans différents processus de rendu dans Chromium.
Nœuds ignorés et sans intérêt
Par défaut, nous cachons certains nœuds : les nœuds ignorés et les nœuds avec le rôle "générique" et sans nom. Ces nœuds n'ont aucune signification sémantique et, dans le cas de nœuds ignorés, ne sont pas exposés aux technologies d'assistance. Nous masquons ces nœuds pour éviter d'encombrer la vue arborescente. Si ce n'est pas le cas, l'arborescence d'accessibilité de la plupart des pages Web ressemblerait plutôt à ceci:
L'inconvénient est que cela signifie essentiellement que nous devons construire un autre arbre que celui qui est disponible sur le backend. Supposons, par exemple, que nous ayons les nœuds A, B, C et X, où A a l'enfant X et B, et X a l'enfant C. Si X est un nœud ignoré, nous supprimons X de l'arborescence et créons à la place une arborescence dans laquelle C est un enfant d'A.
Au niveau du frontend, nous construisons l'arbre complet, y compris les nœuds ignorés, et ne les élaguons qu'au moment de les afficher. Nous le faisons pour deux raisons :
- Cela permet de gérer beaucoup plus facilement les mises à jour de nœuds depuis le backend, car nous avons la même structure d'arborescence sur les deux points de terminaison. Par exemple, si le nœud B est supprimé dans l'exemple, nous recevons une mise à jour pour le nœud X (car ses enfants ont changé), mais si nous avions élagué ce nœud, nous aurions du mal à déterminer ce qu'il fallait mettre à jour.
- Il garantit que tous les nœuds DOM ont un nœud d'accessibilité correspondant. Lorsque l'arborescence est activée, nous sélectionnons le nœud correspondant au nœud actuellement sélectionné dans l'arborescence DOM. Pour l'exemple précédent, si l'utilisateur active l'arborescence alors que le nœud DOM correspondant à X est sélectionné, nous injectons X entre les nœuds A et B, puis nous sélectionnons X dans l'arborescence. Cela permet à l'utilisateur d'inspecter le nœud d'accessibilité pour tous les nœuds DOM et de déterminer pourquoi le nœud est ignoré.
Idées pour l'avenir
Le lancement de la nouvelle arborescence d'accessibilité n'est que le début. Nous avons quelques idées pour de futurs projets que nous pourrions exploiter à partir de cette nouvelle vue, mais nous aimerions également connaître votre avis.
Autres filtres
Comme expliqué ci-dessus, nous filtrons actuellement les nœuds jugés sans intérêt. Nous pourrions proposer un moyen de désactiver ce comportement et d'afficher tous les nœuds, ou proposer d'autres options de filtrage telles que Afficher les nœuds repères ou Afficher les titres.
Mettre en évidence les problèmes d'accessibilité
Nous pourrions intégrer une analyse des "bonnes pratiques d'accessibilité" à l'arborescence et mettre en évidence les problèmes d'accessibilité directement sur les nœuds concernés.
Afficher les actions d'accessibilité dans DevTools
L'arborescence que nous affichons actuellement est purement à sens unique : elle nous permet d'avoir une idée des informations qui seraient transmises à la technologie d'assistance lorsque vous consultez une page Web spécifique. Les actions d'accessibilité représentent la communication dans l'autre sens : elles permettent à la technologie d'assistance d'agir sur l'UI présentée. Nous pourrions afficher ces actions dans DevTools pour autoriser des actions telles que "cliquer", faire défiler la page ou modifier des valeurs sur la page à l'aide de l'API disponible pour les technologies d'assistance.