Accessible Rich Internet Applications (ARIA)

ARIA signifie "Accessible Rich Internet Applications". Tout comme les Règles d'accessibilité pour les contenus web, ARIA est une spécification du W3C. Elle définit une série d'attributs qui peuvent améliorer la sémantique d'une application web. Ces attributs n'ont pas d'influence sur l'aspect visuel et ils n'influencent pas la manière dont les navigateurs traitent les éléments. Leur seul rôle est de fournir de l'information supplémentaire pour les logiciels d'assistance avec lesquels les personnes en situation de handicap utilisent leur ordinateur (surtout les lecteurs d'écran).

Exemples de ce que les attributs ARIA peuvent faire

  • améliorer l'accessibilité de widgets (comme les onglets) pour lesquels il n'existe pas de balises HTML spécifiques.
  • communiquer un statut qui est visuellement très clair mais qui n'est pas annoncé par un lecteur d'écran, par exemple si un sous-menu est déplié ou pas.
  • faire annoncer à un lecteur d'écran qu'une information est apparue ou a été mise à jour ailleurs sur la même page.
  • nommer plus clairement des éléments d'une page (ou application) web pour les personnes aveugles qui n'ont pas la vue d'ensemble de la page.
  • ajouter de l'information sémantique qui n'existe pas (encore) en HTML. Il n'est par exemple pas encore certain que l'élément main intégrera définitivement la spécification HTML5. Entretemps vous pouvez ajouter un role="main" au div qui englobe le contenu principal de votre page.

L'accessibility tree

Un lecteur d'écran est un logiciel qui lit le contenu d'une page web et le restitue au moyen d'une synthèse vocale ou de braille. Le contenu qui est transmis ne se limite pas au texte qui est affiché. Le lecteur d'écran transmet également de l'information sémantique. Il lira par exemple 'Actualités titre de niveau 2' ou 'lien visité Contact'. Tout ce contenu est mis à la disposition du lecteur d'écran par les navigateurs par l'intermédiaire de l'accessibility tree.

L'accessibility tree est une structure, construite sur base du code source et des scripts, comme le DOM, mais qui

  • ne contient pas les information inutiles pour l'accessibilité (le lecteur d'écran n'a pas besoin de savoir qu'il y a 15 div imbriqués)
  • associe à chaque élément un rôle, un nom et un état.

Pour les éléments HTML standards (img, button, h1,...) ces informations sont disponibles par défaut. Par exemple pour le <button>Search</button>, les informations remplies dans l'accessibility tree sont:

  • Rôle: button,
  • Nom: Search,
  • Statut: focusable, unselected.

Sur base de ces informations, l'internaute sait de quelle manière il peut interagir avec le contenu.

Pour les widgets, ou composants d'interfaces riches, qui sont composés d'éléments HTML standards, les informations qui se trouvent dans l'accessibility tree sont insuffisantes. Elles ne permettent pas de comprendre la nature du composant complexe et d'anticiper son comportement. Un module d'onglets sera vu par le lecteur d'écran comme une liste de liens suivie d'un paragraphe de texte. Rien ne permettra à l'utilisateur du lecteur d'écran d'anticiper que le contenu de ce paragraphe est modifié chaque fois qu'un des liens est activé. Rien n'indique que ces éléments forment un tout, ni quelle est la nature de ces composants.

Les attributs ARIA peuvent servir à compléter l'information de l'accessibility tree, pour rendre les interfaces riches compréhensibles et utilisables avec un lecteur d'écran.

Utilisez le plus possible des éléments HTML standards

S'il existe un élément HTML qui correspond à ce dont vous avez besoin, utilisez-le. Quand on utilise des éléments HTML standards, les navigateurs implémentent le comportement standard correspondant et transmettent toute l'information aux lecteurs d'écrans et autres technologies d'assistance.

L'exemple ci-dessous montre qu'il est beaucoup plus simple d'utiliser un élément standard que de devoir le réinventer:

Deux manières de programmer un bouton
<button>Pause</button>
<div onclick="..." class="boutonpause">Pause</div>
Les navigateurs, technologies d'assistance et moteurs de recherche l'identifient comme un bouton Au niveau sémantique ce n'est pas un bouton (donc pas non plus dans l'accessibility tree)
Le lecteur d'écran dit "Bouton pause" Le lecteur d'écran dit "Pause"
Même sans CSS on reconnait un bouton; il est clair visuellement qu'il est cliquable Sans CSS on ne reconnait pas un bouton; même pour onMouseOver il n'y a pas d'indication visuelle que c'est cliquable
On peut l'atteindre avec le TAB On ne peut pas l'atteindre avec le TAB
On peut l'activer avec ENTER et ESPACE Pas activable au clavier (car on ne peut l'atteindre)
Outline visible Pas d'outline

Si vous utilisez un div à la place d'un button, vous devez résoudre vous-même tous les problèmes indiqués dans la deuxième colonne:

  • Vous pouvez ajouter l'attribut ARIA role="button" au div. Cela ne résout que les deux premiers problèmes : le div devient un bouton dans l'accessibility tree. Un lecteur d'écran l'annoncera donc comme un bouton. Mais les points suivants ne sont pas résolus par ARIA.
  • Visuellement le div ne ressemble pas à un bouton : il faut corriger cela dans le CSS.
  • Les utilisateurs du clavier ne peuvent pas atteindre un div en utilisant le TAB. Vous devrez corriger cela en utilisant un attribut tabindex="0"
  • L'utilisateur de lecteur d'écran ne peut pas activer le bouton en utilisant ENTER, alors qu'il est annoncé comme un bouton : c'est à corriger en Javascript.

Tout cela est beaucoup plus compliqué que d'utiliser un élément standard. C'est bien expliqué dans l'article HTML5 accessibility chops : Just use a (native HTML) button. Voir aussi OnClick? Préférez un lien ou un bouton.

L'attribut role

L'attribut role peut être ajouté à tout élément (X)HTML(5). Il faut tenir compte des règles suivantes:

  • Si le composant n'a pas encore de rôle dans l'accessibility tree, l'attribut role va en ajouter un.
  • Si le composant a déjà un rôle dans l'accessibility tree, alors l'attribut role va écraser ce rôle existant.
  • C'est la seule chose que fait l'attribut role. Il ne modifie ou n'ajoute pas de comportement, le statut ou les propriétés.

Écrase la sémantqiue

Si vous ajoutez un rôle ARIA, vous écrasez la sémantique native de l'élément. Il ne faut donc en principe utiliser cet attribut que pour des éléments vides de sémantique, comme un div.

Mauvais exemple:

<nav>
 <ul role="navigation">
 ...
 </ul>
</nav>

La sémantique de l'élément ul (liste) est remplacée par role="navigation". Dans l'accessibility tree il n'y a donc plus de liste. Le lecteur d'écran va bien annoncer qu'un bloc de navigation commence ici, mais n'indiquera pas qu'il s'agit d'une liste de x éléments.

Bon exemple:

<nav role="navigation">
 <ul>
 ...
 </ul>
</nav>

Il faut être extrêmement prudent en ajoutant des rôles ARIA car un élément ne peut avoir qu'un rôle. Si vous utilisez l'attribut role, il a priorité, quel que soit l'élément sur lequel vous l'ajoutez. ARIA l'emporte!

N'ajoute pas de comportement, de statut ou de propriétés

Si vous ajoutez un attribut role, le comportement, le statut ou les propriétés du composant ne changent pas.

<div role="heading" aria-level="1">Texte</div>

devient dans l'accessibility tree:

<h1>Texte</h1>

Les lecteurs d'écran et les moteurs de recherche verront un titre de niveau 1, mais visuellement rien n'aura changé.

En général, il ne suffit pas d'ajouter un rôle ARIA pour régler un problème.

Quels rôles?

L'attribut role peut prendre une septantaine de valeurs. Un premier groupe sont les rôles landmark. Il est recommandé de les utiliser car ils aident un utilisateur de lecteur d'écran à naviguer plus facilement dans la page. Par contre il faut éviter dans la plupart des cas d'utiliser le role="application".

Certains rôles correspondent sémantiquement à des éléments natifs en HTML, comme par exemple role="button" qui est équivalent à <button>, ou role="checkbox" qui est équivalent à <input type="checkbox" />. D'autres rôles n'ont pas d'équivalent sémantique en HTML, comme par exemple role="tablist".

