WAI-ARIA et HTML5

WAI-ARIA est une couche d’accessibilité qui permet de transmettre aux utilisateurs via leur outil d’adaptation des informations supplémentaires nécessaires à une bonne compréhension des éléments interactifs. Pour ce faire, les attributs WAI-ARIA viennent s’ajouter aux balises HTML.

WAI-ARIA n’est pas une solution de correction pour un contenu Web mal structuré ou pour des balises HTML mal utilisées. Une mauvaise utilisation de WAI-ARIA peut même aboutir à des résultats contraires aux objectifs.

Dans l’ordre, les différentes couches de conception s’ajoutent les unes aux autres et chaque couche doit être solide afin de pouvoir y ajouter la suivante.

1. Le code HTML, où chaque balise est utilisée selon son rôle sémantique;
2. La feuille de style CSS, qui gère tous les aspects de la présentation;
3. La programmation JavaScript, qui permet de créer des composants interactifs;
4. Les attributs WAI-ARIA, qui viennent enrichir l’information pour les utilisateurs d’outils d’adaptation.

Il est d’ailleurs important de noter dès le départ que les attributs WAI-ARIA n’ont qu’une valeur « déclarative » qui ne change pas l’interaction habituellement prévue pour les balises HTML. Par exemple, WAI-ARIA pourrait permettre de redéfinir un titre de niveau 2 comme bouton, mais ne permettra pas d’interagir avec ce bouton tant que le nouveau comportement ne sera pas programmé en JavaScript.

Lorsqu’une fonction est déjà prévue en HTML, il est toujours préférable d’utiliser une balise HTML pour remplir cette fonction plutôt que d’assigner un nouveau rôle à une autre balise et d’en reprogrammer le comportement.

WAI-ARIA est une couche finale que l’on ne doit pas utiliser si l’on n’en a pas besoin. En anglais, on dit d’ailleurs : « No ARIA is better than bad ARIA ». C’est une maxime à ne pas oublier.

Le W3C a aussi défini la façon dont les outils d’adaptation doivent interpréter les attributs WAI-ARIA.

• Le rôle, le nom et l’état de chaque élément,
• Sa relation avec les autres éléments.

Ces informations sont transmises via une API (interface de programmation applicative) d’accessibilité. Les navigateurs prennent en charge une ou plusieurs API :

Windows :

• Firefox, Chrome, Edge, Opera et Yandex prennent en charge MSAA/IAccessible et IAccessible2;
• Internet Explorer, aujourd’hui arrivé en fin de vie, prenait en charge MSAA/IAccessible et UIAExpress.

OSX :

• Safari et Chrome prennent en charge NSAccessibility.

iOS :

• Safari et Chrome prennent en charge UIAccessibility.

Les attributs WAI-ARIA sont interprétés automatiquement par le navigateur et transmis à la couche d’accessibilité du système d’exploitation puis à l’outil d’adaptation.

Aux éléments de contrôle actuels : case à cocher, bouton radio, boutons, boutons image, téléversement de fichier, HTML5 introduit de nouveaux types d’entrées, sous la forme de valeurs de l’attribut type :

• Glissière (range),
• Boîtes de texte :
  • texte,
  • recherche (search),
  • téléphone (tel),
  • URL (url),
  • courriel (email),
  • mot de passe (password).
• Dates et heures (date, time, datetime),
• Nombres (number),
• Sélection de couleur (color).

HTML5 définit aussi de nouvelles balises de champs et de nouveaux attributs de formulaire :

• Résultat d’un calcul ou d’un affichage (<output>);
• Progression (<progress>);
• Jauge (<meter>);
• Obligatoire (required);
• Limites et incréments (min, max, step);
• Autocomplétion, listes;
• Espace réservé (placeholder);
• Autofocus;
• Éléments interactifs;
• Menus;
• Détails (<details>) et sa balise enfant de résumé (<summary>).

Un autre apport significatif du HTML5 est l’ajout de balises visant à structurer des sections (ou régions) d’une page :

• Contenu d’introduction (<header>);
• Pied de page (<footer>);
• Navigation (<nav>);
• Contenu principal (<main>);
• Article, composition autonome (<article>);
• Élément aparté (<aside>);
• Section générique (<section>).

