# Bloc interactif accessible : focus, ARIA et navigation au clavier > Onglets, accordéons, carrousels : checklist concrète pour rendre un bloc interactif utilisable au clavier et par les technologies d'assistance, sans y passer des semaines. - Auteur : Clément Hadrot - Publié le : 2024-08-26 - Mis à jour le : 2024-08-26 - Catégorie : Blocs Gutenberg - URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/bloc-interactif-accessible-focus-aria-clavier/ ## L’essentiel - Chaque motif d'interface a un patron ARIA de référence à respecter - Le focus doit toujours être visible et suivre logiquement l'action - Les changements d'état s'annoncent, ils ne s'affichent pas que visuellement Trois blocs distincts développés pour trois clients différents, testés au clavier seul par un membre de l'équipe qui a volontairement débranché sa souris pendant une semaine : dans les trois cas, au moins un piège d'accessibilité empêchait purement et simplement l'utilisation du composant sans souris. Un onglet impossible à activer avec la touche Entrée, un accordéon qui ne changeait pas d'état pour un lecteur d'écran, un carrousel qui piégeait le focus sans possibilité d'en sortir. Cette checklist rassemble les points de contrôle qu'on applique désormais systématiquement avant de livrer un bloc interactif, quel que soit le motif d'interface concerné. Elle ne remplace pas un test utilisateur réel avec des personnes en situation de handicap, mais elle élimine la majorité des blocages évitables. ## Onglets (tablist / tab / tabpanel) Le patron ARIA de référence pour des onglets attend une structure précise : un conteneur `role="tablist"`, des boutons `role="tab"` avec `aria-selected` qui reflète l'onglet actif, et des panneaux `role="tabpanel"` reliés à leur onglet via `aria-controls` et `aria-labelledby`. - Un seul onglet du groupe est atteignable au tabulateur (`tabindex="0"`) ; les autres portent `tabindex="-1"` et se naviguent avec les flèches gauche/droite, pas avec Tab. - Le panneau actif seul reste dans l'ordre de tabulation ; les panneaux masqués portent `hidden`, pas seulement un style `display: none` en CSS sans attribut cohérent. - Activer un onglet au clavier (flèche ou Entrée selon le motif choisi) doit produire exactement le même résultat qu'un clic, sans délai ni double activation. ``` function activerOnglet( index ) { onglets.forEach( ( onglet, i ) => { const actif = i === index; onglet.setAttribute( 'aria-selected', actif ? 'true' : 'false' ); onglet.tabIndex = actif ? 0 : -1; } ); panneaux.forEach( ( panneau, i ) => { panneau.hidden = i !== index; } ); onglets[ index ].focus(); } ``` ## Accordéon Un accordéon accessible repose sur un simple bouton (` ``` > L'essentiel à retenir : Chaque motif d'interface a un patron ARIA de référence à respecter ; Le focus doit toujours être visible et suivre logiquement l'action ; Les changements d'état s'annoncent, ils ne s'affichent pas que visuellement ## Carrousel Le carrousel est historiquement le motif le plus problématique en accessibilité, au point que certaines équipes le déconseillent purement et simplement au profit d'une grille statique. S'il reste nécessaire, quelques règles non négociables : - Les boutons précédent/suivant ont un texte accessible explicite (`aria-label="Diapositive précédente"`), jamais une simple icône sans alternative textuelle. - Le défilement automatique se met en pause dès qu'un élément du carrousel reçoit le focus, et propose un bouton pause/lecture visible. - Le focus ne doit jamais être piégé à l'intérieur du carrousel : un utilisateur au clavier doit pouvoir tabuler pour en sortir normalement. - Chaque diapositive masquée hors champ visuel est retirée de l'ordre de tabulation, sinon le focus « saute » vers un contenu invisible à l'écran. ## Menu déroulant Un menu déroulant (navigation ou filtre) doit répondre à la touche Échap pour se fermer et rendre le focus à l'élément déclencheur, et à la touche flèche bas pour entrer dans la liste d'options depuis le bouton qui l'ouvre. L'état ouvert/fermé se communique via `aria-expanded` sur le bouton déclencheur, exactement comme pour l'accordéon. ### Annoncer les changements dynamiques Pour tout contenu qui change sans rechargement de page — un compteur de résultats filtrés, un message de confirmation — une zone `aria-live="polite"` (ou `role="status"` qui embarque cette sémantique) garantit que le changement est lu par les technologies d'assistance sans interrompre brutalement ce que l'utilisateur était en train de faire. Une zone `aria-live="assertive"` ne se réserve qu'aux messages réellement urgents, comme une erreur bloquante. ## Test rapide avant livraison Avant de considérer un bloc interactif comme terminé, l'équipe applique ce test en moins de cinq minutes : débrancher la souris, naviguer uniquement au clavier (Tab, Maj+Tab, flèches, Entrée, Espace, Échap), et vérifier que chaque action reste possible, que le focus reste visible en permanence (jamais de `outline: none` sans remplacement), et qu'aucun piège ne bloque la sortie d'un composant. > Un conseil qu'on répète en revue de code : si vous devez ajouter un attribut `role` ou `tabindex` à un élément qui n'en a pas nativement besoin, demandez-vous d'abord si un élément HTML natif (`button`, `details`, `summary`) ne ferait pas le travail tout seul, sans ARIA du tout. ## En résumé Ces quatre motifs — onglets, accordéon, carrousel, menu déroulant — couvrent l'immense majorité des blocs interactifs développés pour des sites vitrine ou e-commerce. Respecter leur patron ARIA de référence, garder un focus visible et cohérent, et annoncer les changements d'état plutôt que de se contenter de les afficher visuellement : ces trois réflexes évitent la grande majorité des blocages rencontrés lors de nos audits terrain.