Les outils pour les développeurs Chrome lancent une arborescence d'accessibilité complète, qui permet aux développeurs d'obtenir plus facilement une vue d'ensemble de l'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é: arborescence d'objets d'accessibilité sur lesquels les technologies d'assistance peuvent effectuer des requêtes pour obtenir des attributs et des propriétés, et sur lesquels elles peuvent 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 vue arborescente complète dans les outils de développement, examinons brièvement ce qu'est l'arborescence d'accessibilité en termes plus concrets. L'arborescence d'accessibilité est un dérivé de l'arborescence DOM. Sa structure est à peu près la même, mais simplifiée pour supprimer les nœuds sans contenu sémantique, comme un élément <div> utilisé uniquement 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, nommé Blink, dérive un arbre 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. Toutefois, la plupart de ces nœuds ne se trouvent que dans l'arborescence interne et ne sont pas exposés aux technologies d'assistance. Étant donné que DevTools collecte ses informations d'accessibilité directement à partir du processus de rendu, c'est la représentation arborescente que DevTools gère.
Arborescence d'accessibilité complète dans DevTools
L'arborescence d'accessibilité complète, synchronisée avec l'arborescence DOM, permet aux développeurs de passer de l'une à l'autre. Nous espérons que ce nouvel arbre 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, avec 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, elle remplace la vue de l'arborescence DOM et vous permet de voir 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 vue arborescente pour DevTools, nous avons fait des choix concernant la partie des éléments internes d'accessibilité de Chromium que nous souhaitions afficher.
Plates-formes
Chaque plate-forme dispose d'une API d'accessibilité différente. Bien que la forme de l'arborescence soit la même sur toutes les plates-formes, l'API permettant d'interagir avec l'arborescence est différente, et les noms des attributs peuvent varier. DevTools affiche l'arborescence interne de Chromium, où les rôles et les attributs ont tendance à 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 des 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. Sinon, l'arborescence de l'accessibilité de la plupart des pages Web ressemblerait à ceci:
L'inconvénient est que cela signifie essentiellement que nous devons construire un autre arbre que celui qui est disponible sur le backend. Imaginons, par exemple, que nous ayons les nœuds A, B, C et X, où A a X et B comme enfants, et X C comme enfant. 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 du nouvel arbre d'accessibilité n'est qu'un premier pas. Nous avons quelques idées de projets futurs que nous pourrions développer à partir de la nouvelle vue, mais nous sommes également impatients de recevoir vos commentaires.
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.