Vérificateur d'en-têtes WCAG, gratuit

Qu'est-ce qu'un vérificateur de titres WCAG ?

Un vérificateur de titres WCAG valide que les éléments de titre d'une page web (h1, h2, h3, h4, h5, h6) forment une hiérarchie logique que les lecteurs d'écran et autres technologies d'assistance peuvent parcourir. Les titres sont la façon dont les utilisateurs aveugles et malvoyants parcourent une page : ils utilisent un raccourci du lecteur d'écran pour passer de titre en titre, construisant une table des matières mentale en quelques secondes. Si les titres sont manquants, dans le désordre, ou utilisés de manière décorative, cette navigation s'effondre. Le critère de succès WCAG 2.2 1.3.1 (Information et relations) et 2.4.6 (En-tetes et étiquettes) exigent que les titres traduisent la structure correctement.

Les règles sont simples à énoncer et faciles à violer. Il devrait y avoir exactement un h1 par page (le titre de la page). Chaque titre suivant doit être au maximum un niveau plus profond que son parent (un h2 peut être suivi d'un autre h2 ou d'un h3, mais pas directement d'un h4). Les titres ne doivent pas être vides. Les niveaux de titre doivent décrire la structure du document, pas la taille visuelle (n'utilisez pas h4 simplement parce que vous voulez un texte plus petit). La plupart des audits d'accessibilité signalent les problèmes de hiérarchie des titres comme la première chose à corriger car ils sont courants, faciles à vérifier et à fort impact pour les utilisateurs de lecteurs d'écran.

