Accueil / Articles / De la soupe de div à un marquage significatif : Un guide pratique sur l’HTML sémantique

HTMLAccessibilitySEOWeb StandardsFrontend

De la soupe de div à un marquage significatif : Un guide pratique sur l’HTML sémantique

Découvrez pourquoi les divs génériques compromettent l’accessibilité, le crawlage et la maintenabilité, quels éléments sémantiques utiliser à la place, ainsi que comment refactorer un véritable composant de type carte.

3527 mots

Ouvrez l’inspecteur d’éléments dans une application web moderne typique et vous verrez souvent la même image : une pile profonde et anonyme d’éléments <div>, chacun identifié uniquement par un nom de classe. La page peut paraître parfaite, mais pour les lecteurs d’écran, les robots de recherche et le prochain développeur de l’équipe, elle ne dit presque rien sur la nature du contenu. Ce guide explique quelles en sont les conséquences pour vous, quels éléments sémantiques remplacent la plupart de ces divs, comment trancher entre les choix déroutants (<article> ou <section>, lien ou bouton), et comment refactoriser progressivement un composant réel.

Voici le modèle sous sa forme la plus pure : un en-tête, une navigation, du contenu principal et un pied de page, tous exprimés sous forme de boîtes génériques.

<!-- The modern web's favorite anti-pattern -->
<div class="header">
  <div class="nav-container">
    <div class="nav-item">Home</div>
    <div class="nav-item">About</div>
  </div>
</div>
<div class="main-content">
  <div class="article-title">Stop Using Divs</div>
  <div class="article-body">
    <div class="paragraph">Divs everywhere.</div>
  </div>
</div>
<div class="footer">
  <div class="copyright">© 2026</div>
</div>

Toute élément de structure dans cet extrait se trouve dans les noms de classe. En supprimant ces classes, il ne reste plus rien pour indiquer à une machine ou à une personne où s’arrête la navigation et où commence l’article. Ce style est généralement appelé « div soup », et il est bien plus répandu qu’il ne le devrait.

Pourquoi HTML est devenu un squelette de stylisation

Avec la domination des frameworks tels que React, Vue, Angular et Svelte dans le développement frontend, ainsi qu’avec le CSS axé sur les outils qui rend la stylisation presque automatique, le markup a progressivement perdu sa fonction initiale. HTML a commencé à servir de cadre neutre sur lequel accrocher des classes et des gestionnaires d’événements, plutôt que de langage permettant de décrire du contenu. C’est une mauvaise interprétation de la plateforme : HTML a été conçu pour exprimer du sens, et non pour servir de moteur de mise en page.

Lorsque ce sens disparaît, les dommages se répandent simultanément dans plusieurs domaines. La technologie d’assistance perd ses outils de navigation, les moteurs de recherche reçoivent des informations moins précises sur ce qui est important sur la page, le navigateur ne peut plus fournir de fonctionnalités intégrées, et la base de code devient plus difficile à lire pour les collègues. Aucun de ces problèmes n’est visible sur une capture d’écran, et c’est précisément pour cette raison qu’ils persistent.

Les racines des composants sont par défaut des div

L’architecture des composants divise l’interface en petits éléments tels que <Button/>, <Card/>, <Navbar/> et <Sidebar/>. Chaque composant nécessite un élément racine pour son JSX, et le choix le plus simple est <div>. En empilant plusieurs composants les uns à l’intérieur des autres, le DOM généré se compose de dix couches d’éléments d’enveloppe anonymes, bien que chaque composant pris individuellement paraisse raisonnable. (Si vous travaillez avec React, il est utile de se rappeler qu’un fragment élimine complètement le besoin d’un élément d’enveloppe lorsque aucune boîte n’est requise.)

Les classes utilitaires orientent l’attention sur l’apparence

