Propulsé par le RAAMM

WAI-ARIA et HTML5

Introduction

Au cours des dernières années, le Web est devenu de plus en plus interactif. L’arrivée de HTML5 et le développement des différentes librairies javascript y ont largement contribué.

WAI-ARIA est la réponse du W3C à cette évolution du Web. En application de la règle 4.1.2, il s’agit d’un ensemble de techniques permettant de fournir aux utilisateurs d’outils d’adaptation des informations sur le nom, le rôle, l’état, les propriétés et les valeurs de chaque composant interactif.

Le Web étant un environnement toujours en évolution, il en va de même de HTML5 et WAI-ARIA. Cette dernière spécification publiée en 2014 en est d’ailleurs déjà à la version 1.1 (2017) et le groupe de travail vient de publier en juillet 2017, la première version de travail 1.2. Une évolution très rapide pour une recommandation officielle du W3C.

La prise en charge des navigateurs et des outils d’adaptation est elle aussi en évolution. Il faut donc se tenir à jour et lire les articles qui se publient régulièrement à ce sujet.

Le présent document est une introduction. Pour approfondir le sujet et comprendre comment utiliser correctement WAI-ARIA, voir la section des références en fin de document.

Étant donné le caractère évolutif et parfois même fluctuant de la prise en charge de WAI-ARIA par les différentes environnements (combinaisons de navigateurs et de lecteurs d’écran), il est impératif de s’assurer du bon résultat dans le cadre de tests fonctionnels avec plusieurs environnements.

[/accordion-item]

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 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 suiante.

  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 de 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 : « No ARIA is better dans 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, Opera et Yandex prennent en charge MSAA/IAccessible et IAccessible2,Internet Explorer prend 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. :

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

HTML5 définit aussi de nouveaux champs et 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 et résumés.

Tous ces changements 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 : <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
  • É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-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 :

  • true/false
  • ID reference
  • number
  • string
  • etc.

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.

2e 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 :

–<h1 role=button>Nos services</h1>

À faire plutôt :

–<h1><span role=button>Nos services</span></h1>

ou, mieux :

<h1><button>Nos services</button></h1>

–ni les comportement,

–ni les états,

–ni les propriétés.

Il s’agit uniquement de déclarer pour aider à comprendre et à interagir.

ATTENTION :

Le rôle WAI-ARIA écrase le rôle sémantique natif.

Exemple :

<h1 role=button>text</h1>
devient un bouton dans la couche d’accessibilité :
–<button>text</button>
et la notion de h1 est perdue!

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.

Ne pas faire : 

<button role=heading>text</button> qui

devient un titre dans la couche d’accessibilité mais garde les comportement associés à un bouton en HTML.

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.

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 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 courts é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 toute indiquée en s’assurant que la partie visible de l’étiquette est répétée au début de la chaîne de caractère servant de valeur en application du critère de succès 2.5.3 introduit dans les WCAG 2.1. Ceci afin de s’assurer qu’un utilisateur de commandes vocales puisse facilement sélectionner un champ particulier.

Contrôle de la présentation

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

Le premier est role="presentation". Il a pour effet d’effacer le rôle sémantique d’une balise et de ses descendants obligatoire. Par exemple, il peut être avantageux d’utiliser un tableau de présentation pour faciliter la présentation d’un formulaire d’évaluation ou 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.

Toutefois, on peut éviter baucoup de verbiage inutile en utilisant role="presentation" sur la balise <table>. Ce qui aura pour effet de masquer toute la structure du tableau (balises <tr>, <th>, <td>) à l’API d’accessibilité. Cela aura pour effet d’é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.

Le deuxième est aria-hidden qui 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 a pour effet de masquer entièrement le contenu de la balise à laquelle il est appliqué et de toute autre balise qui peut y être contenue.

