Dans chaque page web, l’information est-elle structurée par l’utilisation appropriée de titres ?
Un utilisateur de lecteur d’écran qui arrive sur une longue page dispose d’une option précieuse : naviguer de titre en titre avec la touche H. En quelques secondes, il parcourt la structure du document sans écouter tout le contenu. Ça ne fonctionne que si les titres existent et sont balisés correctement.
Ce critère impose trois vérifications. Les titres doivent être balisés avec des éléments <hx> (de <h1> à <h6>) ou avec role="heading" accompagné de aria-level. Leur hiérarchie doit être cohérente : pas de saut de <h1> directement à <h3> sans <h2> intermédiaire. Et chaque titre doit décrire la section qu’il introduit, pas juste en meubler la mise en page.
Sans structure de titres, la page devient un bloc opaque pour les personnes aveugles, les personnes sourdes qui parcourent les grandes lignes pour repérer le contenu qui les intéresse, et les personnes avec des troubles cognitifs qui ont besoin de repères sémantiques. Trois profils différents, même besoin : une architecture lisible.
L’écueil le plus fréquent en audit : des <h2> ou <h3> placés pour leur rendu visuel, sans intention sémantique. Un bouton « Télécharger le document » balisé en <h2> parce que ça le met en gros : c’est une erreur classique qui casse la navigation par titres et crée de faux repères dans le plan de la page.
3 tests pour s'assurer que la hiérarchie des titres est cohérente
Hiérarchie des titres <hx>
- Identifiez tous les titres de la page : balises
<h1>à<h6>, et éléments portantrole="heading". - Reconstituez le plan du document (avec un outil comme HeadingsMap ou Web Developer → View Document Outline).
- Vérifiez que la hiérarchie est cohérente : aucun saut de niveau injustifié (ex. : un
<h4>après un<h2>sans<h3>intermédiaire doit être justifié). - Test validé si la structure reflète l’organisation logique du contenu.
Pertinence du contenu des titres
- Reprenez la liste des titres identifiés au test 9.1.1.
- Pour chaque titre, lisez son texte : décrit-il clairement la section qui suit ?
- Un titre vague (« En savoir plus », « Section 1 », « Cliquez ici ») ou trop générique fait échouer le test.
- Test validé si chaque titre annonce clairement le contenu de sa section.
Balisage sémantique des titres
- Pour chaque titre identifié au test 9.1.1, inspectez le code HTML.
- Le titre doit utiliser l’une de ces deux formes :
- Une balise native :
<h1>,<h2>,<h3>,<h4>,<h5>ou<h6>. - Ou un élément avec
role="heading"ETaria-level="x"(x étant un entier).
- Une balise native :
- Un texte visuellement mis en forme comme un titre via CSS, sans ces balises, fait échouer le test.
- Test validé si chaque titre utilise l’un des deux mécanismes ci-dessus.
Exemples
❌ Non conforme : Saut de niveau et balise détournée de son usage
<h1>Nos services</h1>
<h3>Formation RGAA</h3>
<p>Apprenez les critères d’accessibilité.</p>
<h2><a href="/contact">Contactez-nous</a></h2>Deux problèmes cumulés. Le passage de <h1> à <h3> sans <h2> casse la hiérarchie : le lecteur d’écran annonce « titre de niveau 3 » juste après « titre de niveau 1 », ce qui désorie l’utilisateur. Le <h2> autour du lien « Contactez-nous » n’introduit aucune section de contenu : c’est un lien d’action balisé en titre uniquement pour son rendu visuel, créant un faux repère dans le plan de la page.
✅ Conforme : Hiérarchie cohérente et titres descriptifs
<h1>Nos services</h1>
<h2>Formation</h2>
<h3>Formation RGAA</h3>
<p>Apprenez les critères d’accessibilité.</p>
<h3>Formation WCAG</h3>
<p>Maîtrisez les standards internationaux.</p>
<h2>Audit d’accessibilité</h2>
<p>Vérification de conformité de votre site.</p>La hiérarchie h1 → h2 → h3 est continue et logique. Chaque titre décrit la section qu’il introduit. Un utilisateur naviguant par titres comprend immédiatement la structure du contenu sans écouter les paragraphes.
✅ Conforme : Titre ARIA sur un composant custom
<div role="heading" aria-level="2">Accessibilité des formulaires</div>
<p>Les champs doivent avoir des étiquettes visibles et programmatiques.</p>Quand une contrainte technique impose un <div> à la place d’un <h2>, l’association role="heading" et aria-level="2" transmet la même sémantique aux technologies d’assistance. Cette forme est conforme selon le test 9.1.3, mais préférez toujours la balise native <h2> quand c’est possible.
Astuces et pièges
⚠️ Le <hx> utilisé comme outil de mise en forme
Baliser un lien ou un bouton avec <h2> pour lui appliquer le style visuel du titre est l’erreur la plus fréquente en audit. Le lecteur d’écran annonce un titre là où l’utilisateur attend une section de contenu. La navigation par titres devient trompeuse. Si vous avez besoin du style, appliquez une classe CSS à la balise sémantiquement correcte (<a>, <button>) plutôt que de détourner <hx>.
⚠️ Texte visuellement « titre » mais balisé en <p> ou <div>
Un <p> en gras et grande police, mis en forme comme un titre via CSS, n’est pas un titre pour les technologies d’assistance. Le lecteur d’écran le lira comme un paragraphe ordinaire, sans l’annoncer comme point de navigation. Règle simple : si un élément joue le rôle d’un titre dans la page, balisez-le comme tel.
💡 Auditer le plan du document en 10 secondes
Dans Firefox avec l’extension Web Developer, allez dans Information → View Document Outline. Sur Chrome, HeadingsMap affiche la hiérarchie complète en panneau latéral. Si le plan ressemble à une liste chaotique de niveaux mélangés, le critère 9.1 est presque certainement en échec.
⚠️ Sauter un niveau n’est pas systématiquement non conforme
Le RGAA demande que la hiérarchie soit « pertinente », pas strictement continue. Un <h4> après un <h2> peut se justifier si le bloc est intégré depuis un composant tiers avec sa propre hiérarchie interne. Sur une page entièrement maîtrisée, tout saut injustifié doit être corrigé.
⚠️ Plusieurs <h1> dans une même page
La recommandation d’un unique <h1> par page est une bonne pratique, pas une exigence du RGAA 4.1. Ce qui est exigé : une hiérarchie cohérente et des titres pertinents. Plusieurs <h1> peuvent se justifier dans une page composée d’articles indépendants (flux, agrégateur), où chaque <article> a son propre titre principal.
Questions fréquentes
Pourquoi éviter de sauter des niveaux de titres selon le RGAA ?
Rarement justifié. Le RGAA exige une hiérarchie pertinente. Un saut de <h2> à <h4> sans <h3> désorie les utilisateurs de lecteurs d’écran qui s’attendent à trouver un niveau intermédiaire. Si le saut est imposé par un composant tiers non modifiable, documentez la raison dans votre audit. Sur une page maîtrisée, corrigez.
Quel est le rôle obligatoire du <h1> dans la structure RGAA ?
Le RGAA ne l’impose pas explicitement, mais l’absence de <h1> sera signalée dans la quasi-totalité des audits. Sans lui, le point d’entrée principal de la page manque, ce qui désorie les utilisateurs de lecteurs d’écran dès leur arrivée. En pratique, prévoyez toujours un <h1> qui décrit le sujet de la page.
Comment auditer le critère 9.1 des titres RGAA sur une SPA ?
Vérifiez la structure des titres après chaque changement de vue, pas seulement au chargement initial. Dans une SPA, le contenu étant injecté dynamiquement, les titres peuvent disparaître ou se dupliquer. Utilisez l’arbre d’accessibilité des DevTools ou HeadingsMap après navigation pour valider l’état réel du DOM. Le test 9.1 porte sur le rendu final, pas sur le HTML source statique.
Quelle différence y a-t-il entre <h2> et role="heading" aria-level="2" en RGAA ?
Sémantiquement équivalents pour les technologies d’assistance. En pratique, préférez toujours <h2> : plus court, plus robuste, aucun attribut supplémentaire requis. role="heading" avec aria-level est réservé aux cas où un composant génère un élément non-heading (un <div> ou un <span>) qu’il est techniquement impossible de remplacer par une balise native.
Quel impact ont les titres masqués en CSS sur la hiérarchie RGAA ?
Oui, s’il reste accessible aux technologies d’assistance. Un titre masqué avec la technique « visually hidden » (clip, position absolue hors écran) est annoncé par les lecteurs d’écran et doit donc s’intégrer cohéremment dans la hiérarchie. En revanche, display : none et visibility : hidden rendent l’élément invisible de tous, lecteurs d’écran compris, et il ne compte plus.