Le CSS axé sur les fonctionnalités est excellent pour la vitesse, mais il concentre toute l’attention sur l’apparence d’un élément. Lorsque le code s’écrit <div class="flex items-center space-x-4">, la question qui se pose est « comment est-ce agencé ? », tandis que la question « qu’est-ce que c’est ? » n’est jamais posée. Le choix de l’élément devient une considération secondaire.

Les pixels ne représentent que la couche supérieure

La habitude la plus dangereuse est de juger son travail en se basant sur ce que voit un utilisateur avec une souris sur un grand écran. Un <div> avec un arrière-plan bleu, des coins arrondis et du texte en gras ressemble certainement à un bouton. Mais en dehors des pixels affichés, il y a le DOM, l’arbre d’accessibilité que le navigateur met à disposition pour les technologies d’assistance, la vue du moteur de recherche sur le document ainsi que le traitement des entrées par le navigateur. Pour chacune de ces couches, le div stylisé reste simplement un div.

Que signifie réellement l’HTML sémantique

Le terme « sémantique » fait référence au sens. L’HTML sémantique consiste à choisir des éléments dont les noms décrivent le rôle du contenu qu’ils contiennent, afin que le navigateur, les technologies d’assistance et les lecteurs humains puissent tous comprendre le document sans deviner.

Conteneurs génériques

Deux éléments sont délibérément dénués de sens :

  • <div> est un agrégateur de niveau bloc générique.
  • <span> est un agrégateur en ligne générique.

Le texte à l’intérieur d’un <div> peut être un titre de page, un lien de navigation, un paragraphe d’un article de blog, une note dans une barre latérale ou une clause de non-responsabilité légale. Le navigateur ne peut pas le distinguer, il les traite donc tous de la même manière.

Éléments qui portent un sens

Les éléments sémantiques indiquent de quoi est composé leur contenu :

  • <header> contient le contenu introductif de la page ou d’une section, incluant souvent des éléments de navigation.
  • <nav> désigne un bloc de liens de navigation principaux.
  • <main> entoure le contenu principal et unique de la page.
  • <article> représente une composition autonome telle qu’un article ou une nouvelle.
  • <section> regroupe du contenu autour d’un thème unique.
  • <aside> contient des éléments seulement indirectement liés au contenu principal, comme une barre latérale.
  • <footer> affiche des informations de finition telles que les crédits, les droits d’auteur ou des liens juridiques.
  • <button> est un contrôle interactif qui exécute une action.

Lorsque le navigateur rencontre un <article>, il sait que son contenu peut exister indépendamment. Lorsqu’il rencontre un <nav>, il sait que ces liens permettent aux utilisateurs de se déplacer sur le site. C’est cette connaissance qui sert de base au reste de ce guide.

Quatre raisons pour lesquelles l’encodage sémantique vaut la peine

Choisir le bon élément nécessite un instant de réflexion, et un div stylisé affiche les mêmes pixels. Les avantages se manifestent à quatre niveaux.

Accessibilité : points de repère et contrôles natifs

Beaucoup de personnes utilisent le Web avec des lecteurs d’écran tels que NVDA, JAWS ou VoiceOver, ou naviguent entièrement à l’aide du clavier. Les lecteurs d’écran ignorent votre CSS ; ils fonctionnent à partir de l’arbre d’accessibilité que le navigateur déduit de votre HTML.

Avec un marquage bien structuré, le navigateur peut identifier des points de repère, et les technologies d’assistance peuvent les présenter sous forme de liste que l’utilisateur peut parcourir. Pour une page sémantique, cette liste ressemble à peu près à ceci :

Landmark Navigation Map:
- Header
- Navigation (3 links)
- Main Content
  - Heading 1: Stop Using Divs
  - Article
- Sidebar (Aside)
- Footer

Un utilisateur peut appuyer sur une seule touche de raccourci pour sauter des dizaines de liens de navigation et arriver directement dans <main>, ou se rendre directement à l’article. Comparez maintenant la même page construite uniquement à partir de divs :

