Le WordPress d'aujourd'hui, décodé pour les développeurs

Accessibilité

Concevoir des templates de site pour une hiérarchie de titres fiable

Un h1 unique par page et une cascade de titres cohérente : comment organiser les parts et les templates de l'éditeur de site pour garantir cette structure sans y penser à chaque page.

Par WordPress Développement • 19 novembre 2022 • 5 min de lecture • Aucun commentaire
Concevoir des templates de site pour une hiérarchie de titres fiable

Où placer le h1 d’une page quand l’éditeur de site permet d’assembler un en-tête, un contenu et un pied de page à partir de plusieurs parts indépendantes ? La question paraît anodine, mais elle est à l’origine d’un défaut très répandu depuis la généralisation de l’édition complète de site : des pages avec deux, parfois trois titres de niveau 1, parce que chaque part a été conçue isolément sans réflexion d’ensemble sur la hiérarchie finale.

Le problème est structurel : un site part d’en-tête est réutilisé sur toutes les pages du site, un site part de pied de page également. Si l’un des deux contient un h1, celui-ci se retrouve dupliqué sur chaque page où le site part est inséré, en plus du titre de contenu qui devrait légitimement porter ce rôle. Pour une personne naviguant au lecteur d’écran par raccourci de titres, cette duplication rend la navigation confuse : impossible de savoir lequel des deux titres correspond réellement au sujet de la page.

Le principe d’organisation à adopter

La règle qui évite ce piège tient en une phrase : aucun site part ne doit jamais contenir de h1, ni même commencer sa propre cascade à h2 s’il est destiné à être inséré au milieu d’un contenu. Concrètement, l’arborescence de templates se répartit ainsi :

Templates
├── Page d'accueil
│   ├── Site part : en-tête        (aucun titre, ou h2 si nécessaire)
│   ├── Bloc de contenu             (h1 : titre de la page)
│   └── Site part : pied de page   (aucun titre)
├── Page (modèle générique)
│   ├── Site part : en-tête
│   ├── Titre de la publication     (h1, généré dynamiquement)
│   └── Site part : pied de page
└── Article (single)
    ├── Site part : en-tête
    ├── Titre de l'article          (h1, bloc Titre de la publication)
    └── Site part : pied de page

Le h1 n’existe qu’à un seul endroit dans cette arborescence : le bloc « Titre de la publication », inséré directement dans le template, jamais dans un site part réutilisable. Cette contrainte d’organisation garantit mécaniquement l’unicité du titre de premier niveau, sans qu’aucun rédacteur n’ait à y penser page après page.

Le cas particulier de la navigation dans l’en-tête

L'essentiel à retenir : Un seul h1 par page, jamais dans un site part ; Les parts commencent leur cascade à h2 ; Vérification possible sur tout le site en une passe

Le site part d’en-tête contient souvent le nom du site, parfois stylé visuellement comme un grand titre. La tentation est grande d’utiliser un h1 pour ce nom de site, en particulier sur la page d’accueil où il joue effectivement le rôle de titre principal. La solution la plus robuste reste néanmoins de le traiter différemment selon le contexte :

  • Sur la page d’accueil, le nom du site peut porter le h1, à condition que le site part correspondant soit un site part spécifique à cette page, distinct de celui utilisé partout ailleurs ;
  • Sur toutes les autres pages, le nom du site dans l’en-tête doit être un lien simple, sans niveau de titre, le h1 revenant systématiquement au titre de la page ou de l’article affiché.

Cette distinction demande de créer deux variantes du site part d’en-tête plutôt qu’une seule utilisée partout, ce qui représente un coût de conception initial mais élimine durablement le risque de duplication.

Vérifier la cohérence sur l’ensemble du site

Une fois l’arborescence posée, la vérification se fait outil en main : l’extension de navigateur HeadingsMap, ou l’inspecteur d’accessibilité intégré à certains navigateurs, affiche la cascade complète des titres d’une page en un clic. Il suffit de contrôler un gabarit de chaque type de template (page d’accueil, page générique, article, archive) pour valider l’ensemble du site, puisque la structure des site parts est partagée.

Vérifier un template une fois vaut mieux que vérifier cent pages une par une : c’est tout l’intérêt de raisonner au niveau de l’arborescence plutôt que du contenu final.

Les erreurs qui reviennent malgré une bonne arborescence

Même avec cette organisation, deux pièges subsistent. Le premier : un bloc de requête inséré dans une page d’archive qui affiche les titres d’articles en h2, alors que la page contient déjà un h1 de titre d’archive et un h2 de section « Articles récents » — il faut alors descendre les titres d’articles en h3 pour respecter la cascade. Le second : un modèle de page 404 ou de résultats de recherche vide, souvent oublié lors de la vérification initiale, qui peut se retrouver sans aucun titre de niveau 1 si le contenu dynamique attendu ne s’affiche pas.

Pour aller plus loin

Une hiérarchie de titres fiable ne se corrige pas page par page une fois le site en ligne : elle se construit au niveau des templates et des site parts, avant même la rédaction du premier contenu. Cette discipline d’organisation, une fois posée, s’applique automatiquement à toutes les pages futures du site sans surveillance supplémentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi