WCAG 2.4.6 : Titres et libellés

Ce que signifie cette règle

WCAG 2.4.6 stipule : « Les titres et les libellés décrivent le sujet ou la finalité. » En substance, ce critère exige que tout titre (<h1> à <h6>) ou libellé (<label>, aria-label, aria-labelledby) qui apparaît sur une page soit suffisamment descriptif pour communiquer le sujet du contenu qu’il introduit ou la finalité du contrôle qu’il identifie.

Ce critère n’exige pas que des titres ou des libellés soient présents — cette obligation est couverte par d’autres critères de succès tels que 1.3.1 (Informations et relations) et 2.4.2 (Titre de page). Ce que 2.4.6 régit, c’est la qualité des titres et des libellés qui existent déjà : lorsqu’ils sont présents, ils doivent être significatifs. Un titre qui indique « Section 1 » ou un libellé qui indique « Champ » ne dit rien d’utile aux utilisateurs sur le contenu qui suit ou sur la saisie qu’il décrit. À l’inverse, « Votre adresse de livraison » ou « Résumé du budget mensuel » orientent immédiatement les utilisateurs.

Les libellés dans ce contexte incluent non seulement l’élément HTML <label> associé aux contrôles de formulaire, mais aussi tout mécanisme de labellisation programmatique : aria-label, aria-labelledby, l’attribut title lorsqu’il est utilisé comme nom accessible, et l’élément legend pour les ensembles de champs (fieldsets). Tous ceux qui sont exposés aux technologies d’assistance doivent décrire clairement la finalité du contrôle associé.

Un échec se produit lorsqu’un titre ou un libellé est tellement générique, ambigu ou peu informatif qu’un utilisateur ne peut pas déterminer de quoi traite la section ou le contrôle sans lire le contexte environnant. Par exemple, un formulaire avec trois champs de saisie tous libellés « Saisir ici » ne respecte pas ce critère, pas plus qu’une page qui utilise des titres répétés tels que « Plus d’infos » pour chaque sous-section. De même, un titre qui est techniquement présent dans le DOM mais induit complètement l’utilisateur en erreur — par exemple en intitulant une section de formulaire de contact « Actualités et mises à jour » — constitue également un échec.

Il existe une exception officielle importante : WCAG 2.4.6 ne s’applique que lorsque des titres et des libellés sont utilisés. Si une page n’a légitimement aucun titre (par exemple, un document très court avec un seul sujet) ou un contrôle de formulaire sans libellé visible ou programmatique (ce qui serait détecté par 1.3.1 à la place), 2.4.6 ne s’applique pas en tant que tel. La portée de ce critère concerne strictement le caractère descriptif, pas la présence.

Pourquoi c’est important

Des titres et des libellés descriptifs bénéficient à un public remarquablement large, mais l’impact est particulièrement fort pour les personnes handicapées qui s’appuient sur la structure pour naviguer.

Les utilisateurs de lecteurs d’écran — principalement des personnes aveugles ou ayant une déficience visuelle sévère — naviguent couramment dans les pages en sautant de titre en titre à l’aide de touches de raccourci (H dans NVDA/JAWS, le Rotor dans VoiceOver). Si les titres sont vagues ou trompeurs, cette stratégie de navigation s’effondre complètement. Une personne aveugle arrivant sur un portail de services publics qui utilise « Section A », « Section B » et « Section C » comme titres doit lire chaque mot de chaque section de manière séquentielle pour trouver ce dont elle a besoin, ce qui élimine l’avantage d’efficacité que les titres sont censés fournir. Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, ce qui en fait une population mondiale substantielle.

Les personnes ayant des handicaps cognitifs, y compris celles ayant des troubles de l’attention, des troubles de la mémoire ou des troubles d’apprentissage, dépendent fortement de libellés et de titres clairs et prévisibles pour réduire la charge cognitive. Lorsqu’un champ de formulaire est simplement libellé « Nom » sur une page qui recueille à la fois le nom d’une entreprise et le nom d’une personne de contact, une personne ayant une déficience cognitive peut ne pas être en mesure de lever l’ambiguïté à partir du seul contexte, ce qui entraîne des erreurs et de la frustration.

Les utilisateurs ayant des déficiences motrices qui s’appuient sur un accès par contacteur, des logiciels de suivi oculaire ou le contrôle vocal (comme Dragon NaturallySpeaking) bénéficient de libellés descriptifs, car ils peuvent activer un champ de formulaire spécifique en prononçant le nom de son libellé. Si plusieurs champs partagent le même texte de libellé, le logiciel de contrôle vocal ne peut pas les distinguer, obligeant l’utilisateur à effectuer des étapes supplémentaires physiquement éprouvantes.