Landmark Navigation Map:
- Division
  - Division
  - Division
- Division

En pratique, c’est encore pire que ce schéma ne le suggère : les divs ordinaires ne constituent absolument pas de points de repère, donc la liste est simplement vide. L’utilisateur doit parcourir l’élément de page un par un pour trouver ce qu’il est venu chercher.

Les boutons présentent le même problème à une échelle plus réduite. Voici un bouton fictif à côté d’un vrai :

<!-- BAD: Fake Button -->
<div class="my-button" onclick="submitForm()">Submit</div>

<!-- GOOD: Native Button -->
<button type="submit">Submit</button>

Le <button> natif inclut, sans aucun coût supplémentaire :

  • La capacité à recevoir le focus, ce qui lui permet d’apparaître dans l’ordre Tab.
  • Activation possible avec Entrée et Espace.
  • Un rôle correct, de sorte que le lecteur d’écran annonce quelque chose comme « Soumettre, bouton » et que l’utilisateur sait qu’une action est exécutée.

    • La version div ne peut pas recevoir le focus, ne répond pas au clavier et est lue comme du texte brut, sans indication qu’elle soit interactive. Pour qu’elle se comporte correctement, il faudrait tabindex="0", role="button", des gestionnaires de touches pour Entrée et Espace, un stylage pour le focus ainsi qu’un traitement de l’état désactivé. Cela représente beaucoup de code pour reproduire, généralement de manière imparfaite, ce que la plateforme fournit déjà.

    Moteurs de recherche : une vision plus claire de la page

    Des outils d’exploration tels que Googlebot sont, en quelque sorte, des lecteurs de texte spécialisés qui tentent de comprendre de quoi traite chaque page. La structure sémantique leur fournit des indications utiles :

    • <h1> indique le sujet principal.
    • <main> sépare le contenu unique du en-tête et du pied de page qui se répètent sur chaque page.
    • <article> marque un élément de contenu éditorial distinct.
    • <nav> affiche la structure des liens internes.

    Une page composée de divs non différenciés oblige le robot de recherche à déduire tout cela uniquement à partir du layout et du texte. Soyez cependant réaliste quant à l’ampleur de cet effet : le balisage n’est qu’un des nombreux facteurs, et les moteurs de recherche ne publient aucune règle stipulant que les pages sémantiques ont toujours la priorité. Considérez une structure claire comme un élément qui facilite l’analyse et l’indexation de votre contenu, et non comme une garantie de classement.

    Gestionnable : un balisage qui se documente lui-même

    Le code constitue un moyen de communiquer avec d’autres développeurs ainsi qu’avec soi-même des mois plus tard. Prenons en compte deux versions du même layout. La première repose entièrement sur des noms de classes :

    <div class="top-bar">
  <div class="logo-box">...</div>
  <div class="menu-list">
    <div class="menu-item"><a href="#">Home</a></div>
    <div class="menu-item"><a href="#">Blog</a></div>
  </div>
</div>
<div class="wrapper">
  <div class="content-box">
    <div class="title-text">My Post</div>
    <div class="body-text">Hello world...</div>
  </div>
  <div class="right-bar">
    <div class="widget">...</div>
  </div>
</div>
<div class="bottom-bar">
  <div class="legal">© 2026</div>
</div>

    La seconde exprime la même structure à l’aide d’éléments sémantiques :

    <header>
  <div class="logo">...</div>
  <nav>
    <ul>
      <li><a href="#">Home</a></li>
      <li><a href="#">Blog</a></li>
    </ul>
  </nav>
</header>
<main>
  <article>
    <h1>My Post</h1>
    <p>Hello world...</p>
  </article>
  <aside>
    <div class="widget">...</div>
  </aside>
</main>
<footer>
  <small>© 2026</small>