Par exemple, il est inutile d’essayer de lire une carte Gougle avec un lecteur d’écran ou une cadre Facebook dont le contenu va se dérouler à l’infini et dont il sera difficile ou impossible de sortir. Dans ce type de situations, une fois ce contenu masqué avec aria-hidden, il faut offrir une alternative pour accéder à un contenu équivalent. Dans le cas d’une carte, on peut offrir un lien vers l’itinéraire sur le site de Google. Dans celui d’un cadre Facebook, on peut offrir un lien vers la page Facebook dont l’utilisateur pourra consulter le contenu à sa guise et le refermer facilement pour revenir au contenu initial.

On pourrait aussi masquer un tableau complexe en offrant en contrepartie un lien vers une version simplifiée en annexe ou sur une autre page.

Les liens offerts en alternative doivent être visibles pour tous et non seulement pour les lecteurs d’écran car ces alternatives peuvent aussi intéresser d’autres visiteurs ayant d’autres types de limitations ou même sans limitations.

Menus déroulants

Un menu déroulant utilise essentiellement des listes HTML imbriquées et trois rôles pour structurer une barre de menu : menubar, menu et menuitem. Toutefois, il faut programmer les comportements pour l’utilisation au clavier. La barre de menu doit réagir comme celle d’une application bureautique, les flèches directionnelles perdant leur fonction habituelle de lecture pour se déplacer entre les menus en à l’intérieur de ceux-ci.

C’est pourquoi, dès qu’on active le menu, le lecteur d’écran passe en mode formulaire, ce que l’on pourrait aussi appeler « mode interactif » ou « mode applicatif » puisqu’il s’agit d’imiter le fonctionnement d’une application. Un signal sonore sera émis par le lecteur d’écran pour confirmer ce changement de mode.

Voici tous les rôles, état et propriétés impliqués :

  • Un menu est un conteneur d’éléments qui représentent des choix. L’élément servant de menu a un rôle de menu ou de menubar.
  • Les éléments contenus dans un menu sont des éléments enfants du menu ou de la barre de menus contenant et ont l’un des rôles suivants: menuitem,
    menuitemcheckbox ou
    menuitemradio.
  • Si l’activation d’un menuitem ouvre un sous-menu, le menuitem est connu comme un menuitem parent. L’élément de menu d’un sous-menu est contenu dans ou appartient à son parent menuitem.
    Un menuitem parent a l’état aria-haspopup défini sur menu ou true.
  • Un menuitem parent a aria-expanded défini sur false lorsque son menu enfant n’est pas visible et défini sur true lorsque le menu enfant est visible.
  • Chaque élément du menu a un tabindex égal à -1, sauf dans une barre de menus, où le premier élément est défini sur 0.
  • Si une barre de menus a une étiquette visible, l’élément avec le menu menubar a aria-labelledby défini sur une valeur qui fait référence à l’élément d’étiquetage. Sinon, l’élément menubar a une étiquette fournie par aria-label.

Voir aussi :

Panneaux à onglets

Les panneaux à onglets sont souvent imités visuellement en utilisant de simples liens. Toutefois, cette façon de faire crée de la confusion pour les utilisateurs d’un lecteur d’écran. L’utilisation des attributs WAI-ARIA permettent au lecteur d’écran d’identifier clairement ces éléments comme des onglets et d’identifier aussi l’onglet actif parmi la liste.

Comme il faut encore ici programmer l’interaction au clavier, afin de pouvoir se déplacer entre les onglets, le mode navigation sera suspendu au profit du mode interactif ou applicatif. Un signal sonore sera émis par le lecteur d’écran pour confirmer ce changement de mode.

Voici tous les rôles, état et propriétés impliqués :

  • L’élément qui sert de conteneur pour l’ensemble des onglets a un rôle tablist.
  • Chaque élément qui sert d’onglet a un rôle tab et est contenu dans l’élément ayant le rôle tablist.
  • Chaque élément qui contient le contenu du panneau d’un onglet a un rôle tabpanel.
  • Chaque élément avec un rôle tab possède la propriété aria-controls faisant référence à son élément tabpanel associé.
  • L’élément d’onglet actif a l’état aria-selected défini sur true et tous les autres éléments d’onglet l’ont défini sur false.
  • Chaque élément ayant un rôle tabpanel a la propriété aria-labelledby en se référant à son élément tab associé.
  • Si l’élément tablist est orienté verticalement, la propriété aria-orientation est définie sur vertical, mais la valeur par défaut de aria-orientation pour un élément tablist est horizontale et il donc inutile de le préciser si c’est le cas.

Voir aussi :

Boites de dialogue

Une boite de dialogue doit répondre aux conditions suivantes :

  1. Lorsqu’une boite de dialogue apparait, le focus doit y être déplacé.
  2. La boite de dialogue doit être identifée en tant que boite de dialogue avec un identifiant qui en indique la fonction.
  3. Tout le contenu de la page en dehors de la boite de dialogue doit être masqué pour les outils d’adaptation.
  4. La boite de dialogue doit pouvoir être fermée avec le bouton prévu à cet effet ou avec la touche ÉCHAPPE.
  5. À la fermeture de la boit de dialogue, le focus doit être ramené à l’élément qui en a déclenché l’ouverture.

Voici tous les rôles, état et propriétés impliqués :

  • L’élément qui sert de conteneur de dialogue a un rôle de dialog.
  • Tous les éléments requis pour faire fonctionner le dialogue sont les descendants de l’élément qui a un rôle dialog.
  • L’élément de conteneur de dialogue a aria-modal défini sur true.
  • Le dialogue a soit :
    • Une valeur définie pour la propriété aria-labelledby qui fait référence à un titre de boîte de dialogue visible.
    • Une étiquette spécifiée par aria-label.
    • Facultativement, la propriété aria-describedby est définie sur l’élément avec le rôle dialog pour indiquer quel élément ou quels éléments de la boîte de dialogue contiennent du contenu qui décrit l’objectif principal ou le message de la boîte de dialogue. La spécification d’éléments descriptifs permet aux lecteurs d’écran d’annoncer la description avec le titre de la boîte de dialogue et l’élément initialement ciblé lorsque la boîte de dialogue s’ouvre.

Voir aussi :

Accordéons

L’utilisation de panneaus accordéons est très populaire, notamment pour les foire aux questions. Un accordéon doit répondre aux conditions suivantes :

  1. Il doit être ouvert ou fermé à l’aide d’un bouton et non d’un lien.
  2. L’état doit être communiqué lorsque le focus atteint le bouton et tout changement d’état doit être immédiatement annoncé à l’utilisateur.
  3. Lorsqu’un accordéon est ouvert, le focus demeure sur le bouton d’ouverture car le message de changement d’état suffit à confirmer le résultat de l’action.

Voici tous les rôles, état et propriétés impliqués :

  • Le titre de chaque en-tête d’accordéon est contenu dans un élément avec un rôle button.
  • Chaque bouton d’en-tête d’accordéon est enveloppé dans un élément d’en-tête de niveau approprié pour l’architecture d’information de la page.
  • L’élément button est le seul élément à l’intérieur de l’élément d’en-tête. Autrement dit, s’il existe d’autres éléments visuellement persistants, ils ne sont pas inclus dans l’élément de titre.
  • Si le panneau d’accordéon associé à un en-tête d’accordéon est visible, l’élément button a aria-expanded défini sur true. Si le panneau n’est pas visible, aria-expanded est défini sur false.
  • L’élément du bouton d’en-tête accordéon a aria-controls défini sur l’ID de l’élément contenant le contenu du panneau accordéon.

Voir aussi :

Validation de formulaire

Il y a deux méthodes pour faire la validation d’un formulaire : champ par champ lorsque le focus quitte le champs et de façon globale au moment où l’on soumet le formulaire. Idéalement, il est souhaitable de combiner ces deux méthodes.

Voici tous les rôles, état et propriétés impliqués :

  • Les champs obligatoires ont aria-required défini à true.
  • Les messages d’erreur sont immédiatement intégré à l’étiquette du champ en erreur (<label> associé au champ).
  • Le message d’erreur est placé dans une balise <span> avec aria-live défini à assertive afin que le lecteur d’écran lise le message d’erreur au moment où il apparaît.

Voir aussi :

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