HTML sémantique

Revue, réécriture et explication de la sémantique HTML5 (balises, points de repère, titres, formulaires, ARIA). À utiliser chaque fois que l'utilisateur colle du HTML ou demande une révision de balisage, les bonnes balises, l'accessibilité ou la correction de la 'divite'.

Qu'est-ce que HTML sémantique ?

Cette compétence est conçue pour les développeurs et les agents IA qui travaillent avec du code HTML et souhaitent garantir une sémantique correcte, l'accessibilité et le respect des normes HTML5. Elle permet d'analyser tout extrait HTML (ou JSX/autre template en se concentrant sur le balisage résultant) et de fournir un retour structuré comprenant un diagnostic des problèmes, le code corrigé avec des commentaires, et des explications détaillées. L'accent est mis sur le HTML5 simple et indépendant de tout framework, avec une attention particulière à l'arbre d'accessibilité du navigateur et aux rôles implicites des balises. Utile pour les revues de code, l'enseignement des bonnes pratiques, et la correction de la 'divite'. Fonctionne avec n'importe quel agent ou plateforme prenant en charge les compétences markdown.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/lucasaugustsof/skills/tree/HEAD/semantic-html

Installed? Explore more Productivité et collaboration skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait HTML sémantique ?

Aide à réviser le HTML, à retourner une version corrigée et à expliquer le raisonnement derrière chaque choix. L'accent est toujours mis sur le HTML5 simple, indépendant de tout framework : si le code est du JSX ou un autre modèle, analysez uniquement le balisage résultant et répondez en HTML.

Répondez dans la langue dans laquelle l'utilisateur écrit.

Pourquoi la sémantique est importante (utilisez ceci pour expliquer)

Le navigateur transforme le HTML en DOM et, à partir de celui-ci, construit l'arbre d'accessibilité. Chaque balise a un rôle implicite (<button> → bouton, <nav> → navigation, <h2> → titre de niveau 2). Les lecteurs d'écran, les moteurs de recherche, le mode lecture et les extensions lisent cet arbre, pas le CSS. Un <div> stylisé en bouton ressemble à un bouton, mais pour l'arbre ce n'est qu'un bloc générique : il ne reçoit pas le focus, ne répond pas à Entrée/Espace et n'est pas annoncé comme un bouton.

Ancrez les explications sur cela — ce que le navigateur comprend et ce qui change pour les personnes qui utilisent la page — plutôt que sur des règles mémorisées. Préférez des exemples concrets ("le lecteur d'écran annoncera…", "Tab ignorera cet élément…") aux abstractions.

Test mental utile : si le CSS disparaissait, la structure aurait-elle encore un sens ?

Flux de travail

  1. Comprenez le contenu avant les balises. Quel est chaque bloc ? Navigation, contenu principal, élément autonome, contrôle interactif ? Si l'intention est ambiguë (par exemple un lien qui ressemble à un bouton), supposez la lecture la plus probable et indiquez laquelle vous avez supposée.
  2. Révisez en utilisant la liste de contrôle ci-dessous.
  3. Répondez dans le format défini.

Liste de contrôle de révision

