Présentation de l'arborescence d'accessibilité
Imaginez que vous créez une interface utilisateur uniquement pour les utilisateurs de lecteurs d'écran. Ici, vous n'avez pas besoin de créer d'UI visuelle, mais simplement de fournir suffisamment d'informations pour que le lecteur d'écran puisse les utiliser.
Vous allez créer une sorte d'API décrivant la structure de la page, semblable à l'API DOM, mais vous pouvez vous contenter de moins d'informations et de moins de nœuds, car une grande partie de ces informations n'est utile que pour la présentation visuelle. Voici à quoi cela pourrait ressembler.
Il s'agit essentiellement de ce que le navigateur présente au lecteur d'écran. Le navigateur prend l'arborescence DOM et la modifie pour la rendre utile aux technologies d'assistance. Cette arborescence modifiée est appelée arborescence d'accessibilité.
Vous pouvez visualiser l'arborescence d'accessibilité comme une ancienne page Web des années 90 : quelques images, de nombreux liens, peut-être un champ et un bouton.
Parcourir visuellement une page comme celle-ci vous donne une expérience similaire à celle d'un utilisateur de lecteur d'écran. L'interface est là, mais elle est simple et directe, un peu comme une interface d'arborescence d'accessibilité.
L'arborescence d'accessibilité est l'élément avec lequel la plupart des technologies d'assistance interagissent. Le flux se déroule comme suit.
- Une application (le navigateur ou une autre application) expose une version sémantique de son UI à la technologie d'assistance via une API.
- La technologie d'assistance peut utiliser les informations qu'elle lit via l'API pour créer une autre présentation de l'interface utilisateur. Par exemple, un lecteur d'écran crée une interface dans laquelle l'utilisateur entend une représentation vocale de l'application.
- La technologie d'assistance peut également permettre à l'utilisateur d'interagir avec l'application d'une autre manière. Par exemple, la plupart des lecteurs d'écran fournissent des hooks permettant à l'utilisateur de simuler facilement un clic de souris ou un appui du doigt.
- La technologie d'assistance transmet l'intention de l'utilisateur (par exemple, "cliquer") à l'application via l'API d'accessibilité. L'application est ensuite chargée d'interpréter l'action de manière appropriée dans le contexte de l'UI d'origine.
Pour les navigateurs Web, il existe une étape supplémentaire dans chaque direction, car le navigateur est en fait une plate-forme pour les applications Web qui s'exécutent en son sein. Le navigateur doit donc traduire l'application Web en une arborescence d'accessibilité et s'assurer que les événements appropriés sont déclenchés en JavaScript en fonction des actions de l'utilisateur provenant de la technologie d'assistance.
Mais tout cela relève de la responsabilité du navigateur. En tant que développeurs Web, notre travail consiste simplement à être conscients de ce qui se passe et à développer des pages Web qui tirent parti de ce processus pour créer une expérience accessible pour nos utilisateurs.
Pour ce faire, nous nous assurons d'exprimer correctement la sémantique de nos pages : nous vérifions que les éléments importants de la page ont les rôles, états et propriétés accessibles appropriés, et que nous spécifions des noms accessibles et des descriptions. Le navigateur peut ensuite permettre à la technologie d'assistance d'accéder à ces informations pour créer une expérience personnalisée.
Sémantique dans le code HTML natif
Un navigateur peut transformer l'arborescence DOM en arborescence d'accessibilité, car une grande partie du DOM a une signification sémantique implicite. Autrement dit, le DOM utilise des éléments HTML natifs qui sont reconnus par les navigateurs et fonctionnent de manière prévisible sur différentes plates-formes. L'accessibilité des éléments HTML natifs tels que les liens ou les boutons est donc gérée automatiquement. Nous pouvons tirer parti de cette accessibilité intégrée en écrivant du code HTML qui exprime la sémantique des éléments de notre page.
Cependant, nous utilisons parfois des éléments qui ressemblent à des éléments natifs, mais qui n'en sont pas. Par exemple, ce "bouton" n'est pas du tout un bouton.
Il peut être construit en HTML de différentes manières. En voici une :
<div class="button-ish">Give me tacos</div>
Lorsque nous n'utilisons pas d'élément de bouton réel, le lecteur d'écran n'a aucun moyen de savoir sur quoi il a atterri. De plus, nous devrions effectuer un travail supplémentaire en ajoutant tabindex pour le rendre utilisable par les utilisateurs n'utilisant que le clavier, car, tel qu'il est codé actuellement, il ne peut être utilisé qu'avec une souris.
Nous pouvons facilement résoudre ce problème en utilisant un élément button standard au lieu d'un élément div.
L'utilisation d'un élément natif présente également l'avantage de gérer les interactions au clavier pour nous. N'oubliez pas que vous n'avez pas à perdre vos effets visuels élégants simplement parce que vous utilisez un élément natif. Vous pouvez appliquer un style aux éléments natifs pour leur donner l'apparence souhaitée, tout en conservant la sémantique et le comportement implicites.
Nous avons vu précédemment que les lecteurs d'écran annoncent le rôle, le nom, l'état et la valeur d'un élément. En utilisant l'élément sémantique approprié, le rôle, l'état et la valeur sont couverts, mais nous devons également nous assurer que le nom d'un élément est détectable.
En gros, il existe deux types de noms :
- Les libellés visibles, qui sont utilisés par tous les utilisateurs pour associer une signification à un élément.
- Texte alternatif, qui n'est utilisé que lorsqu'un libellé visuel n'est pas nécessaire.
Pour les éléments au niveau du texte, nous n'avons rien à faire, car par définition, ils contiennent du texte. Cependant, pour les éléments de saisie ou de contrôle, et les contenus visuels comme les images, nous devons nous assurer de spécifier un nom. En fait, fournir des alternatives textuelles pour tout contenu non textuel est le tout premier élément de la checklist WebAIM.
Pour ce faire, vous pouvez suivre la recommandation "Les entrées de formulaire ont des libellés textuels associés". Il existe deux façons d'associer un libellé à un élément de formulaire, comme une case à cocher. Ces deux méthodes permettent également de faire du texte du libellé une cible de clic pour la case à cocher, ce qui est également utile pour les utilisateurs de souris ou d'écrans tactiles. Pour associer un libellé à un élément, vous pouvez :
- Placer l'élément d'entrée dans un élément d'étiquette
<label>
<input type="checkbox">Receive promotional offers?
</label>ou
- Utilisez l'attribut
fordu libellé et faites référence à l'élémentid.
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
Lorsque la case à cocher est correctement étiquetée, le lecteur d'écran peut signaler que l'élément a un rôle de case à cocher, qu'il est coché et qu'il est nommé "Recevoir des offres promotionnelles ?".
