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 ce post, découvrez comment cette arborescence est créée 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 à l'aide de propriétés DOM telles que les attributs ARIA pour HTML.
Dans les outils pour les développeurs Chrome, nous fournissons un 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, avec une vue des ancêtres du nœud et de ses enfants immédiats.
Comment l'arborescence est-elle créée ?
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 du contenu du nœud. Prenons l'exemple d'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 qui se présente à 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'énoncé ci-dessus selon lequel l'arborescence d'accessibilité est une dérivée simplifiée 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 synchronisée avec l'arborescence DOM permet aux développeurs de 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 arborescence. Le document HTML suivant, qui comporte un titre, un en-tête et deux boutons, est utilisé pour afficher l'arborescence.
<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
<button>Back</button>
<button>Next</button>
</div>
L'arborescence précédente vous permettait uniquement d'explorer 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 inactifs
Pour que l'arbre soit performant même pour les sites de grande taille, il est construit de manière différée sur l'interface lors de son exploration. Lorsqu'un nœud est développé dans l'arborescence, les enfants des nœuds sont récupérés via le protocole CDP (Chrome DevTools Protocol), et l'arborescence est recréée.
En direct
La nouvelle arborescence est active et se met à jour de manière dynamique si l'arborescence d'accessibilité change dans le moteur de rendu. Il se rattache aux mêmes mécanismes que ceux qui avertiraient la technologie d'assistance des modifications apportées à l'arborescence et l'utilise pour émettre des événements dans l'interface des outils de développement avec les nœuds mis à jour. En pratique, le backend CDP écoute les mises à jour de l'arborescence, effectue le suivi des nœuds précédemment demandés et envoie des événements à l'interface des outils de développement si l'un de ces nœuds est modifié.
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 effectue et comment les outils de développement récupèrent cette arborescence via CDP. Bien que cela soit vrai, nous avons omis quelques complications dans cette description. En réalité, il existe de nombreuses façons différentes de découvrir 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.
Isolation de plusieurs cadres et de sites
Chromium ne se contente pas de placer le contenu de chaque onglet dans des processus de moteur de rendu distincts, mais il isole également les documents intersites dans différents processus de moteur de rendu. Par conséquent, nous devons nous connecter séparément à chaque document enfant hors processus via CDP et extraire son arborescence d'accessibilité. Nous assemblons ensuite ces sous-arborescences sur l'interface pour donner l'illusion d'une arborescence cohérente, même si elles résident dans des processus de moteur de rendu différents dans Chromium.
Nœuds ignorés et inintéressants
Nous masquons certains nœuds par défaut: les nœuds ignorés et les nœuds avec le rôle "générique" 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 l'arborescence. Si ce n'est pas le cas, l'arborescence d'accessibilité de la plupart des pages Web ressemblerait plutôt à ceci:
La mise en garde ici est que cela signifie essentiellement que nous devons construire une autre arborescence que celle 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 éliminons X de l'arborescence et créons à la place une arborescence où C est un enfant de A.
Sur l'interface, nous construisons l'arborescence complète en incluant les nœuds ignorés, et nous les éliminons juste avant d'afficher les nœuds. Nous procédons ainsi pour deux raisons:
- Il est beaucoup plus simple de gérer les mises à jour des nœuds à partir du backend, puisque nous disposons de la même arborescence sur les deux points de terminaison. Si, dans cet exemple, le nœud B est supprimé, nous recevrons une mise à jour pour le nœud X (étant donné que ses enfants ont changé), mais si nous avions éliminé ce nœud, nous aurons du mal à identifier les éléments à mettre à jour.
- Il garantit que tous les nœuds DOM disposent d'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. Ainsi, dans l'exemple précédent, si l'utilisateur change d'arborescence alors que le nœud DOM correspondant à X est sélectionné, nous injectons X entre les nœuds A et B et sélectionnons X dans l'arborescence. Cela permet à l'utilisateur d'inspecter le nœud d'accessibilité à la recherche de tous les nœuds DOM et de déterminer pourquoi le nœud est ignoré.
Idées pour l'avenir
Lancer la nouvelle arborescence d'accessibilité n'est qu'un point de départ. 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 excluons actuellement les nœuds qui ne sont pas intéressants. Nous pourrions proposer un moyen de désactiver ce comportement et d'afficher tous les nœuds, ou d'autres filtres tels que Afficher les nœuds de repère ou Afficher les en-têtes.
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 incriminés.
Afficher les actions d'accessibilité dans les outils de développement
L'arborescence que nous affichons actuellement est à sens unique: elle nous permet de nous faire une idée des informations qui seraient transmises à la technologie d'assistance lors de la navigation sur 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'interface utilisateur présentée. Grâce à l'API disponible pour les technologies d'assistance, nous pourrions afficher de telles actions dans les outils de développement pour permettre des actions telles que "cliquer", "faire défiler" ou modifier des valeurs sur la page.