Cet outil analyse le HTML que vous collez (pas de téléchargement, pas d'aller-retour serveur), parcourt les éléments de titre dans l'ordre du document, et signale les problèmes : h1 manquant, plusieurs h1, niveaux sautés, titres vides, et un plan de la structure de la page. La sortie est du texte simple décrivant chaque problème. Exécutez-le sur n'importe quelle page pendant le développement, avant le lancement, ou dans le cadre d'un cycle d'audit d'accessibilité régulier. La sortie est en langage simple, pas un score numérique ; l'objectif est de vous donner des problèmes spécifiques à corriger, pas une note de passage à viser.

Ce qu'il y a dans l'outil

Le haut de la page est une zone de texte où vous collez votre HTML. Vous pouvez coller un document complet (DOCTYPE, html, head, body) ou un fragment (juste le contenu du body). L'outil extrait tous les éléments h1 à h6 dans l'ordre du document en utilisant un DOMParser standard du navigateur, donc l'analyse correspond à ce qu'un vrai navigateur ferait. La zone de texte gère une entrée de toute taille ; les très gros documents (dizaines de milliers de lignes) fonctionnent mais prennent une fraction de seconde de plus à analyser.

Cliquez sur Vérifier les titres et les résultats apparaissent en dessous. La première section est le plan des titres : chaque titre dans l'ordre, indenté par niveau, afin que vous puissiez lire la structure comme une table des matières. La deuxième section est la liste des problèmes : chaque problème avec son emplacement spécifique, ce qui ne va pas, et une brève explication de pourquoi cela importe. Les problèmes sont classés par sévérité : erreurs (à corriger pour la conformité WCAG) et avertissements (bonne pratique mais pas des échecs stricts).

La sortie reste dans le navigateur ; rien n'est téléchargé. Vous pouvez coller le même HTML plusieurs fois avec des modifications entre les deux pour itérer sur les corrections. L'outil ne vérifie intentionnellement rien en dehors de la structure des titres (il ne vérifie pas le texte alt, le contraste, l'ordre de focus, ARIA, ou tout autre critère WCAG). Pour ceux-ci, utilisez cet outil aux côtés d'un outil d'audit complet comme axe DevTools, Lighthouse, ou WAVE.

Histoire et contexte

Les titres HTML depuis le début (1991)

Tim Berners-Lee a introduit HTML en 1991 avec les éléments h1 à h6 comme partie des 18 balises originales. L'intention sémantique originale a toujours été la structure du document, pas le style visuel. La hiérarchie des titres du Web vient d'une tradition beaucoup plus ancienne : les documents imprimés (livres, articles, rapports gouvernementaux) utilisent des niveaux de section numérotés depuis des siècles pour traduire la structure. HTML a hérité directement de ce modèle. Malgré 35 ans de sémantique stable, l'utilisation incorrecte des titres est l'un des bugs d'accessibilité les plus courants sur le web moderne car les designers stylent souvent par taille visuelle d'abord et vérifient la structure ensuite.

Les lecteurs d'écran apprennent à naviguer par titre (à partir de 1996)

JAWS (Job Access With Speech) a été lancé par Henter-Joyce en 1989 et a ajouté la navigation par titre de page web à mesure que le Web devenait populaire à la fin des années 1990. Appuyer sur la touche H dans JAWS saute au titre suivant ; les touches numérotées 1 à 6 sautent à ce niveau de titre spécifique. Tous les principaux lecteurs d'écran depuis (NVDA en 2006, VoiceOver en 2005, TalkBack sur Android) ont copié ce raccourci. L'enquête annuelle des utilisateurs de lecteurs d'écran de WebAIM trouve systématiquement que 67 à 70 pour cent des utilisateurs de lecteurs d'écran naviguent par titres comme leur méthode principale pour comprendre une page. La hiérarchie de titres cassée n'est donc pas un problème cosmétique.

WCAG 1.0 et la montée des normes d'accessibilité (1999)

Les Directives pour l'accessibilité aux contenus Web 1.0 ont été publiées par le W3C en mai 1999, la première norme internationale pour l'accessibilité Web. WCAG 1.0 exigeait explicitement que les titres soient utilisés pour la structure du document (point de contrôle 3.5). WCAG 2.0 (2008) a affiné cela en critère de succès 1.3.1 (Information et relations, niveau A) et 2.4.6 (En-tetes et étiquettes, niveau AA). WCAG 2.1 (2018) et 2.2 (2023) ont gardé ces critères inchangés car l'exigence sous-jacente est solide. La plupart des lois d'accessibilité dans le monde (ADA aux États-Unis, EAA en Europe, AODA en Ontario) citent maintenant WCAG 2.1 AA comme la référence légale.

Sectionnement HTML5 et plan du document (2014)

HTML5 (Recommandation W3C 2014) a introduit les éléments de sectionnement (article, section, nav, aside) et un algorithme de plan censé dériver la hiérarchie des titres de la profondeur de l'imbrication. L'algorithme n'a jamais été implémenté dans aucun navigateur ou lecteur d'écran et a été formellement déprécié en 2022. La directive pratique est : utilisez des niveaux de titre explicites (h1 à h6) et traitez les éléments de sectionnement comme un regroupement sémantique, pas comme un substitut à la profondeur des titres. Le HTML Living Standard indique maintenant clairement que les niveaux de titre doivent être définis explicitement.

Rôles ARIA et aria-level (à partir de 2014)

WAI-ARIA 1.1 (Recommandation W3C 2017) fournit role="heading" avec aria-level="N" comme alternative pour marquer les titres, utile lorsque vous ne pouvez pas utiliser les éléments natifs h1-h6 (par exemple, dans un composant de framework qui doit rendre différents niveaux de titre dans différents contextes). Les lecteurs d'écran traitent role="heading" identiquement à l'élément natif. La meilleure pratique est d'utiliser les éléments natifs lorsque possible ; utilisez ARIA uniquement lorsque la sémantique native n'est pas disponible. Cet outil vérifie à la fois les éléments de titre natifs et les éléments avec role="heading".

Poursuites d'accessibilité et analyse de rentabilité (à partir de 2017)

Domino's Pizza c. Robles (Cour suprême des États-Unis 2019) a établi que la loi américaine sur les personnes handicapées (ADA, 1990) s'applique aux sites web commerciaux. Des centaines de poursuites similaires ont suivi chaque année (plus de 4 000 poursuites web ADA déposées rien qu'en 2024). La loi européenne sur l'accessibilité (EAA, en vigueur en juin 2025) fait de l'accessibilité équivalente à WCAG une exigence légale pour la plupart des sites web destinés aux consommateurs à travers l'UE. La structure de titres défaillante est l'un des problèmes les plus faciles à identifier et à documenter pour les plaignants, ce qui fait des vérifications de titres de base une étape de conformité à fort effet de levier.

Flux de travail pratiques

Vérification pré-lancement sur les nouvelles pages et modèles

Avant que toute nouvelle page ou modèle ne soit livré, exécutez le HTML à travers ce vérificateur. Les problèmes de structure de titres sont les bugs d'accessibilité les plus faciles à introduire (en particulier dans le contenu géré par CMS où les éditeurs choisissent les niveaux de titre en fonction de la taille visuelle) et les plus faciles à corriger. Les attraper avant le lancement est beaucoup moins coûteux qu'après, quand les corrections nécessitent une coordination avec les propriétaires de contenu. Pour les agences, intégrez cette vérification dans la liste de contrôle QA ; pour les équipes internes, exécutez-la dans le cadre de la révision de code ou avant la fusion vers main.

Audit d'un site existant pour la conformité d'accessibilité

Pour un audit d'accessibilité (pré-litige, conformité EAA, exigence contractuelle), parcourez les pages les plus visitées et exécutez le HTML de chacune à travers ce vérificateur. Documentez les constatations : quelles pages ont des problèmes de titres, de quel type, comment corriger. Combinez avec axe DevTools ou Lighthouse pour les autres critères WCAG. Les constatations de structure de titres sont généralement les plus faciles à remédier et forment une solide section de gains rapides du rapport d'audit.

Formation des éditeurs CMS et modèles

Le contenu géré par CMS (WordPress, Drupal, Contentful, Sanity) donne souvent aux éditeurs un menu déroulant de titres avec les options H1 à H6. Les éditeurs qui ne connaissent pas les règles choisissent les niveaux par taille visuelle. Démontrez ce vérificateur aux éditeurs afin qu'ils puissent voir ce que leurs choix de titres produisent. Pour les modèles, exécutez la sortie rendue à travers le vérificateur après chaque changement de design pour confirmer que les choix de titres de l'éditeur produisent toujours une hiérarchie valide. De nombreux plugins CMS existent qui avertissent les éditeurs au moment de l'écriture ; cet outil sert l'étape de vérification.

Validation des modèles d'email et bulletins HTML

Les emails HTML lus par les lecteurs d'écran doivent suivre la même hiérarchie de titres que les pages web. Exécutez le HTML de votre modèle d'email à travers ce vérificateur avant l'envoi à une grande liste. Problèmes courants des modèles d'email : plusieurs h1 (quand chaque section a son propre titre), h1 manquant (quand la mise en page commence directement par h2), et h4 décoratifs utilisés uniquement pour de petits titres. Corrigez-les avant l'envoi ; les utilisateurs de technologies d'assistance sur votre liste le remarqueront.

Validation des conversions PDF-vers-HTML

Lorsque vous convertissez des PDF en HTML pour l'accessibilité (afin qu'ils puissent être lus par les lecteurs d'écran avec la navigation par titre), le convertisseur doit mapper les balises de structure PDF aux niveaux de titre HTML. Le résultat est souvent cassé : les PDF sans étiquetage approprié produisent du HTML plat sans aucun titre, et même les PDF étiquetés produisent parfois une sortie tout-h1 ou tout-h2. Exécutez le HTML converti à travers ce vérificateur pour repérer le problème avant de publier la page convertie.

Intégration de nouveaux développeurs et designers

Les développeurs front-end juniors et les designers bénéficient de voir des exemples concrets de hiérarchie de titres cassée et l'expérience de lecteur d'écran qui en résulte. Associez cet outil à une démonstration de lecteur d'écran (NVDA sur Windows est gratuit, VoiceOver sur Mac est intégré) pour montrer comment les titres pilotent la navigation du lecteur d'écran. Le lien entre les règles abstraites des titres et l'expérience utilisateur concrète est souvent ce qui fait que la leçon reste.

Pièges courants

Choisir le niveau de titre par taille visuelle

L'erreur la plus courante : utiliser un h4 parce que vous voulez un texte plus petit, ou sauter de h2 à h4 parce qu'il n'y a pas de h3 dimensionné correctement dans le design. Les niveaux de titre sont structurels, pas visuels ; utilisez CSS pour contrôler la taille et utilisez le niveau qui correspond à la hiérarchie du document. Si votre système de design n'a pas de style visuel pour chaque niveau nécessaire, ajoutez-en un (ou remplacez avec des noms de classe) plutôt que de choisir le mauvais niveau.

Plusieurs h1 par page

Une page devrait avoir exactement un h1 représentant le titre de la page. Bugs courants : un logo de site enveloppé dans h1 plus un titre d'article également dans h1 (deux h1), une page d'accueil avec chaque section hero utilisant h1 (plusieurs h1), ou pas de h1 du tout parce que la mise en page commence par h2. La correction est structurelle : choisissez le contenu le plus important de la page comme l'unique h1 et rétrogradez tout le reste à h2 ou en dessous. Des outils comme axe et Lighthouse alertent sur les h1 multiples pour cette raison.

Niveaux de titre sautés

Passer de h2 directement à h4 brise le plan du document. Les utilisateurs de lecteurs d'écran qui se déplacent de titre en titre s'attendent à ce que chaque h4 soit imbriqué sous un h3, et le h3 manquant confond la structure. La correction consiste à insérer le niveau intermédiaire manquant ou à rétrograder le h4 en h3. La cause la plus courante est de copier le design d'une maquette où la hiérarchie visuelle utilise trois tailles mais le système de design utilise quatre niveaux de titre ; revérifiez après chaque mise à jour de composant.

Titres vides

Un h2 sans contenu textuel (souvent parce qu'un widget JavaScript a supprimé le texte mais a gardé l'élément) apparaît dans la liste des titres du lecteur d'écran comme un titre sans étiquette, ce qui est déroutant et inutile. Soit peuplez le titre avec du texte, soit supprimez complètement l'élément de titre. Ceci est courant dans les applications à page unique où des éléments de remplacement sont rendus avant que les données ne se chargent ; rendez le titre uniquement lorsqu'il y a du contenu à y mettre.

Titres dans des emballages non sémantiques

Un titre enveloppé dans un div avec role="presentation" ou aria-hidden="true" est retiré de l'arbre d'accessibilité, ce qui peut cacher un titre autrement correct des lecteurs d'écran. Auditez les éléments parents de chaque titre pour vous assurer qu'ils ne retirent pas le titre de l'arbre d'accessibilité. CSS display:none et visibility:hidden retirent également le titre ; ne les utilisez qu'intentionnellement et jamais sur du contenu qui devrait être visible par le lecteur d'écran.

Utiliser ARIA quand le HTML natif suffirait

Ajouter role="heading" aria-level="2" à un div au lieu d'utiliser un élément h2 fonctionne pour l'accessibilité mais est une complexité inutile. Les éléments natifs h1-h6 obtiennent la sémantique de titre gratuitement, se rendent correctement dans les styles par défaut du navigateur, et survivent mieux aux bugs des lecteurs d'écran que les remplacements ARIA. La première règle d'ARIA (selon les pratiques d'écriture WAI-ARIA) est : n'utilisez pas ARIA quand le HTML natif fournit la même sémantique. Utilisez les éléments de titre natifs sauf si une contrainte de framework force réellement ARIA.

Confidentialité et gestion des données

Le HTML que vous collez reste dans votre navigateur tout au long de la vérification. Le DOMParser qui extrait les titres s'exécute en JavaScript sur votre machine ; les résultats sont rendus dans la page sous la zone de texte. Il n'y a pas d'étape de téléchargement, pas de traitement à distance, et pas de télémétrie sur quel HTML vous avez collé. Cela importe parce que le HTML que vous voulez le plus vérifier (modèles pré-lancement, sites clients sous NDA, pages d'administration internes) est exactement ce que vous ne devriez pas coller dans un validateur SaaS tiers.

Une fois la page chargée, l'outil fonctionne hors ligne. Vous pouvez vous déconnecter d'internet, coller du HTML, exécuter la vérification et examiner les résultats sans que votre balisage ne touche jamais une autre machine. La plupart des vérificateurs d'accessibilité cloud (PowerMapper, Tenon, Site Improve) exigent de télécharger l'URL ou le HTML de la page ; pour les pages confidentielles, c'est précisément le mode de défaillance à éviter.

Quand ne pas utiliser cet outil

Pour les audits WCAG complets (utilisez un outil complet)

La structure des titres est l'un des dizaines de critères WCAG. Pour un audit complet, utilisez axe DevTools (extension Chrome/Firefox gratuite de Deque), Lighthouse (intégré dans Chrome), WAVE (outil gratuit de WebAIM), ou une solution payante comme Tenon ou PowerMapper. Ceux-ci vérifient le contraste de couleur, le texte alt, l'utilisation d'ARIA, les étiquettes de formulaire, l'ordre de focus, et bien plus. Exécutez cet outil aux côtés, pas à la place, des outils complets.

Pour le contenu dynamique (testez le DOM rendu)

Si vos titres sont générés par JavaScript (React, Vue, Svelte, Angular), la source HTML statique ne contient pas les titres finaux. Vous devez coller le DOM rendu après l'exécution de JavaScript. Utilisez le DevTools du navigateur : ouvrez la page, ouvrez DevTools, onglet Éléments, faites un clic droit sur le body ou main, Copier outerHTML, puis collez cela dans ce vérificateur. Ou utilisez une extension de navigateur qui parcourt directement le DOM en direct.

Pour les pipelines CI/CD automatisés (utilisez une bibliothèque Node)

Si vous voulez que les vérifications de titres s'exécutent automatiquement à chaque commit ou pull request, intégrez axe-core, Pa11y, ou jest-axe dans votre suite de tests. Ils exécutent les vérifications de titres (et de nombreuses autres vérifications WCAG) sans tete dans CI. Cet outil navigateur est pour un usage interactif pendant le développement et la révision, pas pour l'automatisation. Les deux ont leur place ; utilisez l'outil navigateur pour les audits ponctuels et la bibliothèque CI pour la validation continue.

Pour l'accessibilité des documents PDF ou Word

Les PDF et documents Word ont leurs propres systèmes de balisage d'accessibilité (PDF/UA, les styles de titre Word). Ils n'utilisent pas les titres HTML, donc cet outil ne s'applique pas. Pour l'accessibilité PDF, utilisez le vérificateur d'accessibilité d'Adobe Acrobat Pro ou PAC 2024 (gratuit, axé sur PDF/UA). Pour Word, utilisez le vérificateur d'accessibilité intégré (onglet Révision). Convertissez d'abord en HTML si vous voulez utiliser cet outil, mais la conversion elle-même peut introduire des problèmes de titre.

Plus de questions

Est-il jamais correct de sauter un niveau de titre ?

Pas dans le contenu de document direct. WCAG 2.2 SC 1.3.1 implique que les titres doivent former une séquence hiérarchique. Le cas commun où cela ressemble à un saut est le plan de page commençant à h1 puis h2 dans la zone de contenu principal, tandis qu'une barre latérale ou navigation a également des h2 ; c'est correct car les deux sont des frères et sœurs sous le h1 de la page. La règle réelle est : ne sautez pas de niveaux dans un flux de contenu contigu. Le vérificateur ne signale que les vrais sauts.

Et si mon framework ne supporte qu'un seul niveau de titre ?

Certaines bibliothèques de composants rendent les titres à un niveau fixe (toujours h2, indépendamment de l'imbrication). La correction est d'exposer une prop de niveau sur le composant de titre (h2, h3, etc.) et de faire en sorte que les parents passent la valeur appropriée. Les frameworks comme React le font couramment ; si le votre ne le fait pas, ajoutez un aria-level sur le composant et utilisez role="heading" comme solution de contournement temporaire jusqu'à ce que vous puissiez refactoriser. À long terme, chaque composant de titre réutilisable doit accepter une prop de niveau.

L'outil vérifie-t-il les rôles ARIA comme role="heading" ?

Oui. Tout élément avec role="heading" et un attribut aria-level valide (1 à 6) est traité comme un titre au niveau indiqué. Les éléments natifs h1-h6 sont toujours préférés, mais les titres marqués ARIA sont également valides pour les lecteurs d'écran et sont vérifiés aux côtés des natifs.

Quelle est l'importance de la hiérarchie des titres par rapport aux autres critères WCAG ?

Très. L'enquête annuelle des utilisateurs de lecteurs d'écran de WebAIM trouve systématiquement que 67-70% des utilisateurs de lecteurs d'écran naviguent par titres comme leur méthode principale pour comprendre une page. Les mauvais titres bloquent effectivement l'une des principales méthodes de navigation d'accessibilité. Dans l'analyse annuelle WebAIM Million de WebAIM, les problèmes de titre sont parmi les cinq échecs d'accessibilité les plus courants sur le web. La combinaison d'un fort impact utilisateur et d'une détection facile en fait une priorité absolue.

Chaque page doit-elle avoir un h1 ?

Oui, avec de rares exceptions. Chaque document HTML complet devrait avoir exactement un h1 qui représente le titre de la page. L'exception est les fragments qui sont explicitement insérés dans une page plus grande (une signature d'email, un widget intégré dans une autre page) ; la page hôte fournit le h1 et le fragment commence à h2 ou plus bas. Pour les pages autonomes, un h1 manquant est un échec d'accessibilité clair.

Puis-je faire confiance à cet outil pour les audits de conformité légale ?

Pour la structure de titres spécifiquement, oui : les règles sont précises et l'outil les implémente avec précision. Pour la conformité WCAG globale, aucun outil automatisé seul ne suffit ; les tests manuels avec technologie d'assistance, la révision d'experts et les tests utilisateurs avec des utilisateurs handicapés sont requis pour les audits de qualité légale. Utilisez cet outil comme l'une de plusieurs entrées dans votre audit, pas comme la seule source de vérité pour la conformité.