Document

  • <!DOCTYPE html>, <html lang="...">, <meta charset="utf-8">, <meta name="viewport">, un <title> descriptif (uniquement si l'extrait est un document complet).

Points de repère

  • <header>, <nav>, <main> (un seul visible par page), <aside>, <footer>.
  • <section> regroupe du contenu thématique et a normalement un titre ; sans titre, c'est probablement un <div>.
  • <article> est un contenu qui aurait du sens tout seul (article, fiche produit, commentaire).
  • Plusieurs <nav> sur la page → distinguez-les avec aria-label.

Titres

  • Hiérarchie sans niveaux sautés (h2 → h4 est un problème).
  • Un titre décrit sa section ; n'utilisez pas les titres pour agrandir du texte, ni du texte stylisé à la place d'un titre.

Interaction

  • Une action sur la page → <button> (avec un type explicite dans les formulaires). Navigation vers une autre URL → <a href>.
  • <div onclick>, <span onclick> et <a> sans href sont des signaux d'alarme.
  • Envisagez les éléments natifs avant de les reconstruire : <details>/<summary>, <dialog>.

Formulaires

  • Chaque champ a un <label> associé (for/id ou enveloppant l'entrée). Un placeholder ne remplace pas un label.
  • Groupes de boutons radio/checkbox dans <fieldset> + <legend>.
  • type approprié (email, tel, number, date…) et autocomplete là où cela a du sens.

Listes et tableaux

  • Un ensemble d'éléments → <ul>/<ol> ; paires terme–définition → <dl>.
  • <table> uniquement pour les données tabulaires, avec <caption>, <thead> et <th scope>. Jamais pour la mise en page.

Média

  • <img> avec alt décrivant son objectif ; décoratif → alt="".
  • Image avec une légende → <figure> + <figcaption>.

Texte

  • Emphase significative : <strong>/<em> ; <b>/<i> uniquement pour un décalage stylistique sans importance.
  • <time datetime>, <blockquote>/<q>, <cite>, <abbr>, <code>/<pre>, <address> là où ils conviennent.
  • <br> uniquement pour les sauts de ligne qui font partie du contenu (adresse, poème), pas pour l'espacement.

ARIA

  • Première règle : si un élément natif existe, utilisez-le plutôt que ARIA.
  • Signalez l'ARIA redondante (<button role="button">, <nav role="navigation">) et l'ARIA qui contredit la balise.

Ne corrigez pas trop. <div> et <span> sont corrects lorsqu'un bloc existe uniquement pour la mise en page ou le style. Remplacer chaque <div> par une <section> aggrave l'arbre d'accessibilité.

Format de réponse (ton mixte : correction directe + court argument)

Diagnostic

Liste des problèmes regroupés par impact :

  • Casse l'accessibilité/la convivialité — quelque chose qui empêche une personne d'utiliser la page (bouton sans focus, champ sans label, image sans alt).
  • Sémantique imprécise — cela fonctionne, mais communique une structure incorrecte (titre sauté, section sans titre).
  • Détail — amélioration de précision.

Chaque élément : ce qui ne va pas → ce qu'il faut utiliser. Une ligne.

Code corrigé

Le HTML complet réécrit, avec de courts commentaires uniquement sur les parties modifiées.

Pourquoi

2 à 5 courtes explications, une par décision importante, liées à ce que fait le navigateur/l'arbre d'accessibilité. Si un concept est central (par exemple rôle implicite, point de repère), expliquez-le une fois avec un exemple concret.

Si le code est déjà bon, dites-le clairement et ne signalez que ce qui vaut vraiment la peine d'être ajusté.

Exemple

Entrée :

<div class="header">
  <div class="logo">Store</div>
  <div class="menu"><a>Accueil</a><a>Produits</a></div>
</div>
<div class="title">Promotions</div>
<div onclick="buy()">Acheter</div>

Sortie (abrégée) :

Diagnostic

  • Casse l'accessibilité : <div onclick> → <button type="button"> ; <a> sans href → liens avec href.
  • Sémantique imprécise : .header → <header> ; .menu → <nav> avec <ul> ; .title → <h1> ; <main> manquant.

Code corrigé

<header>
  <p class="logo">Store</p>
  <nav aria-label="Principale">
    <ul>
      <li><a href="/">Accueil</a></li>
      <li><a href="/produits">Produits</a></li>
    </ul>
  </nav>
</header>
<main>
  <h1>Promotions</h1>
  <button type="button" onclick="buy()">Acheter</button>
</main>

Pourquoi

  • Le <div> n'est pas dans l'ordre de Tab et ne réagit pas à Entrée ; <button> vient avec le focus et le support clavier et est annoncé comme "bouton".
  • Un <a> sans href n'est pas un lien pour le navigateur : il ne reçoit pas le focus et n'apparaît pas dans la liste des liens du lecteur d'écran.
  • <nav> et <main> deviennent des points de repère : les utilisateurs de lecteurs d'écran peuvent y accéder directement.

Sources

En cas de doute sur une règle, confirmez-la sur MDN ou dans le HTML Living Standard (si un outil de documentation est disponible, utilisez-le) et citez le lien.

Skills associés