La plupart des développeurs connaissent le langage de balisage standard du Web moderne, HyperText Markup Language (HTML). Toutefois, vous connaissez peut-être moins les applications Internet riches et accessibles (ARIA) (anciennement appelées WAI-ARIA) : ce qu'elles sont, comment elles sont utilisées, et quand (et quand ne pas) les utiliser.
HTML et ARIA jouent un rôle important dans l'accessibilité des produits numériques, en particulier en ce qui concerne les technologies d'assistance (TA) telles que les lecteurs d'écran. Les deux sont utilisés pour convertir du contenu dans un autre format, comme le braille ou la synthèse vocale.
Passez en revue l'historique d'ARIA, son importance, et quand et comment l'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 à l'aide des API d'accessibilité disponibles dans les navigateurs modernes. Cette communication s'effectue via l'arborescence d'accessibilité.
"WAI-ARIA, la suite d'applications Internet riches et accessibles, définit une manière de rendre les contenus Web 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 les technologies associées."
Le groupe WAI
Arborescence d'accessibilité
ARIA modifie le code incorrect ou incomplet pour améliorer l'expérience des utilisateurs de technologies d'assistance 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, les attributs et les 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 que les technologies d'assistance peuvent comprendre.
ARIA ne modifie pas en soi la fonctionnalité ni l'apparence visuelle d'un élément. Cela signifie que seuls les utilisateurs de technologies d'assistance remarqueront des différences entre un produit numérique avec ARIA et un produit numérique sans ARIA. Cela signifie également que les développeurs sont seuls responsables des modifications de code et de style appropriées pour rendre un élément aussi accessible que possible.
ARIA comporte trois fonctionnalités principales : les rôles, les propriétés, et les états/valeurs.
Les rôles définissent ce qu'est un élément ou ce qu'il fait sur la page ou dans l'application.
<div role="button">Self-destruct</div>
Les propriétés expriment des caractéristiques ou des relations avec 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 et les valeurs définissent les conditions ou les valeurs de données actuelles 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 d'ARIA puissent être utilisés sur une même ligne de code, ce n'est pas obligatoire. Au lieu de cela, superposez les rôles, propriétés, états ou valeurs ARIA jusqu'à ce que vous ayez atteint votre objectif d'accessibilité final. En intégrant correctement ARIA dans votre codebase, vous vous assurez que les utilisateurs de technologies d'assistance disposent de toutes les informations dont ils ont besoin pour utiliser votre site Web, votre application ou tout autre produit numérique de manière efficace et équitable.
Récemment, les outils pour les développeurs Chrome ont créé un moyen de voir l'arborescence complète de l'accessibilité, ce qui permet aux développeurs de mieux comprendre l'impact de leur code sur l'accessibilité.
Quand utiliser ARIA ?
En 2014, le W3C a officiellement publié la recommandation HTML5. Cette version a apporté des changements majeurs, y compris l'ajout d'éléments de repère tels que <main>, <header>, <footer>, <aside>, <nav> et d'attributs tels que hidden et required. Grâce à ces nouveaux éléments et attributs HTML5, ainsi qu'à la compatibilité accrue des navigateurs, certaines parties d'ARIA sont désormais moins critiques.
Lorsque le navigateur est compatible avec une balise HTML avec un rôle implicite ayant un équivalent ARIA, il n'est généralement pas nécessaire d'ajouter ARIA à l'élément. Toutefois, ARIA inclut toujours de nombreux rôles, états et propriétés qui ne sont disponibles dans aucune version de HTML. Ces attributs restent utiles pour le moment.
Nous arrivons à la question ultime : quand faut-il utiliser ARIA ? Heureusement, le groupe WAI a développé les cinq règles d'ARIA pour vous aider à décider comment rendre les éléments accessibles.
Règle 1 : N'utilisez pas ARIA
Oui, vous avez bien lu. L'ajout d'ARIA à un élément ne le rend pas intrinsèquement plus accessible. Le rapport annuel sur l'accessibilité WebAIM Million a révélé que les pages d'accueil avec ARIA présentaient en moyenne 70 % plus d'erreurs détectées que celles sans ARIA, principalement en raison de l'implémentation incorrecte des attributs ARIA.
Il existe des exceptions à cette règle. ARIA est requis lorsqu'un élément HTML n'est pas compatible avec l'accessibilité. Cela peut être dû au fait que la conception ne permet pas d'utiliser un élément HTML spécifique, ou que la fonctionnalité ou le comportement souhaités ne sont pas disponibles en HTML. Cependant, ces situations devraient être rares.
À éviter : attribuer un rôle.
<a role="button">Submit</a>
À faire : utilisez l'élément sémantique.
<button>Submit</button>
En cas de doute, utilisez des éléments HTML sémantiques.
Règle 2 : N'ajoutez pas d'ARIA (inutile) au code HTML
Dans la plupart des cas, les éléments HTML fonctionnent bien tels quels et n'ont pas besoin d'attributs ARIA supplémentaires. En fait, les développeurs qui utilisent ARIA doivent souvent ajouter du code supplémentaire pour rendre les éléments fonctionnels dans le cas d'éléments interactifs.
Ne pas : attribuer un rôle trompeur.
<h2 role="tab">Heading tab</h2>
À faire : attribuez les rôles correctement.
<div role="tab"><h2>Heading tab</h2></div>
Réduisez votre charge de travail et améliorez les performances de votre code en utilisant les éléments HTML comme prévu.
Règle 3 : Assurez-vous que la navigation au clavier est toujours possible
Tous les contrôles ARIA interactifs (non désactivés) doivent être accessibles au clavier. Vous pouvez ajouter tabindex= "0" à n'importe quel élément qui a besoin d'un focus et qui ne le reçoit pas normalement. Dans la mesure du possible, évitez d'utiliser des index de tabulation avec des entiers positifs pour éviter d'éventuels problèmes d'ordre de mise au point au clavier.
À ne pas faire : ajouter un tabindex.
<span role="button" tabindex="1">Submit</span>
Faites-le : définissez l'index de tabulation sur "0".
<span role="button" tabindex="0">Submit</span>
Bien sûr, si vous le pouvez, utilisez un véritable élément <button> dans ce cas.
Règle 4 : Ne masquez pas les éléments sélectionnables
N'ajoutez pas role= "presentation" ni aria-hidden= "true" aux éléments qui doivent être sélectionnés, y compris ceux avec un tabindex= "0". Lorsque vous ajoutez ces rôles et états à des éléments, un message est envoyé à la technologie d'assistance pour indiquer que ces éléments ne sont pas importants et qu'il faut les ignorer. Cela peut entraîner une certaine confusion ou perturber les utilisateurs qui tentent d'interagir avec un élément.
Non : masquer les éléments pouvant être sélectionnés
<div aria-hidden="true"> <button>Submit</button> </div>
À faire : exposer les éléments sélectionnables
<div> <button>Submit</button> </div>
Règle 5 : Utilisez des noms accessibles pour les éléments interactifs
L'objectif d'un élément interactif doit être communiqué à l'utilisateur avant qu'il sache comment interagir avec lui. Assurez-vous que tous les éléments disposent d'un nom accessible pour les personnes utilisant des appareils d'assistance.
Les noms accessibles peuvent être le contenu entouré d'un élément (dans le cas d'un <a>), un texte alternatif ou un libellé.
Pour chacun des exemples de code suivants, le nom accessible est "Bottes en cuir rouge".
<!-- 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 le testant avec un lecteur d'écran.
ARIA dans HTML
Bien qu'il soit préférable d'utiliser les é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 d'assistance AT plus élevé en raison de contraintes environnementales ou comme méthode de secours pour les éléments HTML qui ne sont pas entièrement pris en charge par tous les navigateurs.
Bien sûr, il existe des recommandations pour implémenter ARIA dans HTML. Plus important encore : ne remplacez pas les rôles HTML par défaut, réduisez la redondance et soyez attentif aux effets secondaires indésirables.
Voici quelques exemples.
À éviter : attribuer le mauvais rôle.
<a role="heading">Read more</a>
À faire : utilisez le bon rôle et une description de lien supplémentaire.
<a aria-label="Read more about some awesome article title">Read More</a>
À éviter : ajouter un rôle redondant.
<ul role="list">...</ul>
À faire : réduire la redondance.
<ul>...</ul>
Ne pas : passer à côté d'effets secondaires potentiels.
<details> <summary role="button">more information</summary> ... </details>
À faire : gérez les effets secondaires.
<details> <summary>more information</summary> ... </details>
Complexités d'ARIA
ARIA est complexe. Vous devez donc toujours l'utiliser avec précaution. Bien que les exemples de code de cette leçon soient assez simples, la création de motifs personnalisés accessibles peut rapidement devenir complexe.
Vous devez tenir compte de nombreux éléments, y compris, mais sans s'y limiter, les interactions au clavier, les interfaces tactiles, la compatibilité avec les technologies d'assistance et les navigateurs, les besoins en traduction, les contraintes environnementales, le code hérité et les préférences des utilisateurs. Un peu de connaissances en programmation peut être préjudiciable, voire tout simplement ennuyeux, si elles sont utilisées de manière incorrecte.
Malgré ces avertissements, l'accessibilité numérique n'est pas une situation tout ou rien. Il s'agit d'un spectre qui permet certaines zones grises comme celle-ci. Plusieurs solutions de programmation peuvent être considérées comme "correctes", selon la situation. L'important est que vous continuiez à apprendre, à tester et à essayer de rendre notre monde numérique plus ouvert à tous.