Certains rôles ont un nom trompeur. Le role="menu" n'est pas destiné à être utilisé dans des menus de navigation d'un site web. Il est prévu pour des barres de tâches telles qu'on en trouve par exemple dans les éditeurs de texte, mais pas pour des listes de liens, même s'ils disposent de sous-menus. Vous trouverez plus d'exemples dans l'article How Not To Misuse ARIA States, Properties and Roles.

L'ajout de rôles ARIA inappropriés peut rendre une page web ou un composant complètement inutilisable pour certains. Pour chaque rôle, l'utilisateur s'attend à trouver un certain comportement. Si le comportement effectif n'est pas celui qui est attendu, c'est en général un grand problème. Par exemple, pour un élément avec role="checkbox", l'utilisateur s'attend à pouvoir cocher la case avec la barre d'espace, et quand cela ne fonctionne pas il est probablement bloqué.

Statuts et propriétés

Dans l'accessibility tree, les roles ARIA n'influencent que le rôle des éléments. Il existe d'autres attributs ARIA qui permettent de modifier le nom, le statut et les propriétés d'un élément. Le nom de ces attributs commencent par "aria-".

Un exemple de propriété est aria-haspopup="true". Si vous insérez cette propriété dans l'accessibility tree pour un lien , le lecteur d'écran pourra annoncer l'existence d'un sous-menu. Dans ce cas-ci, ARIA permet de communiquer une information qui est présente visuellement mais qui ne pourrait pas être perçue par un utilisateur lecteur d'écran, sans l'ajout de cet attribut.

aria-expanded="true" est un exemple d'attribut qui représente l'état d'un élément. Il indique ici qu'un menu déroulant est ouvert. La différence entre états et propriétés est qu'un état change plus souvent. Quand le menu déroulant se referme, il ne faut pas oublier de changer ce statut en utilisant aria-expanded="false". How to toggle ARIA values with Javascript?.

Nom

Les éléments qui se trouvent dans l'accessibility tree ont besoin d'un nom. Dans le cas d'éléments HTML le nom est automatiquement rempli. Par exemple, pour une image c'est l'attribut alt qui sert de nom. Le nom d'un lien est le texte du lien. Pour un bouton d'envoi, c'est le contenu de l'attribut value qui sert de nom au bouton.

Il y a deux attributs aria qui permettent de donner un nom à un élément ou de modifier le nom existant: aria-label et aria-labelledby. La valeur de aria-label doit être un texte, qui deviendra le nom de l'élément; aria-labelledby prend la valeur de l'id d'un élément qui contient le texte qui doit servir à identifier l'élément.

Attention

  • Il y a deux 'l' dans 'labelledby'
  • Il ne sert à rien de mettre un attribut aria-label(ledby) sur un span ou un div, sauf s'ils ont aussi un attribut role, car ces éléments ne font pas partie de l'accessibility tree.
  • Si l'élément avait déjà un nom, celui-ci sera remplacé par celui spécifié avec aria-label(ledby). Donc surtout ne pas faire ceci:<a aria-label="Lien externe" href="http://www.anysurfer.be">AnySurfer</a>. Dans cet exemple le texte du lien sera perdu et remplacé par 'lien externe'.
  • L'utilisation d'aria-label être de source de confusion car son contenu est visible pour les logiciels d'aide technique, mais n'est pas visible à l'écran.

    <a href="/en" aria-label="Anglais">EN</a>

    Dans l'exemple ci-dessus il y a un lien vers la version anglaise d'un site: le texte du lien "EN" N'est peut-être pas significatif pour tout le monde. Ce texte a été remplacé dans l'accessibility tree par 'Anglais' en utilisant aria-label. Cela semble une bonne idée: Un lecteur d'écran lit maintenant 'Lien Anglais'. Mais sur l'écran on lit toujours 'EN':

    • L'utilisateur de lecteur d'écran ne sait pas que ce qu'il entend est différent de ce qui est affiché. Cela peut porter à confusion quand il parle à une personne voyante.
    • Une personne qui utilise une reconnaissance vocale comme Dragon Naturally Speaking dira 'Cliquer EN' parce que c'est cela qu'il voit à l'écran. Cela ne fonctionnera pas car le texte est devenu 'anglais' pour Dragon.

