Série RGAA en pratique · Épisode 6 · 5 min

ARIA : quand ne pas l’utiliser

No ARIA is better than bad ARIA. Pourquoi un bouton natif vaut mieux qu’une div avec role=button posée à la main, et quand ARIA devient vraiment nécessaire : boutons, accordéons, m…

Publié le 21 septembre 2026.Consulter la transcription de la vidéo Voir sur YouTube (nouvelle fenêtre)

Chapitres

Transcription

Texte intégral de la narration de l’épisode.

Situations du quotidien

Tu ajoutes un rôle de bouton sur une div, un aria-label par ci, un état ARIA par là, et tu penses avoir rendu ton composant accessible. Sauf qu’au clavier, rien ne bouge. Le lecteur d’écran annonce un bouton qui ne s’active pas. Un attribut ARIA ne rend pas un élément focusable, ne gère pas Entrée ou Espace, ne déclenche aucune action. Il décrit, il ne fait pas. Il existe un principe simple chez les gens qui font de l’accessibilité : pas d’ARIA vaut mieux qu’un mauvais ARIA.

Le natif d’abord, ARIA ensuite

La règle de base, c’est de partir du HTML natif quand il existe. Un bouton, un lien, un champ de saisie, une liste déroulante t’offrent déjà le rôle, le focus et la gestion clavier, sans une ligne de JavaScript. Tu ne sors ARIA que lorsque tu construis quelque chose que le HTML ne connaît pas : un système d’onglets, un accordéon, une arborescence. Et dans ce cas, ARIA décrit l’état, mais c’est toi qui dois câbler le focus, les touches et l’activation. Le RGAA regarde ça de près dans sa thématique Scripts.

Bouton natif vs div (rendu + code)

Regarde ces deux boutons à l’écran. À gauche, une div maquillée en bouton. À la souris, ça marche. Au clavier, le focus n’arrive pas dessus, ou alors Entrée ne fait rien. À droite, un vrai bouton natif : il prend le focus, il s’active à Entrée et à Espace, et le lecteur d’écran l’annonce correctement. En code, tout devient clair. Pour imiter un bouton avec une div, tu dois ajouter un rôle bouton, un tabindex pour le rendre focusable, un aria-label, un gestionnaire clic, et par-dessus un gestionnaire clavier pour Entrée et Espace, sans oublier le comportement au relâchement. Le bouton natif te donne tout ça d’origine. C’est exactement ce que visent le critère 7.1, la compatibilité avec les technologies d’assistance, et le critère 7.3, le contrôle au clavier.

ARIA utile : nommer une icône

ARIA n’est pas l’ennemi. Voici un cas où il est utile. Un bouton qui ne contient qu’une icône, une croix, une loupe, une corbeille, n’a aucun texte à annoncer. À gauche, le bouton est bien un bouton natif, mais il est muet pour le lecteur d’écran : l’utilisateur entend juste bouton, sans savoir ce qu’il fait. À droite, un aria-label clair, Fermer ou Rechercher, donne son nom au bouton. Ici, ARIA complète le natif au lieu de le remplacer. La différence avec le mauvais ARIA, c’est qu’on part d’un élément natif solide et qu’on ajoute juste l’information qui manque.

Accordéons, modales, onglets : le clavier se code

Pour les composants qui n’existent pas en natif, comme les onglets, les accordéons ou les modales, ARIA devient nécessaire. Mais il ne suffit jamais. D’abord le piège : une modale s’ouvre, on lui met bien un rôle de dialogue et un aria-modal, mais le focus reste sur la page derrière, et Échap ne ferme rien. Le lecteur d’écran annonce une boîte de dialogue dans laquelle on ne peut pas entrer. Ensuite le bon comportement : à l’ouverture, le focus entre dans la modale, il reste piégé dedans tant qu’elle est ouverte, Échap la ferme, et le focus revient sur le bouton qui l’avait ouverte. Les attributs ARIA annoncent l’état, mais c’est ton script qui doit déplacer et gérer le focus. C’est le sens des critères 7.1 et 7.3 réunis.

Accordéon : la div ne dit pas si c’est ouvert

Prends un accordéon. À gauche, l’en-tête est une div : le lecteur d’écran ne sait pas si le panneau est ouvert ou fermé, et le clavier ne l’active pas. À droite, un vrai bouton porte un aria-expanded synchronisé avec l’état réel : l’ouverture est annoncée, le focus fonctionne, et les critères 7.1 et 7.3 sont tenus. C’est le même réflexe que pour le bouton : natif solide d’abord, ARIA pour l’état qui manque.

Quand sortir ARIA, quand s’abstenir

Alors comment décider ? La question à te poser est simple : est-ce qu’un élément HTML natif fait déjà le travail ? Si oui, tu l’utilises, point. Recoder une case à cocher à la main, avec un span, un rôle ARIA et tout le clavier à gérer toi-même, c’est beaucoup de code pour reproduire ce qu’une case à cocher native fait gratuitement, et c’est beaucoup d’occasions de te tromper. Tu sors ARIA seulement quand aucun natif ne convient, et là tu assumes tout le comportement clavier qui va avec le rôle que tu déclares. La ligne à retenir : un rôle ARIA sans le comportement, c’est une promesse que ton composant ne tient pas. Un mauvais ARIA casse plus qu’il ne répare.

Checklist

Checklist, cinq réflexes. Premier réflexe : avant d’écrire le moindre attribut ARIA, demande-toi si un élément natif fait déjà le job. Deuxième réflexe : si tu construis vraiment un composant sur mesure, code le focus et les touches, ne te contente pas des attributs. Troisième, chaque rôle ARIA que tu déclares doit avoir son comportement câblé derrière. Quatrième, teste au clavier pour de vrai : Tab, Entrée, Espace, Échap. Et pour finir, branche un lecteur d’écran et écoute ce qui est réellement annoncé, pas ce que tu crois avoir écrit.

CTA

Fais le tour de tes composants d’interface. Traque les fausses commandes en div, les boutons muets, les rôles ARIA posés sans comportement. Rejoue chaque interaction au clavier seul. Pour analyser une page, repérer les signaux à corriger et prioriser, rends-toi sur rgaa-checker.com.

Approfondir dans le guide

Cet épisode aborde ces critères du RGAA 4.1.2. Ouvre leur fiche pour la méthode de test détaillée, les cas particuliers et les exemples.

D’autres épisodes qui abordent des critères proches, dans d’autres séries.

Navigation au clavier
Épisode 3Bases RGAA4 minEn ligne

Passer à l’action

La vidéo pose le cadre. Pour repérer des pistes d’amélioration sur un site réel, lance une analyse ou explore le guide des 106 critères.

Analyser un site Guide RGAA