Rôle ARIA
Un rôle ARIA indique aux technologies d'assistance ce qu'est un élément d'interface : bouton, onglet, alerte, zone de navigation. Les balises HTML sémantiques portent déjà un rôle implicite. L'attribut role n'est nécessaire que pour les composants absents du HTML natif, comme les onglets ou les menus déroulants.
Votre HTML contient déjà des rôles. Un <button> est annoncé «\u00a0bouton\u00a0». Un <nav> est annoncé «\u00a0navigation\u00a0». Le navigateur construit un arbre d'accessibilité à partir du DOM, et chaque balise sémantique y porte un rôle implicite. L'attribut role n'entre en jeu que lorsque ce mécanisme automatique ne suffit pas.
#Ce que le navigateur fait sans vous
Chaque élément HTML sémantique est exposé dans l'arbre d'accessibilité avec un rôle que les technologies d'assistance consomment directement\u00a0:
| Balise HTML | Rôle implicite |
|---|---|
<button> | button |
<a href="..."> | link |
<nav> | navigation |
<main> | main |
<input type="checkbox"> | checkbox |
<h1> à <h6> | heading |
Un <div> ou un <span> n'a aucun rôle\u00a0: il retourne null dans l'arbre d'accessibilité (MDN Web Docs). Le lecteur d'écran l'ignore ou annonce son contenu textuel sans contexte.
Quand vous construisez un composant qui n'existe pas en HTML natif, l'attribut role déclare sa nature\u00a0:
<div role="tablist">
<button role="tab" aria-selected="true">Détails</button>
<button role="tab" aria-selected="false">Avis</button>
</div>
<div role="tabpanel">Contenu de l'onglet sélectionné</div>La spécification WAI-ARIA 1.2 définit environ 80 rôles. Les motifs de conception du W3C APG documentent pour chacun le comportement clavier, les états requis et la structure attendue.
#Poser un rôle, c'est signer un contrat
La première règle de la spécification ARIA in HTML\u00a0: si un élément HTML natif avec la sémantique voulue existe, utilisez-le. Pas de role.
Un <div role="button"> annonce «\u00a0bouton\u00a0» au lecteur d'écran. Mais il ne reçoit pas le focus clavier. Les touches Entrée et Espace ne déclenchent rien. La soumission de formulaire ne fonctionne pas. Le lecteur d'écran promet un bouton. Le clavier ne livre rien. C'est un mensonge accessible.
Le rapport WebAIM Million le confirme à grande échelle\u00a0: les pages utilisant ARIA comptent en moyenne 41 % d'erreurs d'accessibilité de plus que les pages sans ARIA.
Trois pièges reviennent constamment\u00a0:
- Rôle sans clavier.
role="button"sans gestion dekeydownpour Entrée et Espace. - Redondance.
<nav role="navigation">double une information que le navigateur fournit déjà nativement. - Rôle modifié en cours de route. La spécification interdit de changer un rôle après le rendu. Un
tabreste untab.
#En résumé
HTML sémantique d'abord\u00a0: vos balises portent déjà les rôles dont les lecteurs d'écran ont besoin. L'attribut role ne sert que pour les composants absents du HTML natif. Et chaque rôle posé exige son comportement clavier et ses états ARIA synchronisés. Les motifs du W3C APG sont votre référence.