Tous ces changements, dont la liste n’est pas exhaustive, visent à :

• Une meilleure cohérence dans l’expérience utilisateur avec les applications de bureau;
• Moins de développement personnalisé de composants;
• Du HTML plus sémantique. Ex. : <article>, <header>, <footer>, plutôt que <div>.

Tous les nouveaux éléments de HTML5 doivent être reconnus par l’API d’accessibilité.

Pour ce faire, WAI-ARIA propose 3 types d’attributs : rôles, états et propriétés.

• Rôle : Type de l’élément
  • attribut role (dont la valeur précise ce rôle)
  • exemples de rôles : ceux de régions ARIA présentés à la règle 1.3 Adaptable – Perception de la structure, ou encore, menubar, tablist, alert, etc.
• État : caractéristique dynamique d’un élément
  • attribut aria-*
  • exemples : aria-checked, aria-selected, aria-current, aria-hidden, etc.
• Propriété : caractéristique statique d’un élément
  • attribut aria-*
  • exemples : aria-required, aria-checked, aria-label, aria-describedby, aria-haspopup, etc.

De l’aveu même du W3C, la différence entre état et propriété est assez subtile. c’est pourquoi les deux sont souvent regroupés sous le titre « États et propriétés ».

À chacun de ceux-ci peut s’appliquer une valeur qui peut prendre différentes formes :

• valeurs boléennes true ou false;
• référence à un identifiant (ID);
• nombre;
• chaîne de caractères (string);
• etc.

Deux grandes règles doivent être respectées lorsqu’on a recours à WAI-ARIA.

1^ère règle :

Utiliser un élément natif HTML si possible, plutôt que WAI-ARIA.

Exceptions :

• Incapacité d’habiller l’élément en CSS comme désiré;
• Fonction non disponible en HTML;
• Fonction disponible en HTML mais non prise en charge par les navigateurs ou les technologies d’adaptation.

2^e règle :

Ne pas changer la sémantique native HTML, sauf cas particulier.

Exemple : Un titre de section qui soit en même temps un bouton.

À ne pas faire :

À faire plutôt :

Autrement dit…

Ajouter un rôle ne change :

• ni les comportement,
• ni les états,
• ni les propriétés.

Il s’agit uniquement de déclarer un rôle pour aider à comprendre sa fonction et à prévoir la façon d’interagir avec cet élément.

Changer le rôle d’un élément n’ajoute pas automatiquement les comportements (programmation), les propriétés et les états afférents; il faut les développer soi-même.

De plus, le rôle WAI-ARIA écrase le rôle sémantique natif.

Mauvais exemples d’écrasement de la sémantique

• <h1 role="button">texte</h1> devient un bouton dans la couche d’accessibilité, au même titre que <button>texte</button>. Ainsi, la notion de niveau d’en-tête 1 (h1) est perdue!
• <button role="heading">texte</button> devient un titre dans la couche d’accessibilité, mais garde les comportement associés à un bouton en HTML.

Ajout d’information de contextualisation

Trois attributs WAI-ARIA permettent d’ajouter de l’information de contextualisation à des éléments pouvant recevoir le focus.

1. L’attribut aria-labelledby permet d’associer un ou plusieurs éléments visibles à l’écran à un élément interactif en indiquant le ou les ID comme valeur. Par exemple, dans un formulaire présenté sous la forme d’un tableau de données ou chaque champ tire sa signification des titres de colonne et de ligne correspondants, ces titres peuvent être associés au champ en indiquant leur ID comme valeur de l’attribut aria-labelledby.
2. L’attribut aria-describedby joue sensiblement le même rôle et fonctionne de la même façon que aria-labelledby. La nuance entre les deux est que dans le cas de aria-labelledby, il s’agit de courtes étiquettes alors qu’avec aria-describedby, on peut associer des paragraphes entiers si nécessaire, qu’ils soient d’ailleurs visibles à l’écran ou placés hors écran.
3. L’attribut aria-label, quant à lui, utilise plutôt une valeur présentée sous la forme d’une chaîne de caractères qui ne sont pas visibles à l’écran ou visibles seulement en partie. En effet, si une ou plusieurs étiquettes sont déjà visibles à l’écran, il faut plutôt utiliser aria-labelledby. Toutefois, si l’on veut ajouter des éléments d’information supplémentaires à une étiquette déjà visible à l’écran, l’utilisation de aria-label est tout indiquée. Dans ce cas, il est important de s’assurer que tout le texte faisant partie de l’étiquette visible soit répété intégralement dans la valeur du aria-label,  idéalement au début de la chaîne de caractères. Cette précaution, qui réfère au critère de succès 2.5.3 (WCAG 2.1), vise à s’assurer qu’un utilisateur de commandes vocales puisse facilement sélectionner un élément interactif doté d’une étiquette visible.