</footer>

    Dans la première version, il faut lire chaque nom de classe pour en comprendre l’intention. Si quelqu’un omet ou donne un mauvais nom à une classe, la structure se transforme en un mur de boîtes identiques. Dans la seconde version, la forme de la page est visible d’un coup d’œil : où elle commence (<header>), où se trouve le contenu principal (<main>), ce qui est supplémentaire (<aside>) et où elle se termine (<footer>). On remarque également que la navigation devient une véritable liste, ce qui permet aux lecteurs d’écran d’indiquer le nombre d’éléments qu’elle contient.

    Les balises auto-descriptives réduisent la charge mentale lors des revues et diminuent le risque de dysfonctionnements lorsque le layout change.

    Prestations et comportement intégré des navigateurs

    Les moteurs de navigation tels que Chromium, Gecko et WebKit sont optimisés pour les éléments standards, qui disposent déjà de styles par défaut, de gestion des événements et de mécanismes de gestion d’état intégrés. Les contrôles de formulaire en sont l’exemple le plus évident : <input type="email"> et <input type="date"> fournissent aux utilisateurs mobiles un clavier adapté à l’écran ou un sélecteur de date natif, tandis que <details> offre un widget de révélation fonctionnel, tout cela sans aucun JavaScript tiers.

    Chaque fois que vous reconstruisez un menu déroulant ou un bouton à partir d’un div accompagné de scripts, vous envoyez du code supplémentaire sur le réseau, augmentez la taille du paquet de données, consommez davantage des ressources CPU et de la batterie du dispositif, et créez un autre composant que vous devez ensuite entretenir et tester. Pour en savoir plus sur cette idée, consultez six fonctionnalités natives d’HTML qui remplacent les bibliothèques UI JavaScript courantes.

    Résoudre les choix sémantiques complexes

    Connaître la liste des éléments est la partie facile. La véritable confusion provient de quelques paires qui semblent interchangeables.

    article ou section

    C’est la question sur laquelle les développeurs débattent le plus. Un test utile : ce contenu pourrait-il être extrait de la page, placé sur un site différent et rester tout à fait compréhensible ? Si c’est le cas, utilisez <article>. S’il n’a de sens que dans son contexte actuel, utilisez <section>.

    Exemples appropriés pour <article> :

    • Un article de blog ou une nouvelle.
    • Un commentaire unique d’utilisateur.
    • Une fiche produit dans un tableau de magasin.
    • Un widget autonome, comme un panneau météo en direct.

    Chacun de ces éléments peut être diffusé, intégré dans un flux d’actualités ou inséré ailleurs sans la page qui l’entoure.

    Exemples appropriés pour <section> :

    • Le bloc « À propos de nous » d’une page d’accueil.
    • Un chapitre au sein d’un livre numérique.
    • L’aire présentant les fonctionnalités d’une page de destination.
    • Un groupe de témoignages.

    <section> regroupe du contenu autour d’un thème donné, il convient donc presque toujours qu’elle commence par un titre allant de <h2> à <h6>. Si vous ne parvenez pas à trouver un titre approprié, il s’agit probablement pas d’une section, et un <div> serait alors le choix plus judicieux.

    Ces deux éléments s’emboîtent naturellement. Un article peut être divisé en sections, chacune ayant son propre titre :

    <!-- Proper Nesting Example -->
<main>
  <!-- Main article describing a topic -->
  <article>
    <h1>Understanding Semantic HTML</h1>
    <p>Introductory paragraph...</p>

    <!-- Sections dividing the article into sub-topics -->
    <section>
      <h2>Why Accessibility Matters</h2>
      <p>Content about accessibility...</p>
    </section>

    <section>
      <h2>SEO Benefits</h2>
      <p>Content about SEO...</p>
    </section>
  </article>
