Partie 3 — HTML sémantique : la fondation

⏱️ TL;DR — Environ 80 % de l’accessibilité, c’est du bon HTML. Les éléments natifs (<button>, <nav>, <h1>, <table>…) exposent gratuitement un rôle, la navigation clavier et des états aux technologies d’assistance. La fameuse « soupe de <div> » perd tout ça : un <div> n’a ni rôle, ni focus, ni sens. Cette partie est la fondation posée avant l’ARIA, le clavier fin ou les composants complexes — parce qu’on ne construit rien de solide dessus tant que la base sémantique n’est pas là.

Le problème qu’on résout

Beaucoup de dévs traitent le HTML comme un simple support de style : <div> partout, la sémantique viendra « avec de l’ARIA plus tard ». C’est l’erreur fondatrice. L’ARIA ne fait que décrire ; le HTML natif, lui, fait — il apporte le comportement clavier, le rôle annoncé, les états gérés par le navigateur. Repartir des bons éléments élimine des classes entières de bugs d’accessibilité avant même qu’ils existent. Cette partie t’apprend à choisir la bonne balise, à structurer une page en régions, à hiérarchiser tes titres, à distinguer bouton et lien, et à rendre un tableau de données lisible au lecteur d’écran.

Ce que tu sauras faire à la fin de cette partie

• Expliquer ce qu’un élément natif apporte (rôle, focus, clavier, états) et le coût caché du tout-<div>.
• Structurer une page en landmarks (<header>, <nav>, <main>, <aside>, <footer>) navigables au lecteur d’écran.
• Construire une hiérarchie de titres logique (<h1>–<h6>) et utiliser les listes sémantiques.
• Choisir entre <button> (action) et <a href> (navigation), et bannir les <div> cliquables.
• Rendre un tableau de données accessible avec <caption>, <thead>/<tbody> et <th scope>.

Les chapitres

On commence : Pourquoi la sémantique.