Considérez un scénario réel : une personne utilisant un lecteur d’écran visite une page de paiement d’un site de commerce électronique. La page contient trois sections d’adresse — facturation, livraison et adresse du destinataire d’un cadeau — mais chaque section utilise le même titre générique « Adresse » et chaque ensemble de champs utilise les mêmes libellés : « Rue », « Ville », « Code postal ». Sans titres et libellés uniques et descriptifs, l’utilisateur de lecteur d’écran ne peut pas déterminer quel groupe de champs il est en train de remplir, ce qui augmente considérablement le risque d’erreurs de commande et la probabilité d’abandonner complètement l’achat.

Au-delà de l’accessibilité, des titres descriptifs offrent une valeur SEO substantielle. Les moteurs de recherche utilisent la structure des titres comme un signal fort pour comprendre le contenu d’une page et le faire correspondre aux requêtes des utilisateurs. Des titres significatifs aident les moteurs de recherche à indexer les pages plus précisément et peuvent améliorer les taux de clics dans les résultats de recherche, où les titres sont souvent affichés comme texte d’aperçu. Cela aligne directement les incitations commerciales sur les exigences d’accessibilité.

Règles Axe-core associées

WCAG 2.4.6 nécessite des tests manuels, car aucun outil automatisé ne peut déterminer de manière fiable si un titre ou un libellé est descriptif. Le caractère descriptif est un jugement sémantique et contextuel — un titre qui indique « Produits » peut être parfaitement descriptif sur une page et complètement ambigu sur une autre. Les analyseurs automatisés peuvent détecter la présence ou l’absence de titres et de libellés, mais ils ne peuvent pas évaluer si le texte de ces titres et libellés est significatif sans interprétation humaine.

• Revue manuelle du texte des titres : Axe-core signalera les titres manquants ou une imbrication incorrecte (via des règles comme heading-order), mais il ne peut pas signaler un titre qui indique « Cliquez ici » ou « Section sans titre » comme une violation de 2.4.6. Un testeur humain doit lire chaque titre isolément — comme un utilisateur de lecteur d’écran le rencontrerait en naviguant par titres — et évaluer s’il communique le sujet du contenu qui suit.
• Revue manuelle du texte des libellés de formulaire : La règle label d’axe-core vérifie que chaque champ de formulaire a un libellé associé, mais elle n’évalue pas si le texte de ce libellé est descriptif. Un élément label qui ne contient qu’un caractère de remplissage, un caractère d’icône ou un mot générique comme « Saisie » passera les vérifications automatisées tout en ne respectant pas 2.4.6. La revue manuelle nécessite de lire chaque libellé et de confirmer qu’il décrit avec précision la finalité de son contrôle associé.
• Revue manuelle des valeurs aria-label et aria-labelledby : De même, la famille de règles aria-label-is-accessible d’axe-core confirme que les libellés ARIA sont syntaxiquement valides et que les éléments référencés existent, mais elle n’évalue pas si le texte du libellé est sémantiquement significatif ou descriptif de la finalité du contrôle.
• Détection des libellés dupliqués : Bien que certains outils puissent signaler des textes de libellés dupliqués sur une page, ils ne peuvent pas déterminer si la duplication est intentionnelle et appropriée (deux champs ayant la même finalité sur différentes lignes d’un tableau) ou un véritable échec de caractère descriptif où plusieurs contrôles distincts partagent un libellé ambigu. Une revue manuelle est nécessaire pour faire cette distinction.

Comment tester