</main>

    Lien ou bouton

    Mélanger liens et boutons est l’un des bugs d’accessibilité les plus fréquents. La règle est simple :

    • Utilisez <a> avec un véritable href lorsque son activation modifie l’URL ou dirige l’utilisateur vers une autre page ou un autre emplacement.
    • Utilisez <button> lorsque son activation effectue une action sur la page actuelle : envoie des données, ouvre un modal, active/désactive un menu ou modifie d’une autre manière l’état de la page.

    Ces deux types d’erreurs sont fréquents, tout comme leurs correctifs :

    <!-- WRONG: A link styled like a button that triggers JavaScript -->
<a href="#" onclick="openModal()">Open Modal</a>

<!-- WRONG: A button that navigates to a new webpage -->
<button onclick="window.location.href='/about'">About Us</button>

<!-- RIGHT -->
<button type="button" onclick="openModal()">Open Modal</button>
<a href="/about">About Us</a>

    La distinction est importante car les lecteurs d’écran annoncent le rôle du texte. « Link » crée l’attente qu’une page différente sera affichée ; « button » suggère qu’un événement se produira ici. Une erreur dans ce choix brise cette attente. Il existe également des effets secondaires pratiques : un lien avec href="#" peut faire défiler la page en haut et ne peut pas être activé avec l’espace, tandis qu’un bouton de navigation ne peut pas s’ouvrir dans une nouvelle fenêtre ni avoir son adresse copiée.

    Créer une structure de titres pertinente

    Les titres forment le sommaire de votre page, et à la fois les technologies d’assistance et les robots de recherche s’y appuient. Les utilisateurs de lecteurs d’écran naviguent souvent uniquement à l’aide des titres. Quelques règles permettent de maintenir cette structure utile :

    • Utilisez un seul <h1> pour le sujet principal de la page, comme le titre de l’article ou le nom du tableau de bord. La spécification HTML ne l’interdit pas strictement, mais une seule en-tête de niveau supérieur est la convention fortement recommandée et offre le plan le plus clair.
    • N’omettez pas les niveaux. Passer directement de <h2> à <h4> parce que vous souhaitez un texte plus petit est une décision de mise en forme déguisée en structure ; modifiez plutôt la taille du texte avec CSS.
    • Nestez de manière logique : sous le titre <h1> se trouvent des sections principales <h2>, chacune contenant ses propres sous-sections <h3>, suivies du prochain <h2>.

    Notez également que l’élément <header> et les éléments de titre sont des choses différentes. Un <header> représente une région de la page ; <h1> à <h6> sont les titres qui constituent l’arborescence du contenu.

    Lorsqu’un div est l’outil approprié

    Rien de tout cela ne signifie que <div> est interdit. Il a une fonction légitime : entourer du contenu uniquement dans le but d’organiser la mise en page ou de gérer les styles lorsque aucune signification sémantique n’est requise. Centrer un élément avec flexbox, créer des espacements dans une grille, appliquer un arrière-plan dégradé ou activer une animation CSS sont autant de raisons valables d’utiliser un <div> (ou un <span> pour du contenu en ligne).

    Dans la carte suivante, les parties ayant une signification utilisent des éléments sémantiques, tandis qu’un seul div existe uniquement pour disposer deux boutons côte à côte :

    <!-- PERFECTLY VALID USE OF A DIV -->
<article>
  <h1>Card Title</h1>
  <p>Card description goes here...</p>

  <!-- This div exists purely to align two buttons side-by-side with Flexbox -->
  <div class="button-group flex gap-4 mt-4">
    <button type="button">Save</button>
    <button type="button">Cancel</button>
  </div>
