Modale, accordéon, onglets : le clavier se code
Les composants riches (modale, accordéon, système d’onglets) n’existent pas en HTML natif : leur rôle, leur état et leur comportement clavier sont à coder.
Chapitres
- 0:00Situations du quotidien (nouvelle fenêtre, YouTube)
- 0:33Le clavier et le rôle se codent (nouvelle fenêtre, YouTube)
- 1:12Le focus entre, reste, puis revient (nouvelle fenêtre, YouTube)
- 2:02Un bouton qui annonce ouvert ou fermé (nouvelle fenêtre, YouTube)
- 2:50Quand un composant s’ouvre, l’ordre doit tenir (nouvelle fenêtre, YouTube)
- 3:27role tablist, flèches, aria-selected (nouvelle fenêtre, YouTube)
- 4:13Checklist (nouvelle fenêtre, YouTube)
- 4:57CTA (nouvelle fenêtre, YouTube)
Transcription
Texte intégral de la narration de l’épisode.
Situations du quotidien
Modale, accordéon, système d’onglets : ces composants, tu les vois partout, et ils sont souvent superbes à la souris. Le problème arrive au clavier et au lecteur d’écran. La modale s’ouvre, mais le focus reste derrière elle et la touche Échap ne la ferme pas. L’accordéon se déplie, mais rien n’annonce s’il est ouvert ou fermé. Les onglets s’affichent, mais les flèches du clavier ne font rien. Le point commun : le HTML ne connaît pas ces composants en natif. Donc leur comportement clavier et ce qu’ils annoncent aux technologies d’assistance, ce n’est pas fourni, c’est à toi de le coder.
Le clavier et le rôle se codent
Deux critères de la thématique Scripts encadrent ces composants. Le critère 7.1 demande qu’un composant piloté par script expose son nom, son rôle et son état aux technologies d’assistance : le lecteur d’écran doit pouvoir dire, ceci est une boîte de dialogue, ceci un panneau replié, cet onglet est sélectionné. Le critère 7.3 exige que tout soit contrôlable au clavier, pas seulement à la souris. Et le principe à garder en tête : les attributs ARIA décrivent un état, mais ils ne font rien. aria-expanded ne déplie pas ton accordéon, role dialog ne piège pas le focus. Le comportement, c’est ton script qui doit l’écrire.
Le focus entre, reste, puis revient
Commençons par la modale. D’abord le piège : à gauche, la boîte s’ouvre visuellement, mais le focus reste sur la page derrière. Tu tabules, et tu te retrouves à parcourir le contenu masqué sous la modale, sans jamais entrer dedans. Et Échap ne ferme rien. À droite, le comportement attendu, en quatre temps. Un, à l’ouverture, le focus entre dans la modale. Deux, il y reste piégé tant qu’elle est ouverte : Tab tourne en boucle à l’intérieur, sans fuir derrière. Trois, la touche Échap la ferme. Quatre, le focus revient sur le bouton qui l’avait ouverte. Côté code, tu déclares role dialog et aria-modal vrai pour le rôle, et un nom accessible via aria-labelledby. Mais le rôle seul ne suffit pas, ce ballet du focus, il faut l’écrire. C’est le sens des critères 7.1 et 7.3 réunis.
Un bouton qui annonce ouvert ou fermé
L’accordéon, maintenant. À gauche, l’en-tête est une div avec un chevron et un gestionnaire de clic. À la souris ça se déplie, mais le clavier ne l’active pas, et surtout rien n’indique au lecteur d’écran si le panneau est ouvert ou fermé. À droite, l’en-tête est un vrai bouton, idéalement porté par un titre. Ce bouton reçoit le focus, s’active à Entrée et à Espace, et il porte un attribut aria-expanded qui vaut vrai quand le panneau est ouvert, faux quand il est fermé. Le point crucial, c’est la synchronisation : chaque fois que l’état change, tu mets à jour aria-expanded en même temps. Un aria-expanded figé qui ment sur l’état, c’est pire que pas d’ARIA du tout. Là encore, 7.1 pour l’état annoncé, 7.3 pour le clavier.
Quand un composant s’ouvre, l’ordre doit tenir
Un mot sur l’ordre du clavier, parce que ces composants insèrent souvent du contenu à la volée. À gauche, la tabulation part dans le désordre : le focus saute du premier champ au troisième, puis revient au deuxième. À droite, il suit l’ordre de lecture, proprement. La règle : quand ton script ouvre un panneau, révèle un menu ou insère un champ, le nouvel élément doit prendre sa place logique dans le parcours clavier, juste après celui qui l’a déclenché, sans renvoyer l’utilisateur au hasard. C’est le critère 12.8 sur l’ordre de tabulation, et ça va de pair avec le contrôle clavier du 7.3. Évite les tabindex positifs, garde l’ordre du DOM aligné sur l’ordre visuel.
role tablist, flèches, aria-selected
Terminons par les onglets, qui n’ont pas de démo dédiée mais un motif ARIA bien établi. À gauche, la version cassée : des div cliquables, sans rôle ni état, injouables au clavier. À droite, le motif attendu. Le conteneur porte role tablist. Chaque onglet est un bouton avec role tab, un attribut aria-selected qui indique l’onglet actif, et un aria-controls qui pointe vers son panneau. Chaque panneau porte role tabpanel. Côté clavier, la convention est précise : la touche Tab entre dans le groupe d’onglets et en sort, tandis que les flèches gauche et droite passent d’un onglet à l’autre. Ce comportement aux flèches, ce n’est pas automatique, c’est du script à écrire, exactement ce que visent les critères 7.1 pour les rôles et 7.3 pour le clavier.
Checklist
Récapitulons en cinq réflexes. Un, chaque composant sur mesure doit exposer son nom, son rôle et son état aux technologies d’assistance : c’est le critère 7.1. Deux, tout ce qui se fait à la souris doit se faire au clavier, sans exception : critère 7.3. Trois, pour une modale, piège le focus dedans, ferme sur Échap, et rends le focus au bouton d’origine. Quatre, pour un accordéon, utilise un vrai bouton et synchronise aria-expanded avec l’état réel du panneau. Et cinq, pour des onglets, applique le motif role tablist, expose l’onglet actif avec aria-selected, et code la navigation aux flèches. Le fil rouge : ARIA annonce, ton clavier agit.
CTA
À toi de jouer. Prends tes composants interactifs et rejoue-les au clavier seul. La modale piège-t-elle le focus et se ferme-t-elle à Échap ? L’accordéon annonce-t-il son état ? Les onglets répondent-ils aux flèches ? Un scan automatique repère certains signaux, comme un rôle manquant, mais le test clavier reste irremplaçable. Pour analyser une page et repérer les composants à revoir, 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.
Vidéos liées
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.