1. Exécuter d’abord une analyse automatisée : Utilisez axe DevTools (extension de navigateur) ou Lighthouse dans Chrome DevTools pour identifier les problèmes structurels de titres ou de libellés que les outils automatisés peuvent détecter, tels que des libellés manquants, des niveaux de titres sautés ou des éléments de titre vides. Bien qu’il ne s’agisse pas de violations directes de 2.4.6, ils indiquent des zones à examiner plus attentivement lors de la revue manuelle. Notez chaque titre et chaque contrôle libellé signalé ou identifié dans le rapport.
2. Extraire la liste des titres : Utilisez une extension de navigateur telle que l’extension HeadingsMap (disponible pour Firefox et Chrome) ou l’outil WAVE pour générer une liste plate de tous les titres de la page, dépourvue de leur contenu environnant. Lisez cette liste comme s’il s’agissait d’une table des matières. Demandez-vous : un utilisateur pourrait-il comprendre la structure et les principaux sujets de cette page à partir des seuls titres, sans lire le texte du corps ? Si un titre est ambigu ou peu informatif pris isolément, il s’agit d’un échec de 2.4.6.
3. Tester avec NVDA et Firefox : Ouvrez la page et appuyez sur H pour naviguer de titre en titre. Écoutez chaque annonce de titre et évaluez s’il décrit le contenu qui suit. Appuyez ensuite sur F pour parcourir les champs de formulaire et écoutez le libellé annoncé pour chaque champ. Relevez tout titre ou libellé qui ne décrit pas clairement son sujet ou sa finalité.
4. Tester avec VoiceOver et Safari (macOS/iOS) : Utilisez le Web Rotor (VO+U) pour ouvrir la liste des titres et la liste des contrôles de formulaire. Parcourez chaque liste et évaluez le caractère descriptif de chaque élément indépendamment du contexte de la page. Sur iOS, utilisez un balayage à trois doigts pour naviguer par titres dans le Rotor.
5. Tester avec JAWS et Chrome : Appuyez sur H pour naviguer entre les titres et utilisez le mode Formulaires (F) pour vous déplacer entre les contrôles de formulaire. Utilisez la boîte de dialogue Liste des titres de JAWS (Insert+F6) pour afficher tous les titres dans une liste plate, ce qui reproduit la façon dont un utilisateur de lecteur d’écran analyserait la structure de la page.
6. Évaluer les libellés de formulaire isolément : Pour chaque contrôle de formulaire, masquez ou ignorez tout le contexte environnant et lisez uniquement le libellé programmatique (texte de libellé visible, aria-label ou cible aria-labelledby). Confirmez que le libellé seul suffit à comprendre quelle information doit être saisie ou quelle action le contrôle effectue.
7. Vérifier la duplication des textes de titres ou de libellés : Recherchez sur la page des textes de titres répétés (par exemple, plusieurs titres « Lire la suite » ou plusieurs sections « En savoir plus »). Si le même texte est utilisé pour des titres ou des libellés qui se réfèrent à des sujets ou des contrôles différents, il s’agit d’un échec de 2.4.6.

Comment corriger

Titres de section génériques — Incorrect

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Titres de section génériques — Correct

<!-- Each heading now describes the actual topic of its section,
     enabling screen reader users to jump directly to what they need -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Libellés de formulaire ambigus — Incorrect

<!-- A checkout form with two address blocks, both using identical labels -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

Libellés de formulaire ambigus — Correct

<!-- Legends now distinguish the two fieldsets; labels remain short because
     the legend provides the distinguishing context programmatically -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

Libellé ARIA non descriptif sur un bouton icône — Incorrect

<!-- aria-label provides a label but it does not describe the button's purpose -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Libellé ARIA non descriptif sur un bouton icône — Correct

<!-- aria-label now clearly communicates what activating the button will do -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Titres ou liens « Read More » répétés — Incorrect

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Titres ou liens « Read More » répétés — Correct

<!-- Each article has a unique, descriptive heading that identifies its topic -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Erreurs courantes

