Comprendre Accessibility Object Model (AOM)

L’accessibility tree

L’accessibility tree est construit par le navigateur à partir du DOM, le code source généré. Il met à disposition des technologies d’assistance les informations nécessaires à restituer aux utilisateurs ^[1].

Ces informations sont généralement :

• la nature de l’élément (un lien, un paragraphe, un bouton…) ;
• son nom (le nœud texte, la valeur de la propriété aria-label) ;
• son état (coché, indisponible…) ;
• et éventuellement les actions disponibles (appuyer pour activer).

Actuellement, lorsqu’un script modifie une propriété d’accessibilité (par exemple la valeur d’un attribut), cette propriété doit d’abord être rendue dans le DOM pour ensuite être prise en compte dans l’accessibility tree.

AOM propose d’intervenir au cœur même de l’accessibilité, en agissant directement sur l’accessibility tree : rationaliser le travail de développement des composants personnalisés, en évitant de devoir injecter les attributs relatifs à l’accessibilité dans le DOM, pour que l’accessibility tree correspondant puisse être généré.

Il s’agit donc de permettre une communication directe entre JavaScript et l’accessibility tree, en sautant l’étape de génération du DOM.

Les web components et le Shadow DOM

Les web components (composants personnalisés) ont été écrits pour permettre aux développeurs de créer de nouvelles balises HTML, ou étendre les fonctionnalités des balises HTML natives.

Un composant personnalisé embarque des balises HTML, du style CSS ainsi que des scripts. Sa particularité est que tout ou partie de son code peut être encapsulé dans le Shadow DOM.

Le Shadow DOM permet d’isoler des portions de code du reste du DOM généré. Le code qui y est inclus est masqué dans les inspecteurs de code ^[2].

Ce Shadow DOM, on y est déjà confronté lorsqu’on essaie de styler, par exemple les éléments select ou video pour lesquels les contrôleurs (tels que le bouton de lecture de la balise video ou la flèche du champ de sélection select) ne sont pas accessibles dans le DOM visible.

Puisque le code est masqué, les méthodes usuelles de développement front-end ne fonctionnent pas. Il n’est pas possible de modifier le Shadow DOM avec les méthodes JavaScript traditionnelles, tout comme il ne sera pas possible d’appliquer un style CSS en ciblant une class CSS disponible dans le Shadow DOM.

Ainsi, l’accessibility tree que nous avons décrit est également construit avec toutes les informations contenues dans le Shadow DOM.

C’est la raison d’être d’AOM : fournir les moyens d’accès et d’actions sur les éléments du Shadow DOM qui viennent alimenter l’accessibility tree.

Les principales fonctionnalités d’AOM

AOM apporte des nouveautés innovantes dans le paysage du développement web accessible :

• des propriétés JavaScript dédiées à la manipulation des attributs ARIA ;
• la création de références sans utilisation d’identifiants ;
• la détection des événements spécifiques aux interactions par les technologies d’assistance ;
• la création de nœuds virtuels non accessibles depuis le DOM ;
• et bien d’autres innovations encore.

Des propriétés JavaScript dédiées à la manipulation des attributs ARIA

Aujourd’hui, pour manipuler les attributs ARIA, les principales méthodes à disposition sont des méthodes génériques : getAttribute ou setAttribute.

Avec AOM, les développeurs auront à disposition des interfaces IDL (propriétés JavaScript) pour chacun des attributs ARIA. Par exemple, ariaDescribedby permettra de manipuler l’attribut ARIA aria-describedby.

el.setAttribute("aria-describedby","myID") ;


Avec AOM, ce code devient :

el.ariaDescribedby="myID" ;


À noter que les interfaces IDL ARIA font maintenant partie de la suite ARIA 1.2.

Créer des références sans identifiants

Certains attributs ARIA référencent une ou des valeurs d’identifiants (comme aria-describedby, aria-activedescendant, etc.). Il faut donc, pour chaque élément référent, définir un identifiant (id) unique.

<p id="toto">Un élément à référencer</p>

<input type="text" aria-describedby="toto" />

Mais l’utilisation d’identifiants pose plusieurs problèmes :

• la génération même de ces identifiants est une source d’erreur (duplication, mauvaise référence, etc.) ;
• les références d’identifiants sont limitées au contexte dans lequel elles sont implémentées, c’est-à-dire qu’un identifiant défini dans le DOM n’est pas accessible depuis le Shadow DOM. Il n’est donc pas possible de référencer un identifiant issu du DOM à l’intérieur d’un attribut ARIA du Shadow DOM d’un composant personnalisé.

À l’avenir, AOM autorisera la création de relations sans avoir à définir d’identifiants. Avec de nouvelles propriétés, il serait alors possible de se passer de la déclaration d’identifiants en référençant les objets eux-mêmes.

el.ariaLabelledByElements = [el2, el3];

Événements spécifiques à l’accessibilité

