ARIA - l'attribut role

Lisez d'abord l'introduction à ARIA.

L'attribut ARIA role définit le rôle d'un élément dans l'accessibility tree. On peut l'ajouter à tout élément HTML mais ce n'est pas toujours une bonne idée. 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émantique

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:

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

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:

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

Il faut être très prudent en ajoutant un attribut role. 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 voient un titre de niveau 1, mais visuellement rien n'a 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 de type landmark qui permettent de baliser les différentes régions d'une page. Ils sont en grande partie superflus depuis l'arrivée des éléments sectionnants en HTML5. 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é.

Dans l'accessibility tree, les éléments ont égalemnt un nom, des statuts et des propriétés.