• Utiliser des titres positionnels ou ordinaux tels que « Étape 1 », « Étape 2 », « Section A » sans texte descriptif : ces titres indiquent seulement à l’utilisateur où il se trouve dans une séquence, pas de quoi traite la section. Associez toujours les indicateurs de séquence à un syntagme nominal descriptif, par exemple « Étape 2 : Vérifiez votre adresse e-mail ».
• Donner à toutes les cartes ou tous les composants d’article sur une page de liste le même texte de titre (par exemple, chaque fiche produit a un <h3> qui indique simplement « Produit ») : chaque titre de carte doit identifier de manière unique ce produit, cet article de blog ou cet élément spécifique.
• Utiliser le texte d’espace réservé comme nom accessible pour un champ de formulaire (en s’appuyant sur l’attribut placeholder au lieu d’un élément <label> ou d’un aria-label) : les espaces réservés disparaissent lors de la saisie et ne sont pas annoncés de manière fiable par tous les lecteurs d’écran comme noms accessibles. Même lorsqu’un espace réservé existe, un libellé descriptif distinct est requis.
• Écrire un aria-label qui ne fait que reformuler le type d’élément plutôt que sa finalité, comme aria-label='input' sur un champ de texte ou aria-label='button' sur un bouton : le libellé doit décrire ce que fait le contrôle ou quelle valeur il recueille, et non le type d’élément qu’il est.
• Utiliser le texte d’infobulle ou les attributs title comme seul libellé pour un contrôle de formulaire en supposant que cela satisfait 2.4.6 : les libellés basés sur title sont souvent inaccessibles aux utilisateurs uniquement au clavier et ne sont pas annoncés de manière cohérente par les lecteurs d’écran. Fiez-vous plutôt à des éléments <label> visibles ou à aria-label.
• Libeller des champs de recherche uniquement par « Rechercher » sur une page où plusieurs périmètres de recherche existent (par exemple, une recherche sur l’ensemble du site et une recherche dans un tableau de données) : lorsque deux contrôles effectuent des recherches différentes, chaque libellé doit préciser le périmètre, comme « Rechercher tous les produits » et « Rechercher dans l’historique des commandes ».
• Appliquer le même texte de titre à la fenêtre modale qu’au titre principal de la page : les titres de modale doivent décrire la tâche ou le contenu spécifique de la boîte de dialogue (par exemple, « Confirmez votre annulation ») plutôt que d’hériter du titre de la page, ce qui serait déroutant pour les utilisateurs de lecteurs d’écran naviguant dans la boîte de dialogue.
• Omettre un <legend> descriptif pour des groupes de boutons radio ou de cases à cocher tout en fournissant des libellés pour les options individuelles : le <legend> fournit un contexte essentiel qui rend chaque libellé individuel significatif. « Oui » et « Non » en tant que libellés d’options isolés sont peu informatifs sans une légende telle que « Acceptez-vous les conditions générales ? »
• Tronquer le texte d’un titre dans le DOM pour des raisons de design visuel (par exemple, un titre qui ne contient qu’une icône ou un seul mot parce que le texte complet se trouve dans des éléments visuels adjacents) : le titre programmatique doit être entièrement descriptif, car les utilisateurs de lecteurs d’écran l’entendent sans voir la mise en page visuelle environnante.
• Supposer que parce qu’un libellé est visible pour les utilisateurs voyants, il est donc suffisamment descriptif pour tous les utilisateurs : un libellé qui s’appuie sur la position spatiale (par exemple, un en-tête de colonne dans une grille personnalisée où la signification du libellé dépend de la visualisation de sa relation avec les cellules environnantes) peut être visuellement clair mais ne pas transmettre la même information de manière programmatique. Vérifiez toujours que le nom accessible seul est suffisant.

Lien avec la réglementation turque en matière d’accessibilité

La Circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des obligations obligatoires en matière d’accessibilité numérique pour un large éventail d’entités publiques et privées opérant en Turquie. La Circulaire fait explicitement référence à WCAG 2.1 niveau AA comme norme technique de conformité, et les exigences de niveau AA de WCAG 2.2 — qui est rétrocompatible avec WCAG 2.1 au niveau AA — sont fortement encouragées et requises pour les entités souhaitant obtenir le Logo d’accessibilité (Erişilebilirlik Logosu) officiel délivré par le ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.4.6 est un critère de niveau AA, ce qui signifie qu’il relève pleinement du champ de ce que les entités concernées doivent traiter pour atteindre une conformité complète. Les types d’entités suivants sont couverts par la Circulaire présidentielle : les institutions publiques et les organismes gouvernementaux ; les plateformes de commerce électronique ; les banques et institutions financières ; les hôpitaux et prestataires de soins de santé ; les opérateurs de télécommunications comptant 200,000 abonnés ou plus ; les agences de voyage ; les entreprises de transport privé ; et les écoles privées autorisées par le ministère de l’Éducation nationale (Millî Eğitim Bakanlığı).

Pour ces entités, ne pas fournir de titres et de libellés descriptifs comporte un risque réglementaire concret. Un portail gouvernemental avec des titres de section vagues empêche les citoyens handicapés d’accéder aux services publics, ce qui est en contradiction directe avec l’objectif déclaré de la Circulaire d’assurer l’égalité d’accès. Un site de commerce électronique avec des libellés de formulaire ambigus dans son parcours de paiement peut empêcher des utilisateurs ayant des déficiences visuelles ou cognitives de finaliser leurs achats, constituant un obstacle à la participation économique que la Circulaire vise à éliminer.

Les entités souhaitant obtenir l’Erişilebilirlik Logosu doivent démontrer leur conformité au moyen d’un audit d’accessibilité, et 2.4.6 fait partie des critères que les auditeurs évalueront manuellement. Comme ce critère nécessite un jugement humain — les outils automatisés ne peuvent pas évaluer le caractère descriptif — les organisations devraient inclure une revue manuelle structurée de tous les titres et libellés de formulaire comme partie standard de leur processus d’audit d’accessibilité. Intégrer cette revue dans les flux de travail de gestion de contenu et les systèmes de design, plutôt que de la traiter comme une tâche d’audit ponctuelle, est la stratégie la plus efficace pour maintenir une conformité continue à mesure que le contenu évolue au fil du temps.