ARIA et HTML

La plupart des développeurs connaissent bien le langage de balisage standard de notre Web moderne, le langage de balisage hypertexte (HTML). Cependant, vous connaissez peut-être moins les applications Internet riches accessibles (ARIA) (anciennement WAI-ARIA): qu'est-ce que c'est, comment elles sont utilisées, et quand (et quand ne pas) les utiliser.

HTML et ARIA jouent un rôle important pour rendre les produits numériques accessibles, en particulier lorsqu'il s'agit de technologies d'assistance telles que les lecteurs d'écran. Tous deux sont utilisés pour convertir du contenu dans un autre format, tel que le braille ou la synthèse vocale.

Examinons brièvement les fonctionnalités ARIA. Nous allons vous expliquer en quoi elles sont importantes, et quand et comment les utiliser au mieux.

Présentation d'ARIA

ARIA a été développé pour la première fois en 2008 par le groupe Web Accessibility Initiative (WAI), un sous-ensemble du World Wide Web Consortium (W3C), qui régit et réglemente Internet.

ARIA n'est pas un véritable langage de programmation, mais un ensemble d'attributs que vous pouvez ajouter aux éléments HTML pour améliorer leur accessibilité. Ces attributs communiquent le rôle, l'état et la propriété aux technologies d'assistance via les API d'accessibilité disponibles dans les navigateurs modernes. Cette communication s'effectue via l'arborescence d'accessibilité.

"WAI-ARIA, la suite d'applications Internet enrichies accessible, permet de rendre les contenus et les applications Web plus accessibles aux personnes handicapées. Il est particulièrement utile pour le contenu dynamique et les commandes d'interface utilisateur avancées développées avec HTML, JavaScript et d'autres technologies associées."

Groupe WAI

Arborescence d'accessibilité

ARIA modifie un code incorrect ou incomplet afin d'améliorer l'expérience des utilisateurs de TA en modifiant, en exposant et en augmentant des parties de l'arborescence d'accessibilité.

L'arborescence d'accessibilité est créée par le navigateur et basée sur l'arborescence DOM (Document Object Model) standard. Comme l'arborescence DOM, l'arborescence d'accessibilité contient des objets représentant tous les éléments de balisage, attributs et nœuds de texte. L'arborescence d'accessibilité est également utilisée par les API d'accessibilité spécifiques à la plate-forme pour fournir une représentation compréhensible par les technologies d'assistance.

ARIA seule ne modifie pas la fonctionnalité ni l'apparence visuelle d'un élément. Cela signifie que seuls les utilisateurs AT remarqueront des différences entre un produit numérique avec ARIA et un produit sans. Cela signifie également que les développeurs sont seuls responsables de la modification du code et des modifications de style afin de rendre un élément aussi accessible que possible.

Les trois principales fonctionnalités des ARIA sont les rôles, les propriétés et les états/valeurs.

Les rôles définissent ce qu'un élément est ou fait sur une page ou dans une application.

<div role="button">Self-destruct</div>

Les propriétés expriment les caractéristiques ou les relations d'un objet.

<div role="button" aria-describedby="more-info">Self-destruct</div>

<div id="more-info">This page will self-destruct in 10 seconds.</div>

Les états/valeurs définissent les conditions actuelles ou les valeurs de données associées à l'élément.

<div role="button" aria-describedby="more-info" aria-pressed="false">
  Self-destruct
</div>

<div id="more-info">
  This page will self-destruct in 10 seconds.
</div>

Bien que les trois éléments ARIA puissent être utilisés dans une seule ligne de code, ce n'est pas obligatoire. Ajoutez plutôt des rôles, des propriétés et des états/valeurs ARIA jusqu'à atteindre votre objectif final d'accessibilité. En intégrant correctement les flux ARIA dans votre code base, vous vous assurez que les utilisateurs d'AT ont toutes les informations dont ils ont besoin pour utiliser votre site Web, votre application ou tout autre produit numérique avec succès et de manière équitable.

Récemment, les outils pour les développeurs Chrome ont créé un moyen de voir l'arborescence complète d'accessibilité. Les développeurs peuvent ainsi mieux comprendre l'impact de leur code sur l'accessibilité.

Quand utiliser ARIA ?

En 2014, le W3C a officiellement publié la recommandation HTML5. Des changements importants ont également été apportés, y compris l'ajout d'éléments de repère tels que <main>, <header>, <footer>, <aside> et <nav>, ainsi que d'attributs comme hidden et required. Grâce à ces nouveaux éléments et attributs HTML5, et à une meilleure compatibilité des navigateurs, certaines parties des flux ARIA sont désormais moins essentielles.

Lorsque le navigateur accepte une balise HTML avec un rôle implicite avec un équivalent ARIA, il n'est généralement pas nécessaire d'ajouter ARIA à l'élément. Cependant, ARIA inclut toujours de nombreux rôles, états et propriétés qui ne sont disponibles dans aucune version du langage HTML. Ces attributs restent utiles pour le moment.

Cela nous amène à la question ultime: quand utiliser les flux ARIA ? Heureusement, le groupe WAI a développé les cinq règles ARIA pour vous aider à décider comment rendre les éléments accessibles.

Règle 1: Ne pas utiliser les modes ARIA

