Présentation de l'arborescence d'accessibilité
Imaginez que vous créez une interface utilisateur pour les utilisateurs de lecteurs d'écran uniquement. Dans ce cas, vous n'avez pas besoin de créer d'interface utilisateur visuelle, mais vous devez simplement fournir suffisamment d'informations pour que le lecteur d'écran puisse l'utiliser.
Vous allez créer une sorte d'API décrivant la structure de la page, semblable à l'API DOM, mais vous pouvez vous en tirer avec moins d'informations et de nœuds, car une grande partie de ces informations n'est utile que pour la présentation visuelle. Cela peut ressembler à ceci.
C'est en fait ce que le navigateur présente au lecteur d'écran. Le navigateur prend l'arborescence DOM et la modifie sous une forme utile pour les technologies d'assistance. Nous appelons cette arborescence modifiée l'arborescence d'accessibilité.
Vous pourriez visualiser l'arborescence d'accessibilité comme une vieille page Web des années 90: quelques images, de nombreux liens, peut-être un champ et un bouton.
Analyser visuellement une page comme dans ce cas vous offre une expérience semblable à celle qu'obtiendrait un utilisateur de lecteur d'écran. Bien que l'interface existe, elle est simple et directe, un peu comme une arborescence d'accessibilité.
La plupart des technologies d'assistance interagissent avec l'arborescence d'accessibilité. Le flux va quelque chose comme ceci.
- Une application (le navigateur ou une autre application) expose une version sémantique de son UI à une 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 d'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 manière différente. Par exemple, la plupart des lecteurs d'écran fournissent des hooks pour permettre à un utilisateur de simuler facilement un clic de souris ou un appui avec le doigt.
- La technologie d'assistance transmet l'intent de l'utilisateur (tel que "clic") à l'application via l'API d'accessibilité. L'application est alors tenue d'interpréter l'action de manière appropriée dans le contexte de l'UI d'origine.
Pour les navigateurs Web, il y a une étape supplémentaire dans chaque direction, car le navigateur est en fait une plate-forme pour les applications Web qui s'y exécutent. 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 c'est toute la responsabilité du navigateur. Notre travail en tant que développeurs Web consiste simplement à être informés de la situation et à développer des pages Web qui exploitent ce processus afin de créer une expérience accessible pour nos utilisateurs.
Pour ce faire, nous nous assurons que la sémantique de nos pages est exprimée correctement : nous nous assurons que les éléments importants sur la page ont les rôles, les états et les propriétés accessibles appropriés, et que nous spécifions des noms et des descriptions accessibles. Le navigateur peut ensuite laisser la technologie d'assistance 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 reconnus par les navigateurs et fonctionnant de manière prévisible sur diverses plates-formes. L'accessibilité des éléments HTML natifs tels que les liens ou les boutons est ainsi gérée automatiquement. Nous pouvons profiter 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 ne le sont pas. Par exemple, ce "bouton" n'est pas du tout un bouton.
Elle peut être construite en HTML de différentes manières (voir ci-dessous).
<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. En outre, nous devrions ajouter "tabindex" pour le rendre utilisable uniquement par le clavier, car, comme il est désormais codé, il ne peut être utilisé qu'avec une souris.
Pour résoudre ce problème facilement, utilisez un élément button standard au lieu d'un élément div.
L'utilisation d'un élément natif nous permet également de prendre en charge les interactions avec le clavier. N'oubliez pas que vous n'avez pas besoin de perdre vos effets visuels époustouflants simplement parce que vous utilisez un élément natif. Vous pouvez styliser ces éléments pour qu'ils s'affichent comme vous le souhaitez, tout en conservant la sémantique et le comportement implicites.
Précédemment, nous avons remarqué que les lecteurs d'écran annonceront 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 visible.
De manière générale, il existe deux types de noms:
- Les libellés visibles, utilisés par tous les utilisateurs pour associer du sens à un élément
- Des alternatives au texte, qui ne sont utilisées que lorsqu'il n'est pas nécessaire d'utiliser un libellé visuel.
Pour les éléments au niveau du texte, aucune action n'est requise de votre part, car ils comportent par définition du contenu textuel. Toutefois, pour les éléments d'entrée ou de contrôle, et le contenu visuel comme les images, nous devons 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 sont associées à des libellés de texte". Il existe deux façons d'associer un libellé à un élément de formulaire (une case à cocher, par exemple). Ces deux méthodes entraînent également l'apparition du texte du libellé comme 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 avez le choix entre deux possibilités :
- Placer l'élément d'entrée dans un élément de libellé
<label>
<input type="checkbox">Receive promotional offers?
</label>
ou
- Utilisez l'attribut
fordu libellé et reportez-vous auidde l'élément.
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
Lorsque la case à cocher a été correctement libellée, le lecteur d'écran peut signaler que l'élément a le rôle de case à cocher, qu'il est coché et qu'il est nommé "Recevoir des offres promotionnelles ?".
