ARIA - introduction

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 handicapées utilisent leur ordinateur (surtout les lecteurs d'écran).

Exemples de ce que les attributs ARIA peuvent faire

• améliorer l'accessibilité de composants (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: unselected.
• Propriété : focusable

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

Pour les 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. Les attributs ARIA peuvent aussi écraser des informations dans l'accessibility tree, et c'est pour celà qu'il faut les utriliser avec la plus grande prudence.

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.

Par exemple, pour un élément select le navigateur permet d'y accéder en utilisant le TAB, de sélectionner un élément en utilisant la flèche vers le bas, et d'atteindre rapidement une option en tapant la première lettre de cette option. Les utilisateurs connaissent ces modes d'interaction et peuvent les utiliser sans avoir besoin d'explications. Un lecteur d'écran annonce qu'il s'agit d'une liste déroulante.

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

<button>Pause</button>

<div onclick="..." class="boutonpause">Pause</div>

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.

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 peut parfois être ajouté au moyen d'un plugin.
• 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 composant. Vous y trouverez le comportement au clavier que vous devrez implémenter ainsi que les attributs ARIA à utiliser.
• Si vous utilisez des attributs ARIA, il faut vraiment bien vous renseigner. Un mauvais usage peut rendre un composant inutilisable.

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.

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 composants qui se comportent de manière identique et cohérente, les utilisateurs vont se familiariser avec ce comportement.

Tester

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. Il faut donc tester également votre interface au clavier, sans lecteur d'écran, pour s'assurer qu'ils se comporte 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

• Using WAI-ARIA in HTML
• What is WAI-ARIA, what does it do for me, and what not? (Marco's Accessibility Blog)
• The Accessibility Tree: A Training Guide for Advanced Web Development