</article>

    Les éléments <article>, <h1>, <p> et <button> décrivent le contenu ; le <div> n’a qu’une fonction de mise en page. Voilà tout le principe en une phrase : utiliser des éléments sémantiques pour le sens et des divs pour la mise en page. (Sur une page réelle où cette carte se trouve à l’intérieur d’un document plus large, son titre serait généralement un <h2> ou <h3> pour correspondre à la structure de la page.)

    Refactorisation d’une carte de publication de blog, étape par étape

    Prenons un composant de carte que l’on trouve sur presque tous les sites de contenu : une image, une étiquette, un titre, l’auteur et la date, un extrait ainsi que deux actions. Voici la version avec des divs :

    <div class="card">
  <div class="card-image">
    <img src="tech.jpg" alt="Technology background" />
    <div class="badge">Article</div>
  </div>
  <div class="card-content">
    <div class="post-title" onclick="goToPost()">10 Tips for Better Code</div>
    <div class="post-author">By Jane Doe</div>
    <div class="post-date">August 12, 2026</div>
    <div class="post-excerpt">
      Learn how to write cleaner, more maintainable frontend code today...
    </div>
    <div class="card-footer">
      <div class="share-btn" onclick="sharePost()">Share</div>
      <div class="read-more" onclick="goToPost()">Read More</div>
    </div>
  </div>
</div>

    Les problèmes sont faciles à énumérer une fois qu’on les cherche :

    • L’enveloppe extérieure est un <div>, bien que la carte constitue un élément de contenu autonome, ce pour quoi le <article> a été conçu.
    • Le titre est un div cliquable, de sorte que les utilisateurs au clavier ne peuvent pas y accéder et que les lecteurs d’écran ne reconnaissent ni qu’il s’agit d’un titre ni d’un lien.
    • L’auteur et la date se trouvent dans des conteneurs génériques ne possédant aucune signification lisible par une machine.
    • "Partager" et ">Lire plus" sont des boutons fictifs qui présentent les mêmes problèmes d’accès au clavier et de notification évoqués précédemment.

    Voici la version réécrite :

    <article class="card">
  <figure class="card-image">
    <img src="tech.jpg" alt="Abstract technology grid pattern" />
    <span class="badge">Article</span>
  </figure>

  <div class="card-content">
    <h2>
      <a href="/posts/10-tips-for-better-code">10 Tips for Better Code</a>
    </h2>

    <p class="meta-info">
      Written by <span class="author">Jane Doe</span> on
      <time datetime="2026-08-12">August 12, 2026</time>
    </p>

    <p class="post-excerpt">
      Learn how to write cleaner, more maintainable frontend code today...
    </p>

    <footer class="card-footer">
      <button type="button" onclick="sharePost()" aria-label="Share this article">
        Share
      </button>
      <a href="/posts/10-tips-for-better-code" class="btn-primary">
        Read More
      </a>
    </footer>
  </div>