Lorsqu’on interagit avec un élément HTML natif, le navigateur intercepte les actions du contrôleur (les touches du clavier, les actions de la souris, la commande envoyée par la technologie d’assistance) qui initie l’action, afin de déclencher les comportements correspondants.

Par exemple : sur un champ de type range, la touche BAS va déclencher l’action de décrémenter la valeur du champ.

Certes, les technologies d’assistance n’émettent pas d’événements physiques perceptibles (appui sur la touche clavier, clic souris, etc.), par contre, elles envoient aux API d’accessibilité des événements de haut niveau : cliquer, sélectionner, annuler, augmenter, etc.

Bien que ces événements de haut niveau soient en grande partie gérés par les navigateurs pour les éléments HTML natifs (et permettent donc de déclencher les actions correspondantes sur l’interface), il n’existe aujourd’hui aucun moyen pour les développeurs de les détecter lors d’interactions avec des composants personnalisés.

Ces événements de haut niveau peuvent être déclenchés par n’importe quelle technologie d’assistance.

Par exemple, un potentiomètre physique pourrait déclencher les événements d’incrémentation et de décrémentation d’un slider personnalisé sur une application web.

Toutefois, si l’événement émis par le potentiomètre ne peut pas être intercepté par le script, il est impossible pour les développeurs de déclencher les comportements en conséquence, tels que diminuer la valeur du slider personnalisé si le potentiomètre envoie l’information de décrémentation.

Il s’agit donc de permettre aux développeurs d’accéder à ces événements de haut niveau pour pouvoir gérer les comportements en retour sur les composants personnalisés.

Quid de la détection des technologies d’assistance ?

Mais la détection des interactions par les technologies d’assistance risque de provoquer certains biais, et notamment de la discrimination.

On pourrait décider de rediriger l’utilisateur vers une autre version de l’application sans son autorisation, ou bien décider de sauvegarder ces informations et de faire du profilage en fonction de la technologie d’assistance ^[3].

Pour ces raisons, les événements spécifiques déclenchés par les technologiques d’assistance ne seraient pas dévoilés, mais ils seraient mis en correspondance avec l’événement DOM associé, avant d’être rendus disponibles en lecture pour les développeurs.

Par exemple, notre potentiomètre physique déclencherait l’événement de haut niveau increment, mais les développeurs accéderaient uniquement à l’événement DOM correspondant, c’est-à-dire à l’appui sur la touche HAUT du clavier.

Nœuds virtuels

Les nœuds accessibles virtuels permettront aux développeurs de déclarer dans l’accessibility tree des composants qui ne sont associés à aucun nœud du DOM.

Ainsi, les développeurs pourront définir des composants entièrement en JavaScript, sans avoir besoin de les faire se refléter dans le DOM, pour que ceux-ci puissent être pris en compte dans l’accessibility tree.

Avec AOM, il deviendra possible de créer un composant personnalisé, sans avoir à l’insérer dans le DOM.

Quel support pour AOM ?

AOM n’en est encore qu’à ses balbutiements. Le support est très partiel sur les trois principaux navigateurs : le groupe de travail tient à jour un document sur l’état d’implémentation d’AOM dans Chrome, Safari et Firefox.

Actuellement, seul Chrome implémente les nouveautés d’AOM en version expérimentale, depuis mai 2018. Cependant, la syntaxe n’étant pas encore totalement stabilisée, il ne s’agit là que d’un aperçu pour en comprendre le fonctionnement et l’utilité.

Pour en faire l’usage dans un contexte réel, il faudra encore patienter.

Cette page est tenue à jour en fonction de l’avancement de l’implémentation d’AOM par les principaux navigateurs concernés.

Conclusion

Avec AOM, la conception des interfaces web est complètement bouleversée. JavaScript prend de plus en plus de place dans les méthodes de création web et on ne saurait plus faire sans.

Au-delà d’une profonde modification dans les processus de développement de sites web et d’applications, c’est également le métier d’auditeur ou auditrice accessibilité qui va connaître un grand virage. Avec AOM, le code source généré ne pourra plus jamais faire office de preuve en matière d’accessibilité. En effet, une simple inspection du code ne sera plus suffisante pour évaluer la présence ni la pertinence des implémentations.

De même, les outils de tests automatiques vont devoir repenser leurs tests, puisque le code généré ne sera plus un objet de preuve. En outre, il faudra que ces outils soient capables d’exploiter l’accessibility tree.

Le RGAA même, tel qu’il est construit aujourd’hui, ne permettra pas de répondre aux nouveaux besoins d’évaluation que va imposer AOM. L’audit d’accessibilité va devoir être repensé dans ce contexte, à l’aide notamment de nouvelles méthodes d’évaluation qui utiliseraient systématiquement les inspecteurs d’interfaces et les technologies d’assistance.

Mais AOM n’en est qu’au début, cela nous laisse le temps de nous mettre à la page !