HTML sémantique

L’HTML sémantique est un HTML dans lequel chaque élément est choisi pour sa signification, pas seulement pour son apparence. Un <button> sert aux actions. Un <nav> encadre la navigation. Un <table> contient des données tabulaires. Utiliser un <div> stylisé pour ressembler à un bouton afin de réaliser une action est un échec sémantique — même si le résultat visuel est identique.

La grande majorité des anomalies d’accessibilité trouve son origine dans un abandon de la sémantique. Presque toutes les défaillances relatives aux technologies d’assistance partagent la même cause profonde : un élément générique faisant le travail d’un élément sémantique conçu pour cela.

Pourquoi les lecteurs d’écran s’en soucient

Les lecteurs d’écran exposent le HTML à l’utilisateur via leur arbre d’accessibilité — une représentation interne construite à partir du DOM qui associe chaque élément à un rôle, un nom, un état et des propriétés. L’arbre d’accessibilité est ce que l’utilisateur entend réellement.

Un <button> natif entre dans l’arbre d’accessibilité en tant que button "Envoyer". Un <div> stylisé pour ressembler à un bouton y entre en tant que generic — ce qui signifie que le lecteur d’écran n’annonce rien d’utile, et que l’utilisateur n’a aucun moyen de découvrir que ce div est interactif.

La même logique s’applique à :

• Les titres (<h1> à <h6>) — les lecteurs d’écran permettent aux utilisateurs de sauter de titre en titre pour parcourir une page rapidement. <div class="heading"> n’apparaît pas dans la liste des titres.
• Les listes (<ul>, <ol>, <li>) — les lecteurs d’écran annoncent « liste, 5 éléments » avant de lire. Des <div> se faisant passer pour des éléments de liste ne font pas cela.
• Les formulaires — un <input> associé à un <label> lit « E-mail, champ de saisie ». Un champ personnalisé construit avec des divs et contenteditable ne lit rien.
• Les tableaux — un <table> avec des en-têtes <th> de lignes et de colonnes permet aux utilisateurs de naviguer dans les tableaux de données cellule par cellule avec l’en-tête annoncé en contexte. Des grilles CSS composées de divs ne le font pas.

Le modèle de correction

La correction adopte presque toujours la même forme :

• <div onclick="..."> → <button> (ou <a href> pour la navigation).
• <span class="link"> → <a href>.
• <div role="heading"> → <h1> à <h6>.
• Listes déroulantes personnalisées → <select> lorsque le design le permet, ou un combobox ARIA testé selon les bonnes pratiques lorsqu’il ne le permet pas.
• Onglets construits avec des <div> stylisés → modèle d’onglets du Guide des pratiques de création ARIA.

Quand recourir à ARIA

La première règle d’ARIA est : ne pas utiliser ARIA si un élément natif fait le travail. Les rôles, états et propriétés ARIA sont un correctif pour les cas où le HTML natif ne peut pas décrire le composant que l’on construit (vues arborescentes, listes déroulantes à sélection multiple, certains modèles de fenêtres modales). Ils ne se substituent pas à l’utilisation de <button>.

Un audit pragmatique

Le moyen le plus rapide de détecter la dégradation sémantique dans une base de code : rechercher onclick sur les div et span. Chaque occurrence est une défaillance potentielle. Ensuite : rechercher les attributs role=. ARIA est acceptable dans des contextes limités, mais une utilisation intensive d’ARIA signale souvent que des éléments natifs ont été écartés pour des raisons stylistiques qui ne le justifiaient pas réellement.