ARIA et HTML

La plupart des développeurs connaissent le langage de balisage standard de notre environnement Web, HyperText Markup Language (HTML). Cependant, vous connaissez peut-être moins Accessibles Rich Internet Applications (ARIA) (formellement appelé WAI-ARIA): ce que c'est, comment et quand, et quand pas, l'utiliser.

HTML et ARIA jouent un rôle important dans l'accessibilité des produits numériques, en particulier lorsqu'il s'agit de technologies d'assistance (TA) telles que les lecteurs d'écran. Les deux sont utilisés pour convertir le contenu dans un format alternatif, tel que le braille ou Text-to-Speech (TTS)

Passons en revue un bref historique des ARIA, en quoi ils sont importants, quand et comment mieux de l'utiliser.

Présentation d'ARIA

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

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

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

<ph type="x-smartling-placeholder"></ph> Le groupe WAI

Arborescence d'accessibilité

ARIA modifie le code incorrect ou incomplet afin d'améliorer l'expérience pour ceux qui utilisent les TA en modifiant, en exposant et en améliorant des parties de l'accessibilité arborescence.

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

À lui seul, ARIA ne modifie pas la fonctionnalité ni l'apparence visuelle d'un élément. Cela signifie que seuls les utilisateurs de TA remarqueront les différences entre un produit numérique avec ARIA et un sans. Cela signifie aussi que les développeurs sont seuls pour apporter les modifications de code et de style appropriées à un élément que possible.

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

Les rôles définissent ce qu'est ou fait un élément 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/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. Au lieu de cela, superposez les rôles, les propriétés et les états/valeurs ARIA jusqu'à atteint votre objectif final en matière d’accessibilité. L'intégration correcte des données ARIA dans votre code base garantit que les utilisateurs AT disposent de toutes les informations nécessaires pour utilisent votre site Web, votre application ou tout autre produit numérique de manière efficace et équitable.

Depuis peu, les outils pour les développeurs Chrome afficher l'arborescence complète d'accessibilité ce qui permet aux développeurs de mieux comprendre l'impact de leur code l'accessibilité.

Quand utiliser ARIA ?

En 2014, le W3C a officiellement publié sa recommandation HTML5. Avec lui quelques changements importants, y compris l'ajout d'éléments emblématiques tels que <main>, <header>, <footer>, <aside>, <nav> et des attributs tels que hidden et required Grâce à ces nouveaux éléments et attributs HTML5, prise en charge accrue des navigateurs, certaines parties d'ARIA sont désormais moins critiques.

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

Cela nous amène à la question fondamentale: quand utiliser ARIA ? Heureusement le groupe WAI a développé cinq règles des principes ARIA pour vous aider à décider pour 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 accessibles. Rapport annuel sur l'accessibilité de WebAIM Million a constaté que les pages d'accueil avec ARIA présente en moyenne 70% d'erreurs détectées en plus que celles sans ARIA, en raison d'une mauvaise mise en œuvre 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 ne un élément HTML spécifique, ou la fonctionnalité/comportement souhaité n'est pas disponibles au format HTML. Cependant, ces situations sont 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 d'éléments ARIA (inutiles) au code HTML

Dans la plupart des cas, les éléments HTML fonctionnent bien et ne nécessitent pas l'ajout d'éléments 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.

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

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

Travaillez moins et obtenez un code plus performant lorsque vous utilisez des éléments HTML en tant que prévu.

Règle 3: Toujours prendre en charge la navigation au clavier

Toutes les commandes ARIA interactives (non désactivées) doivent être accessibles au moyen du clavier. Toi peut ajouter tabindex= "0" à tout élément nécessitant une attention qui n'est pas recevoir le focus du clavier. Évitez d'utiliser des index de tabulation avec des valeurs positives entiers dans la mesure du possible pour éviter d'éventuels problèmes 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 sélectionnés, y compris les éléments avec tabindex= "0". Lorsque vous ajoutez ces rôles/états aux éléments, il envoie un message à la TA indiquant que ces éléments ne sont pas importants et de 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: Utilisez des noms accessibles pour les éléments interactifs

L'objectif d'un élément interactif doit être communiqué à un utilisateur avant il sait comment interagir avec. Assurez-vous que tous les éléments ont un nom accessible pour les personnes utilisant TA appareils.

Les noms accessibles peuvent être le contenu entouré par 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 "cuir rouge" bottes. »

<!-- 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 en HTML

Bien que l'utilisation d'éléments HTML seuls soit une bonne pratique, les éléments ARIA peuvent être ajoutées dans certaines situations. Par exemple, vous pouvez associer ARIA avec HTML dans modèles nécessitant un niveau de soutien plus élevé de la technologie de TA en raison de l'environnement ou comme méthode de remplacement pour les éléments HTML qui ne sont pas entièrement compatibles avec 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, de réduire la redondance et d'être conscient des effets secondaires imprévus.

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é de l'algorithme ARIA

Les données ARIA étant complexes, vous devez toujours faire preuve de prudence lorsque vous les utilisez. Alors que le exemples de code présentés dans cette leçon sont assez simples, ce qui crée les motifs personnalisés peuvent rapidement devenir compliqués.

Vous devez prendre en compte de nombreux points, y compris, mais sans s'y limiter: interactions avec le clavier, interfaces tactiles, prise en charge des technologies de l'information et du navigateur, besoins en traduction, les contraintes d'environnement, l'ancien code et les préférences des utilisateurs. Un peu les connaissances en codage peuvent être préjudiciables, voire pénibles, si elles sont utilisées. incorrectement. N'oubliez pas que votre code doit être simple.

Ces avertissements mis à part, l'accessibilité numérique n'est pas il s'agit d'un spectre qui permet d'avoir certaines 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 de continuer à apprendre, tester et essayer de rendre nos un monde numérique plus ouvert à tous.

Testez vos connaissances

Tester vos connaissances sur ARIA et HTML