Oui, tu as bien lu. L'ajout d'ARIA à un élément ne le rend pas intrinsèquement plus accessible. Le rapport annuel sur l'accessibilité de WebAIM Million a révélé que les pages d'accueil présentant des informations ARIA enregistraient en moyenne 70% d'erreurs détectées en plus par rapport à celles sans ARIA, principalement en raison d'une implémentation incorrecte des attributs ARIA.

Il existe des exceptions à cette règle. ARIA est obligatoire lorsqu'un élément HTML n'est pas compatible avec l'accessibilité. Cela peut être dû au fait que la conception n'autorise pas un élément HTML spécifique ou que la fonctionnalité ou le comportement souhaité ne sont pas disponibles en HTML. Cependant, ces situations devraient être rares.

<a role="button">Submit</a>

<button>Submit</button>

En cas de doute, utilisez des éléments HTML sémantiques.

Règle 2: n'ajoutez pas (inutile) de texte ARIA au code HTML

Dans la plupart des cas, les éléments HTML fonctionnent parfaitement par défaut et n'ont pas besoin d'être ajoutés à des flux ARIA supplémentaires. En réalité, les développeurs qui utilisent les flux ARIA doivent souvent ajouter du code supplémentaire pour rendre les éléments fonctionnels dans le cas d'éléments interactifs.

<h2 role="tab">Heading tab</h2>

<div role="tab"><h2>Heading tab</h2></div>

Utilisez les éléments HTML comme prévu afin de gagner en efficacité et d'améliorer les performances de votre code.

Règle 3: permettre la navigation au clavier

Toutes les commandes ARIA interactives (non désactivées) doivent être accessibles avec le clavier. Vous pouvez ajouter tabindex= "0" à tout élément qui nécessite un ciblage qui ne reçoit normalement pas de sélection au clavier. Dans la mesure du possible, évitez d'utiliser des index de tabulation avec des entiers positifs pour éviter tout problème potentiel d'ordre de sélection du clavier.

<span role="button" tabindex="1">Submit</span>

<span role="button" tabindex="0">Submit</span>

Règle 4: Ne pas masquer les éléments sélectionnables

N'ajoutez pas role= "presentation" ni aria-hidden= "true" aux éléments qui doivent être ciblés, y compris les éléments avec un tabindex= "0". Lorsque vous ajoutez ces rôles/états aux éléments, vous envoyez un message à l'AT indiquant que ces éléments ne sont pas importants et les ignorer. Cela peut prêter à confusion ou perturber les utilisateurs qui tentent d'interagir avec un élément.

<div aria-hidden="true"><button>Submit</button></div>

<div><button>Submit</button></div>

Règle 5: Utiliser des noms accessibles pour les éléments interactifs

L'objectif d'un élément interactif doit être transmis à l'utilisateur avant qu'il ne sache comment interagir avec lui. Assurez-vous que tous les éléments ont un nom accessible pour les utilisateurs d'appareils TA.

Les noms accessibles peuvent être le contenu entouré par un élément (dans le cas d'une <a>), un texte alternatif ou un libellé.

Pour chacun des exemples de code suivants, le nom accessible est "Bottes en cuir rouges".

<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>

<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>

<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>

Il existe de nombreuses façons de vérifier le nom accessible d'un élément, y compris en inspectant l'arborescence d'accessibilité à l'aide des Outils pour les développeurs Chrome ou en la testant avec un lecteur d'écran.

ARIA en HTML

Bien qu'il soit recommandé d'utiliser des éléments HTML seuls, des éléments ARIA peuvent être ajoutés dans certaines situations. Par exemple, vous pouvez associer ARIA à HTML dans des modèles qui nécessitent un niveau de compatibilité plus élevé en raison de contraintes environnementales ou comme méthode de remplacement pour les éléments HTML qui ne sont pas entièrement compatibles avec tous les navigateurs.

Il existe bien sûr des recommandations pour intégrer les ARIA dans HTML. Plus important encore: ne remplacez pas les rôles HTML par défaut, réduisez la redondance et soyez conscient des effets secondaires inattendus.

Examinons quelques exemples.

<a role="heading">Read more</a>

<a aria-label="Read more about some awesome article title">Read More</a>

<ul role="list">...</ul>

<ul>...</ul>

<details>
  <summary role="button">more information</summary>
  ...
</details>

<details>
  <summary>more information</summary>
  ...
</details>

Complexité des flux ARIA

Les flux ARIA étant complexes, vous devez toujours les utiliser avec précaution. Bien que les exemples de code de cette leçon soient assez simples, la création de modèles personnalisés accessibles peut rapidement devenir compliquée.

Vous devez prêter attention à de nombreux éléments, y compris, mais sans s'y limiter, les interactions avec le clavier, les interfaces tactiles, la compatibilité avec les systèmes de technologie/navigateur, les besoins en traduction, les contraintes environnementales, l'ancien code et les préférences utilisateur. Quelques connaissances en codage peuvent être préjudiciables, ou tout simplement agaçants, si elles sont mal utilisées. N'oubliez pas de simplifier votre code.

Ces avertissements mis à part, l'accessibilité numérique n'est pas une situation "tout ou rien", c'est un spectre qui autorise des zones grises comme celle-ci. Plusieurs solutions de codage peuvent être considérées comme "correctes", selon la situation. Ce qui est important, c'est que vous continuiez à apprendre, à tester et à essayer de rendre notre monde numérique plus ouvert à tous.

Testez vos connaissances

Tester vos connaissances sur ARIA et le langage HTML