Contrôle de la présentation

Deux attributs WAI-ARIA permettent de contrôler la présentation de certains éléments :

• role="presentation";
• aria-hidden, qui peut recevoir la valeur true ou false.

Le rôle de présentation

L’attribut role="presentation" a pour effet d’effacer le rôle sémantique d’une balise et de ses descendants obligatoires. Par exemple, il peut être avantageux d’utiliser un tableau de présentation pour faciliter la disposition visuelle d’un formulaire d’évaluation où chaque item doit être coté de 1 à 5 à l’aide de boutons radio. Il y aura évidemment un problème d’étiquetage de chacun de ces boutons, dont nous avons déjà parlé dans la section précédente.

Ainsi, dans le contexte d’un tableau de présentation, on peut éviter beaucoup de verbiage inutile sur la balise  <table> en lui retirant son rôle au moyen de role="presentation" . Cela aura pour effet de masquer toute la structure du tableau (balises <tr>, <th>, <td>) à l’API d’accessibilité. Cela va également éliminer toutes les informations sur la taille du tableau ainsi que les numéros de lignes et de colonnes, informations inutiles qui ne contribuent qu’à créer de la confusion pour l’utilisateur d’un lecteur d’écran.

L’attribut aria-hidden

L’attribut de propriété aria-hidden peut recevoir la valeur true ou false. Il s’agit d’une arme puissante qu’il faut utiliser seulement dans des cas particuliers. Cet attribut retire entièrement, dans l’arbre d’accessibilité du document, le contenu de la balise à laquelle il est appliqué, ainsi que tous les contenus et balises enfants. C’est donc dire qu’un contenu masqué avec aria-hidden="true" sera masqué aux outils d’adaptation, sans toutefois être masqué visuellement.

Attention : La spécification WAI-ARIA n’autorise pas l’usage de aria-hidden="true" sur des balises dont le contenu reçoit le focus, ou sur toute balise dont les éléments enfants sont focusables. On ne peut, par exemple, appliquer cet attribut sur la balise d’un lien ou d’un bouton recevant le focus.

Bon à savoir : Il importe de considérer toutes les personnes ayant des limitations, lorsqu’on s’interroge sur la pertinence d’employer aria-hidden="true". En effet, les personnes aveugles et malvoyantes ne sont pas les seules clientèles utilisant des outils d’adaptation reconnaissant l’instruction donnée par cet attribut.

Voici quelques exemples d’emploi de aria-hidden="true" :

• Pour masquer des images purement décoratives, notamment celles intégrées depuis la balise <svg> ou à l’aide l’icônes sous forme de caractères textuels (voir l’exemple de code plus bas);
• Pour masquer des contenus dupliqués, tels que du texte répété.

Exemples de masquage d’icônes décoratives à l’aide de aria-hidden="true"

<button>
  <svg aria-hidden="true">...</svg>
  Fermer
</button>

<a href="...">
  <span class="fa-regular fa-envelope" aria-hidden="true"></span>
  Nous joindre
</a>...

Composants interactifs

Voici plus bas des exemples de composants interactifs qui utilisent des attributs WAI-ARIA. Ils sont tirés de la banque de composants Web accessibles du Laboratoire.

Pour chaque composant listé, nous fournissons des liens vers un exemple fonctionnel et vers la documentation qui traite précisément de l’emploi d’ARIA pour ce composant.

