Composants interactifs accessibles : menus, fenêtres modales, onglets et accordéons
En bref — un composant interactif que tout le monde peut piloter
Le menu déroulant, la fenêtre modale (panier rapide, bandeau cookies, connexion), les onglets d'une fiche produit et les accordéons de FAQ sont parmi les composants les plus présents d'un e-commerce — et, quand ils sont codés « à la main » en <div>, parmi les plus inaccessibles. L'European Accessibility Act (norme EN 301 549 / WCAG 2.1 AA), applicable au commerce électronique depuis le 28 juin 2025, impose qu'ils soient utilisables par tous. Les points clés :
- Utiliser le HTML natif d'abord (
<button>,<details>,<dialog>), l'ARIA seulement en complément ; - Tout doit fonctionner au clavier, sans piège (critères 2.1.1 · 2.1.2) ;
- Rôle, nom et état doivent être exposés (
aria-expanded,role="dialog"…) (4.1.2) ; - Dans une modale, le focus est déplacé dedans, piégé, puis restitué ; Échap ferme (2.4.3 · 2.1.2) ;
- Menus et infobulles restent affichés et fermables au survol/focus (1.4.13).
La règle d'or : si un élément HTML natif fait le travail, utilisez-le — il apporte le clavier, le rôle et l'état gratuitement. L'ARIA ne corrige jamais un <div> mal choisi.
Un mega-menu qui ne s'ouvre qu'au survol de la souris, une fenêtre « Aperçu rapide » dont on ne peut pas sortir au clavier, un bandeau cookies qui ne donne jamais le focus à ses boutons, des onglets de fiche produit codés en <div> que le lecteur d'écran ignore : les composants interactifs « faits maison » sont la cause la plus fréquente — et la plus invalidante — des blocages d'accessibilité. Voici les six règles WCAG que l'EAA impose pour les menus, fenêtres modales, onglets et accordéons, et comment les vérifier.
Pourquoi ces composants posent problème
Un lien ou un bouton HTML natif arrive « équipé » : il est focusable au clavier, il a un rôle que le lecteur d'écran annonce, il réagit à Entrée et Espace. À l'inverse, un composant construit avec des <div> et du JavaScript ne possède aucune de ces propriétés par défaut : pour une souris il « marche », mais pour une personne au clavier ou au lecteur d'écran, il n'existe pas — ou pire, c'est un piège dont on ne sort plus.
C'est pourquoi la communauté résume la bonne pratique par la « première règle de l'ARIA » : si un élément HTML natif existe et fait l'affaire, utilisez-le plutôt que de réinventer un composant en <div> + ARIA. L'ARIA (rôles et attributs aria-*) sert à décrire des comportements que le HTML ne couvre pas — pas à rattraper un mauvais choix d'élément. L'EAA s'appuie sur l'EN 301 549, fondée sur les WCAG 2.1 niveau AA : les composants interactifs relèvent surtout du critère 4.1.2 (Nom, rôle, valeur), complété par 2.1.1 / 2.1.2 (clavier), 2.4.3 (ordre du focus) et 1.4.13 (contenu au survol ou au focus).
Les 6 règles pour des composants interactifs accessibles
Le bon élément apporte clavier, rôle et état gratuitement
Avant d'écrire du JavaScript, demandez-vous si un élément natif fait le travail : <button> pour une action, <a href> pour un lien, <details>/<summary> pour un accordéon simple, <dialog> pour une boîte modale, <select> pour un choix. Ces éléments sont focusables, annoncés et pilotables au clavier sans une ligne de code. Réservez l'ARIA aux motifs que le HTML ne couvre pas (onglets, menus arborescents, infobulles).
<details><summary>Question</summary>…</details> : ouvrable au clavier et annoncé « réduit / développé » nativement.<div onclick> : invisible au clavier, sans rôle, et qui oblige à rajouter tabindex, role et la gestion des touches à la main.→ Voir aussi liens et boutons accessibles.
Ouvrir, parcourir et fermer sans la souris
Chaque composant doit s'ouvrir, se parcourir et se fermer entièrement au clavier (critère 2.1.1) : Tab pour atteindre le déclencheur, Entrée ou Espace pour l'activer, Échap pour fermer. Et il ne faut jamais piéger le focus (2.1.2) : si l'utilisateur entre dans un composant au clavier, il doit pouvoir en sortir de la même façon. Un menu qui ne s'ouvre qu'au survol de la souris est inutilisable au clavier.
:hover de la souris : il n'apparaît jamais pour qui navigue au clavier.→ Voir aussi la navigation au clavier.
Le lecteur d'écran doit savoir ce que c'est et dans quel état
Pour chaque composant, le lecteur d'écran doit pouvoir annoncer ce que c'est (un bouton, un onglet, une boîte de dialogue), comment il s'appelle et dans quel état il se trouve. C'est l'objet du critère 4.1.2 : un bouton qui ouvre un panneau porte aria-expanded="true/false" ; un onglet actif aria-selected="true" ; un déclencheur indique ce qu'il commande via aria-controls. Sans cela, l'utilisateur ne sait pas si le menu est ouvert ou fermé.
<button aria-expanded="false" aria-controls="menu-compte">Mon compte</button> ; l'état passe à true à l'ouverture, annoncé « développé ».Entrer dedans, y rester, en sortir proprement
Une fenêtre modale (aperçu produit, connexion, bandeau cookies bloquant) demande un soin particulier : à l'ouverture, le focus se déplace dans la fenêtre ; tant qu'elle est ouverte, le focus reste piégé à l'intérieur (la navigation clavier ne doit pas repartir dans la page derrière) ; Échap et un bouton « Fermer » explicite la referment ; à la fermeture, le focus revient sur l'élément qui l'avait ouverte. La fenêtre porte role="dialog" (ou l'élément natif <dialog>) avec aria-modal="true" et un nom (aria-labelledby).
→ Voir aussi le tunnel de commande et les formulaires accessibles.
Survivre au pointeur et pouvoir être refermés
Un contenu qui apparaît au survol ou au focus (sous-menu, infobulle, aide contextuelle) doit respecter le critère 1.4.13 : il reste affiché tant qu'on le survole ou qu'il a le focus (on doit pouvoir amener le pointeur dessus sans qu'il disparaisse), il est refermable sans déplacer la souris ni le focus (par exemple avec Échap), et il ne masque pas brutalement le contenu sous-jacent. Cela évite les infobulles qui s'évanouissent dès qu'on tente de les lire.
Un comportement prévisible, un état annoncé
Pour les fiches produit à onglets (Description / Avis / Livraison) et les accordéons, l'utilisateur doit retrouver un comportement prévisible et un état clair. Le plus simple et le plus robuste : bâtir un accordéon sur des <button> portant aria-expanded, ou sur <details>/<summary>. Pour un vrai motif d'onglets ARIA (role="tablist"/tab/tabpanel), l'onglet actif porte aria-selected="true" et la navigation entre onglets se fait aux flèches. Évitez surtout de cacher du contenu indexable derrière un composant que ni le clavier ni le lecteur d'écran ne peuvent ouvrir.
aria-selected="true", chaque panneau est relié à son onglet, et tout est atteignable au clavier.<div> sans rôle : le lecteur d'écran ne sait pas qu'il s'agit d'onglets ni lequel est actif.Récapitulatif des critères pour les composants interactifs
| Point à vérifier | Niveau | Critère WCAG |
|---|---|---|
| Bon élément (HTML natif d'abord), rôle correct | A | 4.1.2 · 1.3.1 |
| Utilisable au clavier, pas de piège | A | 2.1.1 · 2.1.2 |
| Nom et état exposés (aria-expanded, aria-selected…) | A | 4.1.2 |
| Modale : focus déplacé, piégé puis restitué | A | 2.4.3 · 2.1.2 |
| Contenu au survol/focus persistant et refermable | AA | 1.4.13 |
| Focus visible sur chaque élément interactif | AA | 2.4.7 |
<dialog> fait l'essentiel de ce travail.
<div> cliquable en vrai bouton, n'ajoute pas la gestion du focus à vos modales et ne crée pas le motif clavier de vos menus — ce sont des choix de développement propres à votre boutique et à son thème. Rappel : la FTC américaine a sanctionné un éditeur d'overlay d'un million de dollars pour des allégations de conformité trompeuses. Voir pourquoi les overlays ne suffisent pas.Comment vérifier vos composants interactifs
Quelques tests rapides, à faire sur vos menus, vos modales (panier, aperçu, cookies), vos onglets de fiche produit et vos accordéons :
- Rangez la souris et naviguez au clavier : chaque composant s'ouvre-t-il, se parcourt-il et se ferme-t-il à Tab, Entrée/Espace et Échap ?
- Ouvrez une modale : le focus va-t-il dedans ? Reste-t-il piégé ? Revient-il au bon endroit à la fermeture ?
- Refaites le parcours au lecteur d'écran (NVDA, VoiceOver) : l'état « ouvert / fermé » et « onglet sélectionné » est-il annoncé ?
- Approchez le pointeur d'une infobulle ou d'un sous-menu : reste-t-il affiché ? Peut-on le fermer sans bouger la souris ?
- Vérifiez le focus visible : voit-on clairement où l'on se trouve à chaque étape ?
Un scan automatique repère une partie des problèmes (élément sans nom accessible, rôle ARIA incohérent, aria-* mal employé), mais la gestion du focus dans une modale et le comportement clavier d'un menu se vérifient surtout à la main, au clavier et au lecteur d'écran. Notre rapport signale les manquements détectables automatiquement et l'ensemble des autres points WCAG.
→ Méthode complète : comment tester l'accessibilité de son site. Voir aussi la structure des titres et les messages d'erreur de formulaire.
Vérifiez l'accessibilité de votre boutique gratuitement
DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 AA, repère les manquements (composants, contraste, structure, étiquettes…) et génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre client e-mail va s'ouvrir avec la demande pré-remplie — il vous suffit de l'envoyer.
Questions fréquentes
Faut-il toujours ajouter de l'ARIA à mes composants ?
Non, et c'est même l'inverse : la « première règle de l'ARIA » recommande d'utiliser un élément HTML natif (<button>, <a>, <details>, <dialog>, <select>) chaque fois qu'il fait le travail, car il apporte le clavier, le rôle et l'état sans code. L'ARIA sert à décrire les motifs que le HTML ne couvre pas (onglets, menus arborescents, infobulles). Une ARIA mal posée fait souvent plus de mal qu'une absence d'ARIA.
Comment rendre une fenêtre modale accessible ?
Quatre points : déplacer le focus dans la fenêtre à l'ouverture ; piéger le focus à l'intérieur tant qu'elle est ouverte (la navigation clavier ne doit pas repartir dans la page derrière) ; permettre la fermeture par Échap et par un bouton « Fermer » explicite ; redonner le focus à l'élément qui avait ouvert la fenêtre à la fermeture. Marquez-la role="dialog" aria-modal="true" avec un nom, ou utilisez l'élément natif <dialog> qui automatise une grande partie de ce comportement.
Mon bandeau cookies doit-il être accessible ?
Oui, et c'est prioritaire : un bandeau de consentement bloquant est souvent la première chose qui s'affiche et il peut empêcher d'accéder au reste du site. Il doit être atteignable au clavier, ses boutons (« Accepter », « Refuser », « Paramétrer ») doivent être de vrais boutons avec des libellés clairs, et s'il se comporte comme une modale, il doit gérer le focus comme une modale. Un bandeau cookies inaccessible bloque, de fait, tout votre site.
Un accordéon en <details>/<summary> est-il suffisant ?
Pour un accordéon simple (FAQ, blocs d'information), oui : <details>/<summary> est focusable, pilotable au clavier et son état « réduit / développé » est annoncé nativement, sans JavaScript ni ARIA. C'est souvent la solution la plus robuste. Pour des comportements plus riches (un seul panneau ouvert à la fois, navigation aux flèches), un motif sur <button aria-expanded> est possible, mais demande davantage de soin et de tests.
Le scan automatique détecte-t-il les composants inaccessibles ?
En partie. Un scan repère des signaux fiables : élément interactif sans nom accessible, attribut aria-* invalide ou incohérent, rôle mal employé. En revanche, il ne peut pas « cliquer » partout : savoir si une modale piège correctement le focus, si un menu s'ouvre au clavier ou si Échap referme bien se vérifie à la main, au clavier et au lecteur d'écran. Notre rapport combine le détectable automatiquement et la liste des points à contrôler manuellement.