</article>

    Qu’est-ce qui a changé et pourquoi cela aide :

    • L’enveloppe <article> indique aux technologies d’assistance et aux robots de recherche que la carte est un élément indépendant.
  • L’image et son badge sont regroupés dans un <figure>, et le texte alternatif décrit désormais l’image au lieu de la qualifier de manière générique.
  • Le titre est un véritable <h2> contenant un lien réel, ce qui le fait apparaître dans l’arborescence des titres, peut être atteint avec la touche Tab et expose sa destination aux outils de balayage.
  • La date utilise <time datetime="2026-08-12">, ce qui permet aux outils de extraction, aux logiciels de traduction et aux intégrations calendaires d’obtenir une valeur lisible par machine sans ambiguïté, quel que soit le formatage du texte visible.
  • "Partager" est un <button> car il agit sur la page actuelle, tandis que "Lire plus" est un <a> car il permet de naviguer.
  • La propriété aria-label sur le bouton de partage fournit aux utilisateurs de lecteurs d’écran plus de contexte sur ce qui sera partagé. Conservez le texte visible à l’intérieur de la étiquette, comme c’est le cas ici (« Partager » fait partie de « Partager cet article »), afin que les utilisateurs contrôlés par la voix puissent encore l’activer en prononçant ce qu’ils voient.

    • Une amélioration à considérer : la carte contient désormais deux liens vers la même URL. Certaines équipes ne conservent que le lien du titre, ou rendent toute la carte cliquable grâce à ce seul lien, de sorte que les utilisateurs de clavier et de lecteurs d’écran n’atteignent pas deux fois la même destination.

    Habitudes pour garder votre balisage sémantique

    Vous n’avez pas besoin de réapprendre le développement web pour écrire un HTML de meilleure qualité. Quelques vérifications régulières permettent de détecter la plupart des problèmes.

    Mettre en œuvre un audit automatisé

    Les extensions de navigateur telles que axe DevTools ou WAVE, disponibles pour Chrome et Firefox, analysent une page en quelques secondes et signalent des problèmes tels que des attributs ARIA invalides, l’absence de types de boutons, un ordre de titres incorrect et des éléments interactifs sans sémantique adéquate. Les outils automatisés ne détectent qu’une partie des éléments importants, il convient donc de considérer un rapport sans erreur comme un point de départ et non comme une preuve d’accessibilité.

    Essayez la page sans CSS

    Désactivez tous les styles, que ce soit via les outils de développement ou une extension qui désactive le CSS, et observez ce qui reste. S’agit-il encore d’un document lisible ? Pouvez-vous distinguer les titres des paragraphes et trouver la navigation ? Si le résultat est un bloc de texte indifférencié, la structure dépend du CSS pour avoir un sens. Un document bien structuré reste organisé même en l’absence totale de styles.

    Oubliez la souris

    Essayez de faire fonctionner votre application en utilisant uniquement les flèches, Tab, Shift + Tab, Entrée, Espace et les touches directionnelles, puis vérifiez :

    • Si tous les éléments interactifs sont accessibles.
    • Si vous pouvez toujours voir quel élément est en surbrillance.
    • Si les formulaires, les listes déroulantes et les modaux fonctionnent correctement.

    Lorsque vous rencontrez un élément div qui ignore les touches Entrée ou Espace, remplacez-le par un <button>. C’est souvent l’une des solutions les plus rapides pour améliorer l’accessibilité.

    Demandez quel est le contenu avant d’écrire div

    Au moment de créer un nouveau conteneur, arrêtez-vous et demandez-vous ce que son contenu représente réellement :

    • Les éléments de navigation nécessitent <nav>.
    • Une barre latérale nécessite <aside>.
    • Une action cliquable nécessite <button>.
    • Une carte ou une publication indépendante nécessite <article>.
  • Le contenu principal de la page nécessite l’utilisation de <main>.
  • Seul un conteneur de mise en page dépourvu de signification propre requiert l’utilisation de <div>.

    • Cela vaut également à l’intérieur des composants : l’élément racine d’un composant React fait partie du document final, il convient donc de le choisir avec la même prudence. Pour en savoir plus sur les différences entre JSX et le HTML réel, consultez JSX n’est pas HTML : les vrais compromis derrière le markup des composants.

    Points clés

    • Les pixels affichés ne représentent qu’une seule couche ; l’arbre d’accessibilité, les outils de balayage et le traitement des entrées par le navigateur lisent tous vos éléments, et non vos styles.
    • Les éléments natifs tels que <button>, <a>, <input> et <details> offrent un focus, un support clavier, des rôles et un comportement mobile qui sont coûteux à recréer manuellement.
    • Utilisez <article> pour le contenu indépendant et <section> pour une partie thématique d’un ensemble plus large, et attribuez un titre à chaque section.
    • Les liens permettent de naviguer, les boutons agissent ; les mélanger confond les utilisateurs et perturbe le comportement attendu du navigateur.
    • Conservez une structure de titres claire sans sauts de niveau, et utilisez le CSS plutôt que les niveaux de titres pour contrôler la taille.
    • Les div restent le choix idéal pour un simple agencement. Les frameworks changent tous les quelques années, mais cette base existe depuis des décennies, et un marquage qui exprime clairement son sens est bénéfique tant pour les utilisateurs que pour les moteurs de recherche et votre équipe.

    Lectures complémentaires

    Tous les articlesEnvoyer le brief