ARIA : quand l'utiliser, et surtout quand ne pas l'utiliser
ARIA est souvent présenté comme la solution magique de l'accessibilité, alors qu'un mauvais usage dégrade l'expérience plus qu'il ne l'améliore. La règle fondatrice est contre-intuitive : la meilleure utilisation d'ARIA, c'est souvent de ne pas l'utiliser. Ce guide explique à quoi sert vraiment ARIA, et comment éviter les erreurs les plus fréquentes.
La première règle de l'ARIA
La spécification WAI-ARIA énonce une première règle sans ambiguïté : si vous pouvez utiliser un élément HTML natif doté du rôle et du comportement dont vous avez besoin, faites-le plutôt que de détourner un autre élément avec ARIA. Un bouton natif gère déjà le focus clavier, l'activation par Entrée ou Espace et son rôle, là où un div auquel on ajoute role bouton n'apporte rien de tout cela gratuitement. ARIA ne modifie que ce que les technologies d'assistance perçoivent, jamais le comportement réel : il ne rend pas un élément focalisable ni cliquable au clavier. Le HTML natif reste donc toujours le premier choix.
À quoi sert réellement ARIA
ARIA a un vrai rôle quand le HTML natif atteint ses limites : composants riches sans équivalent natif (onglets, menus déroulants complexes, fenêtres modales), ou mises à jour dynamiques de contenu. Il fournit trois familles d'outils : les rôles, qui décrivent la nature d'un élément ; les propriétés, qui décrivent ses caractéristiques (par exemple un champ requis ou un lien vers une description) ; et les états, qui décrivent sa situation à l'instant T (déplié ou replié, sélectionné, masqué). Ces attributs comblent l'écart entre une interface JavaScript sur mesure et ce que doit annoncer un lecteur d'écran.
Les régions live pour le contenu dynamique
Un cas où ARIA est vraiment utile : signaler un changement de contenu sans rechargement de page, comme un message de confirmation ou une erreur de formulaire. L'attribut aria-live indique à la technologie d'assistance qu'elle doit annoncer la nouveauté ; la valeur polite attend une pause de l'utilisateur, assertive interrompt. C'est souvent la bonne réponse quand un contenu apparaît dynamiquement et passerait sinon totalement inaperçu pour une personne aveugle. Encore faut-il que la région existe dans le DOM avant la mise à jour.
Les pièges les plus courants
Le piège numéro un est l'ARIA redondant ou contradictoire : ajouter role bouton à une vraie balise bouton, ou un rôle qui ment sur la nature de l'élément. Vient ensuite l'ARIA cassé : un attribut aria-labelledby qui pointe vers un identifiant inexistant, ou un état aria-expanded jamais mis à jour par le JavaScript, ce qui désinforme l'utilisateur. Enfin, masquer du contenu avec aria-hidden tout en le laissant atteignable au clavier crée des éléments fantômes. Le dicton de la communauté résume tout : une ARIA absente vaut mieux qu'une mauvaise ARIA.
Testez l’accessibilité de votre site, gratuitement
Voyez en moins d'une minute où votre site rencontre ce type d'écart, gratuitement.
Lancer le diagnostic gratuitQuestions fréquentes
- ARIA rend-il un élément accessible au clavier ?
- Non, et c'est une confusion fréquente. ARIA ne change que l'information transmise aux technologies d'assistance, pas le comportement. Rendre un élément focalisable et activable au clavier reste votre responsabilité, via du HTML natif ou des attributs comme tabindex et des gestionnaires d'événements appropriés.
- Le RGAA impose-t-il d'utiliser ARIA ?
- Le RGAA n'impose pas ARIA pour lui-même : il impose un résultat accessible. ARIA est l'un des moyens admis pour y parvenir, notamment pour les composants d'interface (thématique 7) et certains formulaires, mais le HTML natif reste prioritaire chaque fois qu'il suffit.
- Quelle différence entre un rôle, un état et une propriété ARIA ?
- Le rôle décrit ce qu'est l'élément (une boîte de dialogue, un onglet). La propriété décrit une caractéristique stable (un champ obligatoire). L'état décrit une situation qui change pendant l'utilisation (déplié ou replié). États et propriétés s'écrivent avec le préfixe aria suivi de leur nom.
- Puis-je remplacer un input par un div avec des attributs ARIA ?
- Techniquement oui, mais c'est presque toujours une mauvaise idée. Vous devriez alors réimplémenter à la main le focus, la saisie, la validation et tous les comportements qu'un champ natif fournit gratuitement, avec un risque d'erreur élevé. Préférez l'élément natif.
- Comment vérifier que mon ARIA n'est pas cassé ?
- Il faut contrôler que chaque référence (aria-labelledby, aria-describedby) pointe vers un identifiant existant et que les états sont bien mis à jour par le JavaScript. Notre diagnostic gratuit détecte ces ARIA orphelins ou contradictoires, et un audit manuel vérifie le ressenti réel au lecteur d'écran.
Retour à tous les guides d'accessibilité.