Au passage, nous recommandons la lecture complète de la fiche explicative du composant, aussi proposée en hyperlien. De fait, l’emploi d’ARIA ne constitue qu’une partie de la solution technique pour rendre accessible un composant interactif. En consultant chaque fiche, vous aurez une vue d’ensemble des principes du composant, ainsi que des aspects fonctionnels et techniques à surveiller.

Accordéons

• Exemple d’accordéons accessible
• Attributs ARIA du composant Accordéons
• Fiche explicative complète du composant Accordéons

Boîte de dialogue modale

• Exemple de boîte de dialogue accessible
• Attributs ARIA pour une boîte de dialogue
• Fiche explicative complète de la boîte de dialogue

Validation de formulaire

• Exemple de validation de formulaire accessible
• Attributs ARIA pour la validation de formulaire
• Fiche explicative complète de la validation de formulaire

Champ d’autocomplétion

• Exemple de champ d’autocomplétion accessible
• Attributs ARIA pour le champ d’autocomplétion
• Fiche explicative complète du champ d’autocomplétion

Panneaux à onglets

• Exemple de panneaux à onglets accessibles
• Attributs ARIA pour les panneaux à onglets
• Fiche explicative complète des panneaux à onglets

Menus déroulants

Deux techniques peuvent être utilisées pour rendre un menu déroulant accessible : les menus en accordéons et les menus interactifs ARIA. Après une mise en contexte de ces deux approches, nous fournissons un accès aux ressources pertinentes pour intégrer WAI-ARIA dans leur conception.

• Menus déroulants en accordéons (approche à privilégier) : La navigation contient une liste de boutons qui représentent diverses sections d’un site Web et permettent d’étendre ou de réduire des menus de liens associés.
• Menus interactifs ARIA : Ceux-ci utilisent des rôles tels que menubar et menu. Cependant, comme l’explique le W3C dans son Guide des pratiques de conception ARIA, les menus ARIA sont associés à une plus grande complexité d’interactions, notamment avec des outils d’adaptation. C’est pourquoi le Guide estime que l’approche des accordéons (disclosure pattern) est généralement mieux adaptée aux sites Web typiques qui ne nécessitent pas la complexité des interactions clavier d’un menu interactif ARIA.
  • Remarque : Ce menu est qualifié d’interactif, car il entraîne l’activation du mode « interactif » (ou applicatif) de certains lecteurs d’écran, pour utiliser les touches clavier assurant les déplacements dans le composant. Le basculement vers le mode interactif sera confirmé par un signal sonore émis par le lecteur d’écran.

Menus déroulants en accordéons (à privilégier)

• Exemple de menus en accordéons accessible
• Attributs ARIA pour les menus en accordéons
• Fiche explicative complète des menus en accordéons

Menus déroulants interactifs ARIA

Les ressources qui suivent (en anglais) sont tirées du Guide des pratiques de conception ARIA du W3C. Comme l’indique le Guide, les codes et exemples fournis ne sont pas destinés à être utilisés en production et visent principalement à illustrer une manière d’employer ARIA qui se conforme à la spécification. Le guide nous avertit par ailleurs de la possibilité de différences dans le niveau de support des outils d’adaptation pour cet exemple. Ces ressources sont donc à considérer avec prudence.

• Exemple de menu interactif ARIA
• Attributs ARIA pour le menu interactif ARIA
• Fiche explicative complète de l’exemple de menu interactif

Pour approfondir le sujet et comprendre comment utiliser correctement WAI-ARIA, vous pouvez vous référer aux sources suivantes (en anglais) :

• Accessible Rich Internet Applications (WAI-ARIA) 1.2
• WAI-ARIA Authoring Practices Guide (APG)
• Core Accessibility API Mappings 1.1, ainsi que la recommandation candidate de la version 1.2
• ARIA in HTML
• ARIA and Assistive Technologies Project (ARIA-AT) : Ce projet développe des mesures du niveau de support des outils d’adaptation pour les exemples de composants interactifs fournis dans le Guide des pratiques de conception ARIA (APG).