Quand on parle de html tab en pratique, on parle surtout d’un motif d’onglets pour organiser plusieurs blocs de contenu dans un espace réduit. Le vrai sujet n’est pas seulement l’apparence : il faut aussi penser au balisage, au clavier, au focus et à l’accessibilité pour que l’interface reste fiable sur desktop comme sur mobile. Dans cet article, je vais aller droit au but avec une méthode claire, des exemples concrets et les erreurs que je vois le plus souvent sur ce type de composant.
Les points à retenir avant de coder un composant d’onglets
- Un composant d’onglets n’est pas un simple effet visuel, c’est un pattern d’interaction complet.
- La structure la plus solide repose sur
tablist,tabettabpanel. - Pour l’accessibilité, il faut gérer l’état actif, le masquage des panneaux et la navigation au clavier.
- Le W3C recommande un vrai comportement clavier, pas seulement un bloc caché/affiché au clic.
- Si le contenu est long, lourd ou très mobile-first, un accordéon peut être plus pertinent qu’un système d’onglets.
Quand les onglets sont le bon choix
Je réserve ce pattern aux situations où plusieurs contenus sont de même niveau et ne doivent pas être lus en même temps. C’est typiquement le cas d’une fiche produit, d’un tableau de réglages, d’un espace admin ou d’une page qui doit condenser des informations connexes sans noyer le lecteur sous une très longue colonne verticale.
Le piège, c’est de vouloir mettre des onglets partout. Dès que le contenu a besoin d’être comparé, partagé par section ou parcouru comme une lecture continue, les onglets deviennent moins naturels. En revanche, ils fonctionnent bien quand l’utilisateur vient chercher un seul bloc à la fois et veut changer rapidement de contexte sans quitter la page.
| Cas d’usage | Pourquoi les onglets aident | Point de vigilance |
|---|---|---|
| Fiche produit avec description, avis, livraison | Le contenu reste compact et lisible | Les panneaux trop longs fatiguent vite sur mobile |
| Interface de réglages | Chaque groupe d’options garde sa logique propre | Ne pas cacher des options critiques trop loin |
| Documentation interne | On évite de charger une page avec trop d’informations simultanées | Prévoir une navigation clavier solide |
| Dashboard métier | On sépare des vues très proches sans quitter la page | Les données lourdes peuvent provoquer un changement d’état lent |
Mon réflexe est simple : si le lecteur doit comparer des blocs, les onglets sont utiles ; s’il doit parcourir un récit ou une série de sections indépendantes, je commence déjà à regarder une autre solution. Cette distinction évite beaucoup de composants élégants en apparence, mais pénibles à l’usage.
La structure HTML qui reste maintenable
Le cœur du composant tient dans une structure sémantique claire. Le W3C traite ce pattern comme un vrai ensemble interactif, avec un conteneur pour les onglets, des onglets eux-mêmes et des panneaux associés. C’est plus robuste qu’un assemblage de div cliquables qui n’expliquent rien aux technologies d’assistance.
Je pars généralement d’un modèle basé sur des button pour les onglets, puis j’ajoute les rôles et attributs nécessaires. MDN rappelle d’ailleurs qu’une combinaison purement HTML/CSS ne remplace pas le comportement attendu d’un vrai composant accessible. Autrement dit, on peut maquiller l’interface, mais on ne peut pas improviser la logique.
Contenu visible par défaut.
Autre panneau de contenu.
Les attributs les plus importants sont faciles à retenir : role="tablist" pour le groupe, role="tab" pour chaque onglet, role="tabpanel" pour le contenu, aria-selected pour l’état actif, aria-controls et aria-labelledby pour relier les éléments. Si le panneau actif n’a pas d’élément focusable au début, je lui ajoute souvent tabindex="0" afin qu’il reste navigable au clavier sans bricolage.
En pratique, le bon balisage évite trois problèmes classiques : le lecteur d’écran ne sait pas quoi contrôler, le focus se perd, ou le contenu caché reste accessible au mauvais moment. C’est précisément là que la qualité du composant se joue, bien plus que dans la couleur de l’onglet actif.
Le comportement clavier qui fait la différence
Un composant d’onglets solide doit être utilisable sans souris. Le W3C recommande une navigation cohérente au clavier, avec des flèches pour passer d’un onglet à l’autre, puis Entrée ou Espace pour activer l’onglet si l’activation n’est pas automatique. Je considère ce point comme non négociable.
| Commande | Comportement attendu | Pourquoi c’est utile |
|---|---|---|
| Flèche droite / gauche | Déplace le focus vers l’onglet suivant ou précédent | Permet une exploration rapide du groupe |
| Flèche haut / bas | Même logique que droite / gauche en orientation verticale | Préserve une navigation cohérente selon la disposition |
Home |
Va au premier onglet | Raccourci pratique sur les listes longues |
End |
Va au dernier onglet | Évite plusieurs pressions successives |
Entrée / Espace
|
Active l’onglet sélectionné | Confirme l’action pour les modes à activation manuelle |
J’ajoute une nuance importante : l’activation automatique au survol du focus n’est pertinente que si le panneau s’affiche sans latence visible. Sinon, le déplacement devient agaçant, surtout quand il faut attendre le chargement d’un gros bloc de données ou d’images. Dans ces cas-là, je préfère un mode manuel, un peu moins “magique”, mais nettement plus stable.
Pour les onglets verticaux, je surveille aussi un détail souvent oublié : les flèches haut et bas prennent le relais, alors que les onglets horizontaux ne devraient pas détourner ces touches de leur comportement de défilement normal. Ce n’est pas un caprice de spécification, c’est ce qui rend l’interface prévisible au quotidien.
Les erreurs qui cassent l’expérience
La plupart des mauvais composants d’onglets ne sont pas “cassés” au premier regard. Ils fonctionnent visuellement, mais la logique interne est bancale. C’est plus gênant, parce que le défaut ne saute pas aux yeux immédiatement et finit souvent en bug d’accessibilité ou en retour utilisateur difficile à diagnostiquer.
- Utiliser un simple
divcliquable au lieu d’un vrai élément interactif. - Oublier de synchroniser
aria-selected,tabindexet l’affichage du panneau. - Masquer un panneau visuellement sans le retirer correctement de l’ordre de tabulation.
- Déplacer le focus vers le panneau au mauvais moment, ce qui casse la continuité de navigation.
- Ne pas afficher d’indicateur de focus visible.
- Réutiliser des
idambigus ou dupliqués, ce qui ruine la relation entre onglet et panneau.
Un autre piège fréquent concerne la pseudo-solution “HTML uniquement” basée sur des ancres et des contenus cachés. Pour de simples sections internes, ça peut dépanner, mais dès qu’on vise un vrai comportement d’onglets accessible, il manque une partie du contrat : état actif, focus, annonces par lecteur d’écran et logique clavier complète. C’est exactement le genre de raccourci qui paraît économique au début et coûte cher ensuite.
Je regarde aussi la performance. Si chaque onglet déclenche un chargement lourd, un recalcul massif ou une animation mal maîtrisée, l’interface perd son intérêt principal, à savoir la rapidité perçue. Un bon composant doit donner l’impression que le changement de vue est presque instantané.
Tabs, accordéon ou navigation secondaire
Tout n’a pas vocation à devenir un système d’onglets. Quand le contenu est long, très mobile-first ou amené à être partagé section par section, l’accordéon ou une navigation secondaire font souvent un meilleur travail. Je préfère décider tôt, avant que le composant ne soit déjà figé dans la maquette.
| Solution | Meilleur usage | Limite principale |
|---|---|---|
| Onglets | Blocs de contenu de même niveau, relativement courts | Peu pratique si les panneaux sont très longs |
| Accordéon | Sections verticales, lecture mobile, contenu extensible | Moins rapide pour comparer plusieurs blocs |
| Navigation secondaire | Sections qui méritent d’être ancrées ou partagées directement | Prend plus de place et change davantage la structure de page |
Dans une logique produit, je fais souvent ce choix très simplement : si les contenus ont la même importance et doivent rester dans le même espace, j’envisage les onglets ; si l’utilisateur doit dérouler beaucoup de matière, je bascule vers l’accordéon ; si chaque bloc mérite sa propre URL ou son propre ancrage, je m’éloigne du pattern d’onglets. C’est une règle pragmatique, pas une loi absolue, mais elle évite de forcer une interface là où elle ne rend pas service.
Le contrôle final qui évite les retours inutiles
Avant de livrer, je fais un test simple et concret. Je parcours le composant uniquement au clavier, je vérifie que le lecteur d’écran annonce bien l’onglet actif, je contrôle que le panneau caché ne perturbe pas la lecture et je teste le rendu sur un écran étroit. En 2026, un système d’onglets sans focus visible, sans navigation clavier fiable ou sans comportement cohérent sur mobile reste difficile à défendre.
- Le focus est toujours visible sur l’onglet actif.
- Les flèches déplacent le focus sans comportement bizarre.
- Le panneau visible correspond toujours à l’onglet sélectionné.
- Les panneaux inactifs ne polluent pas la navigation.
- Le changement d’onglet reste rapide, même avec du contenu un peu lourd.
Si je devais résumer la règle de fond, je dirais ceci : un bon composant d’onglets ne se juge pas seulement à son rendu, mais à la précision de sa mécanique. Quand le balisage, le clavier et l’état sont propres, l’interface devient discrète dans le bon sens du terme, et c’est souvent le meilleur signe d’un frontend bien construit.