Quand utiliser ARIA?

  • N'utilisez ARIA que lorsqu'il manque des informations dans l'accessibility tree ou lorsque l'information qui s'y trouve est incorrecte.
  • Si vous utilisez un toolkit of framework UI ARIA est souvent déjà utilisé, ou il existe un plugin pour l'ajouter.
  • Si vous construisez vous-même un widget qu'il n'est pas possible de rendre totalement accessible en utilisant uniquement HTML et CSS, vous pouvez utiliser ARIA. Suivez toujours les motifs de conception (Design Patterns) décrits dans les WAI-ARIA Best Practices. Ils décrivent le comportement de chaque type de widget. Vous y trouverez le comportement au clavier que vous devrez implémenter ainsi que les attributs ARIA à utiliser.
  • Si vous utilisez des attributs ARIA, vous devez le faire de manière informée. Un mauvais usage peut avoir des effets néfastes.

Support

Pour qu'un attribut ARIA ait un effet, il faut que le navigateur et le lecteur d'écran le supportent. Quand il n'y a pas de support un attribut ARIA est simplement nié: un <div role="button"> devient un <div>.

Les navigateurs et lecteurs d'écrans les plus récents offrent le meilleur support. Les versions plus anciennes contiennent des bugs. Il y a beaucoup de personnes qui n'utilisent pas les versions les plus récentes des navigateurs et lecteurs d'écrans. C'est pourquoi nous demandons de n'utiliser ARIA que lorsque c'est absolument nécessaire. Un diaporama ou une lightbox peut être accessible sans ARIA.

Certains rôles ARIA font basculer les lecteurs d'écran dans un mode d'interaction différent. Il y a encore beaucoup d'utilisateurs qui ne sont pas habitués à cela et qui pensent alors qu'ils ont fait une fausse manœuvre ou que le site web réagit de façon anormale. Il faut en être conscient, mais en tant que développeur, la meilleure chose à faire est de suivre les standards. À force de rencontrer des widgets qui se comportent de manière identique et cohérente, ceux-ci vont se familiariser avec ce comportement.

Tester

ARIA est compatible avec tous les DOCTYPE, mais les outils de validation génèrent des erreurs pour les attributs ARIA parce que les DTD n'ont pas été mis à jour. Si vous utilisez le DOCTYPE HTML5 vous pouvez valider votre code avec le W3C Nu Markup Validation Service.

Quand vous utilisez ARIA il est important de tester avec plusieurs lecteurs d'écran et avec d'autres aides techniques car la raison d'être d'ARIA est d'améliorer l'expérience des utilisateurs qui utilisent ces aides techniques.

Souvenez-vous qu'ARIA n'influence pas l'interaction au clavier et que si vous avez utilisé ARIA vous aurez probablement aussi du coder en Javascript les interactions au clavier. Il faut donc tester également les widgets au clavier, sans lecteur d'écran, pour s'assurer qu'ils se comportent correctement.

En résumé

  • Les attributs ARIA vous permettent d'ajouter ou de modifier de l'information dans l'accessibility tree.
  • L'information qui se trouve dans l'accessibility tree n'est utilisée que par les lecteurs d'écrans et autres aides techniques utilisées par les personnes handicapées.
  • ARIA n'a aucun impact sur l'accessibilité pour les personnes qui n'utilisent pas ces aides techniques. Il faut donc tester l'accessibilité au clavier de toute façon, qu'ARIA soit utilisé ou pas.
  • S'il existe un élément HTML qui correspond à ce dont vous avez besoin, utilisez-le.
  • Un rôle ARIA ne modifie que la manière dont un composant est annoncé par un lecteur d'écran, pas son comportement. Celui-ci doit être programmé pour correspondre à ce qui est annoncé.
  • Quand vous utilisez un attribut role, c'est la valeur de cet attribut qui détermine le rôle de l'élément dans l'accessibility tree, quel que soit le rôle d'origine de l'élément. ARIA l'emporte.
  • Certains rôle ont des noms trompeurs. N'utilisez-pas role="menu" et "menuitem" pour des menus de navigation. Ces rôles sont destinés à être utilisés dans des menus applicatifs.
  • N'utilisez pas role="application"
  • Il vaut mieux ne pas utiliser ARIA du tout que de l'utiliser mal.
  • Les attributs ARIA sont utiles pour ajouter de l'information à destination des utilisateurs de lecteurs d'écran, mais il ne faut pas exagérer.

Sources