WCAG 1.3.1 : Informations et relations

Ce que signifie cette règle

WCAG 1.3.1 — Informations et relations est un critère de niveau A relevant du principe « Perceptible ». Son exigence centrale est simple mais aux implications vastes : toute information ou relation communiquée visuellement doit également être exprimée d’une manière que les technologies d’assistance peuvent détecter et transmettre aux utilisateurs. Si votre conception utilise des indices visuels — retrait pour suggérer une liste, texte en gras pour marquer un champ obligatoire, couleur pour indiquer une erreur ou taille pour signaler un titre — ces mêmes sémantiques doivent exister dans le code sous-jacent.

Le critère s’applique à trois catégories de signification que le contenu web transmet régulièrement par la présentation :

• Informations — faits ou données communiqués sur la page, comme les champs de formulaire obligatoires ou les cellules de tableau qui partagent une relation.
• Structure — le schéma organisationnel du contenu, comme les hiérarchies de titres, les listes ordonnées ou non ordonnées et les tableaux de données.
• Relations — associations entre éléments, comme une étiquette et son champ de saisie, un en-tête de tableau et ses cellules de données, ou un terme et sa définition.

Une page satisfait au critère 1.3.1 lorsque chaque information structurelle ou relationnelle disponible pour un utilisateur voyant est soit encodée en HTML sémantique valide, soit exposée via un rôle, une propriété ou un état ARIA correct que les technologies d’assistance peuvent interpréter. Une page échoue lorsque la structure visuelle n’existe que dans le CSS ou les images, ou lorsque le balisage ARIA contredit la structure du DOM présentée ou en est absent.

Les exceptions officielles sont minimes. Le critère n’exige pas que toute décoration visuelle porte une signification sémantique — un formatage purement esthétique comme une bordure décorative ou une couleur d’arrière-plan n’a pas besoin d’équivalent programmatique. Cependant, tout formatage qu’un utilisateur interpréterait raisonnablement comme porteur de sens (astérisques pour les champs obligatoires, termes en gras dans un glossaire, étapes numérotées) doit avoir une expression programmatique correspondante.

Pourquoi c’est important

Les informations et les relations sous-tendent presque toutes les interactions qu’un utilisateur a avec une page web. Lorsque cette structure est enfermée dans la seule présentation visuelle, une part significative de la population est de fait exclue de la compréhension du contenu.

Les utilisateurs de lecteurs d’écran — généralement des personnes aveugles ou malvoyantes — naviguent dans les pages en interrogeant l’arbre d’accessibilité, construit à partir du HTML sémantique et d’ARIA. Lorsqu’un développeur utilise un <div> stylé pour ressembler à un titre au lieu d’un véritable <h2>, un utilisateur de lecteur d’écran qui saute de titre en titre avec la touche H le manquera complètement. Il se peut qu’il ne trouve jamais la section introduite. Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde vivent avec une forme de déficience visuelle, et des dizaines de millions s’appuient quotidiennement sur des lecteurs d’écran.

Les utilisateurs ayant des handicaps cognitifs bénéficient tout autant d’une structure claire. Des titres correctement imbriqués, un balisage de liste significatif et des contrôles de formulaire étiquetés réduisent la charge cognitive en fournissant des schémas prévisibles. Un lecteur d’écran annonçant « titre de niveau 2, Produits » suivi de « titre de niveau 3, Ordinateurs portables » fournit une carte cognitive de la page. Un mur uniforme de texte stylé sans ancrages structurels désoriente tout le monde, mais particulièrement les utilisateurs ayant des difficultés d’attention ou de mémoire.

Les utilisateurs ayant des limitations motrices qui dépendent de la navigation au clavier, de l’accès par contacteurs ou de logiciels de commande vocale dépendent eux aussi de la structure programmatique. Les logiciels de commande vocale comme Dragon NaturallySpeaking génèrent des cibles cliquables à partir des noms accessibles dérivés des étiquettes et des rôles — les champs de formulaire sans étiquettes associées ne peuvent tout simplement pas être ciblés de manière fiable par commande vocale.

Considérez un scénario concret : un portail patient d’hôpital affiche un tableau des prochains rendez-vous. Le tableau utilise l’alignement visuel et la couleur d’arrière-plan pour associer les dates aux médecins, mais les éléments <th> n’ont pas d’attributs scope et les cellules de données ne référencent pas les en-têtes. Un utilisateur aveugle avec un lecteur d’écran entend des valeurs de cellules isolées — « 9:00 AM », « Dr. Ayşe Kaya », « Cardiologie » — sans moyen de savoir quelle valeur appartient à quelle colonne. Il peut mal interpréter l’heure de son rendez-vous ou se présenter dans le mauvais service. L’utilisation correcte de scope='col' sur les en-têtes et d’attributs headers sur les cellules aurait rendu ces relations audibles.

Au-delà de l’accessibilité, le HTML structurel a une valeur SEO significative. Les robots des moteurs de recherche utilisent les hiérarchies de titres pour comprendre les sujets de la page, le balisage de liste pour identifier le contenu énuméré et les associations d’étiquettes pour comprendre la finalité des formulaires. Une page qui respecte 1.3.1 est presque toujours une page que les moteurs de recherche peuvent analyser et classer plus précisément.

Règles axe-core associées

Les règles axe-core suivantes correspondent directement aux violations de WCAG 1.3.1. Chaque règle cible un aspect spécifique de la structure ou des relations programmatiques :

• aria-required-children — Vérifie que les éléments avec certains rôles ARIA contiennent les rôles enfants requis. Par exemple, un role='list' doit contenir des enfants avec role='listitem'. Sans la structure enfant correcte, la relation entre un conteneur et ses éléments est rompue pour les technologies d’assistance.
• aria-required-parent — L’inverse de ce qui précède : vérifie que les éléments avec des rôles nécessitant un contexte parent spécifique ont effectivement ce parent. Un role='listitem' qui n’est pas à l’intérieur d’un role='list' ou d’un <ul>/<ol> est signalé car le contexte relationnel manque.
• aria-roles — Valide que toutes les valeurs d’attribut role sont des rôles ARIA valides. Un rôle invalide ou mal orthographié (par exemple, role='heading' au lieu d’utiliser un élément de titre, ou un rôle complètement inventé) signifie que la technologie d’assistance ne reçoit aucune information utile et peut ignorer complètement l’élément.
• definition-list — Vérifie que les éléments <dl> ne contiennent que les enfants autorisés : <dt>, <dd>, <div>, <script> et <template>. Insérer d’autres éléments comme <p> directement à l’intérieur d’un <dl> invalide la structure de relation terme-définition.
• dlitem — Vérifie que les éléments <dt> et <dd> ne sont utilisés qu’à l’intérieur d’éléments <dl>. Utiliser ces éléments en dehors de leur contexte parent requis détruit la signification sémantique de la paire terme-définition.
• heading-order — Signale les niveaux de titres qui sont sautés dans la structure du document (par exemple, passer de <h2> à <h4>). Bien que ce ne soit pas toujours un échec strict, sauter des niveaux induit les technologies d’assistance en erreur sur la structure hiérarchique de la page et perturbe les utilisateurs qui naviguent par les titres.
• label — Vérifie que chaque champ de formulaire a une étiquette associée de manière programmatique, soit via <label for='...'>, aria-label, aria-labelledby ou un élément <label> englobant. Un champ sans étiquette accessible refuse aux utilisateurs aveugles et aux utilisateurs de commande vocale les informations dont ils ont besoin pour comprendre quoi saisir.
• list — S’assure que les éléments <ul> et <ol> ne contiennent que des éléments <li> comme enfants directs (plus <script> et <template>). Des éléments enfants invalides rompent la structure de liste que les lecteurs d’écran utilisent pour annoncer le nombre d’éléments et leurs positions.
• listitem — Vérifie que les éléments <li> ne sont utilisés qu’à l’intérieur de conteneurs <ul>, <ol> ou role='list'. Des éléments de liste orphelins perdent entièrement leur signification sémantique.
• scope-attr-valid — Valide que l’attribut scope sur les éléments <th> ne contient que les valeurs autorisées : col, row, colgroup ou rowgroup. Une valeur de scope invalide ou absente sur un tableau de données complexe signifie que les lecteurs d’écran ne peuvent pas annoncer de manière fiable quel en-tête s’applique à une cellule de données donnée.
• td-headers-attr — Vérifie que lorsque les cellules de données utilisent l’attribut headers, chaque ID référencé existe réellement dans le même tableau et appartient à une cellule d’en-tête. Des références rompues ou manquantes coupent la relation programmatique entre les données et leur en-tête descriptif, laissant les utilisateurs de lecteurs d’écran sans contexte.

Notez que les outils automatisés comme axe-core ne peuvent pas détecter toutes les violations de 1.3.1. Par exemple, un développeur peut utiliser un <div> visuellement stylé avec role='list' et des éléments enfants role='listitem' correctement structurés — axe validera cela — mais un testeur humain peut découvrir que le retrait visuel implique une sous-liste imbriquée qui n’est pas représentée dans la structure ARIA. Chaque fois que la hiérarchie visuelle est complexe, l’inspection manuelle et les tests avec lecteur d’écran sont des compléments essentiels à l’analyse automatisée.

Comment tester

1. Analyse automatisée avec axe DevTools ou Lighthouse : Installez l’extension de navigateur axe DevTools (Chrome ou Firefox). Ouvrez la page à tester, ouvrez les DevTools, accédez à l’onglet axe et lancez une analyse de page complète. Filtrez les résultats par le tag wcag131 ou examinez tous les problèmes étiquetés « Info and Relationships ». Recherchez spécifiquement les violations des onze règles axe listées ci-dessus. Dans Lighthouse (panneau Audits de Chrome DevTools), lancez un audit d’accessibilité et vérifiez la catégorie « Accessibility » pour les échecs liés à l’ordre des titres, aux étiquettes et aux listes. Notez tous les éléments signalés et leurs sélecteurs DOM pour la remédiation.
2. Revue manuelle de la structure des titres : Utilisez l’extension de navigateur HeadingsMap ou le panneau « Headings » dans axe DevTools pour afficher la structure complète des titres de la page. Vérifiez que la structure est logique et hiérarchique — elle doit se lire comme une table des matières bien structurée. Confirmez qu’aucun niveau de titre n’est sauté et que le texte des titres est significatif et non simplement un style visuel appliqué à des éléments qui ne sont pas des titres.
3. Vérification des étiquettes de formulaire : Parcourez au clavier chaque élément de formulaire interactif de la page. Pour chaque input, select et textarea, confirmez qu’une étiquette visible est présente et qu’elle est associée de manière programmatique (inspectez l’élément dans DevTools et recherchez une paire for/id correspondante, ou un aria-label/aria-labelledby). Utilisez l’arbre d’accessibilité dans Chrome DevTools (panneau Elements → onglet Accessibility) pour confirmer le nom accessible calculé pour chaque contrôle.
4. Tests avec lecteur d’écran NVDA + Firefox : Lancez NVDA et ouvrez la page dans Firefox. Appuyez sur H pour parcourir les titres et vérifiez que les niveaux de titres annoncés correspondent à la hiérarchie visuelle. Appuyez sur F pour passer d’un champ de formulaire à l’autre et confirmez que l’étiquette de chaque champ est annoncée. Appuyez sur T pour naviguer dans les tableaux et parcourez les cellules avec les flèches, en écoutant les annonces des en-têtes. Appuyez sur L pour parcourir les listes et confirmez que le nombre d’éléments est annoncé.
5. Tests avec lecteur d’écran VoiceOver + Safari (macOS/iOS) : Activez VoiceOver (Cmd+F5 sur macOS). Ouvrez le Rotor (Ctrl+Option+U) et inspectez les sections Headings, Links, Form Controls et Tables. Confirmez que tous les éléments structurels apparaissent dans le Rotor et que les noms annoncés sont significatifs et exacts.
6. Tests avec lecteur d’écran JAWS + Chrome : Ouvrez JAWS et la page dans Chrome. Utilisez la liste des titres de JAWS (Insert+F6) pour examiner l’arborescence des titres. Utilisez Insert+F5 pour les champs de formulaire afin de vérifier les associations d’étiquettes. Naviguez dans les tableaux avec les touches fléchées et confirmez que JAWS annonce les en-têtes de colonnes et de lignes pour chaque cellule de données.
7. Vérification des relations d’en-têtes de tableau : Identifiez tous les tableaux de données sur la page. Pour les tableaux simples, vérifiez que les éléments <th> ont des attributs scope appropriés. Pour les tableaux complexes avec des en-têtes à plusieurs niveaux, vérifiez que les cellules de données utilisent l’attribut headers en référencant les valeurs id correctes. Suivez visuellement chaque cellule jusqu’à ses en-têtes de ligne et de colonne logiques, puis confirmez que le même chemin est représenté dans le code.

Comment corriger

Titres visuels implémentés comme div stylés — Incorrect

<!-- Heading conveyed only through CSS font-size and font-weight -->
<div class='section-title'>Our Services</div>
<div class='subsection-title'>Web Development</div>
<p>We build fast, accessible websites.</p>

Titres visuels implémentés comme div stylés — Correct

<!-- Semantic heading elements expose hierarchy to assistive technologies -->
<h2>Our Services</h2>
<h3>Web Development</h3>
<p>We build fast, accessible websites.</p>

Champ de formulaire sans étiquette associée — Incorrect

<!-- The placeholder is not a substitute for a label; it disappears on input -->
<p>Email Address *</p>
<input type='email' placeholder='Enter your email' />

Champ de formulaire sans étiquette associée — Correct

<!-- The for attribute ties the label to the input by matching id -->
<label for='email'>Email Address <span aria-hidden='true'>*</span><span class='sr-only'>(required)</span></label>
<input type='email' id='email' aria-required='true' />

Tableau de données sans attributs scope — Incorrect

<!-- Headers have no scope; screen readers cannot associate columns with data -->
<table>
  <tr>
    <th>Tarih</th>
    <th>Doktor</th>
    <th>Klinik</th>
  </tr>
  <tr>
    <td>15 Temmuz 2025</td>
    <td>Dr. Ayşe Kaya</td>
    <td>Kardiyoloji</td>
  </tr>
</table>

Tableau de données sans attributs scope — Correct

<!-- scope='col' tells screen readers each th describes its entire column -->
<table>
  <caption>Yaklaşan Randevular</caption>
  <thead>
    <tr>
      <th scope='col'>Tarih</th>
      <th scope='col'>Doktor</th>
      <th scope='col'>Klinik</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>15 Temmuz 2025</td>
      <td>Dr. Ayşe Kaya</td>
      <td>Kardiyoloji</td>
    </tr>
  </tbody>
</table>

Éléments de liste utilisés en dehors d’un conteneur de liste — Incorrect

<!-- li elements without a parent ul or ol have no semantic meaning -->
<div class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</div>

Éléments de liste utilisés en dehors d’un conteneur de liste — Correct

<!-- Wrapping ul gives screen readers item count and navigation context -->
<ul class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</ul>

Erreurs courantes

• Utiliser uniquement les propriétés CSS font-size et font-weight pour créer l’apparence visuelle de titres sur des éléments <div> ou <span>, sans jamais ajouter role='heading' et aria-level ni convertir en véritables éléments <h1>–<h6> — les lecteurs d’écran ne peuvent pas découvrir ces éléments comme des titres navigables.
• Utiliser le texte de placeholder comme seule étiquette pour les champs de formulaire, ce qui fait disparaître l’étiquette dès que l’utilisateur commence à saisir, laissant le champ sans étiquette pendant toute la durée de la saisie — associez toujours les champs à un élément <label> persistant.
• Marquer les champs obligatoires avec un astérisque rouge (*) qui n’est expliqué que dans une légende visuelle en haut du formulaire, sans ajouter aria-required='true' ni inclure « obligatoire » dans l’étiquette programmatique, de sorte que les utilisateurs de lecteurs d’écran reçoivent la même information.
• Appliquer list-style: none via CSS à un <ul> sans comprendre que certains lecteurs d’écran (en particulier Safari + VoiceOver) peuvent alors cesser d’annoncer l’élément comme une liste — si la sémantique de liste est significative, ajoutez explicitement role='list' pour la préserver.
• Sauter des niveaux de titres — par exemple, placer un <h4> directement après un <h2> parce que le designer voulait un texte plus petit — plutôt que d’utiliser le niveau de titre correct et de contrôler l’apparence visuelle via CSS.
• Construire des tableaux de données complexes avec des cellules fusionnées (colspan/rowspan) sans ajouter l’attribut headers sur les cellules de données, laissant les utilisateurs de lecteurs d’écran incapables de déterminer quel en-tête régit une cellule fusionnée ambiguë.
• Utiliser des éléments <table> à des fins de mise en page puis ajouter role='presentation' de manière incohérente — certaines cellules contiennent encore des en-têtes qui sont annoncés hors contexte, ce qui perturbe les utilisateurs qui ne peuvent pas voir que le tableau est purement décoratif.
• Envelopper une paire <dt>/<dd> dans un <p> ou un <div> qui est un enfant direct d’un <dl> sans comprendre que seuls les wrappers <div> sont autorisés à l’intérieur d’un <dl> en HTML5, et que le mélange d’autres éléments de bloc détruit la structure de la liste de définitions.
• Ajouter aria-labelledby sur un champ qui référence un ID n’existant pas dans le DOM, ou référencer l’ID d’un élément non textuel — le nom accessible calculé devient vide et le champ est de fait sans étiquette pour les technologies d’assistance.
• Supposer que parce qu’une page est visuellement correcte et obtient un score Lighthouse supérieur à 90, elle est conforme à 1.3.1 — les outils automatisés ne peuvent pas détecter toutes les violations structurelles, comme les relations d’imbrication visuelle qui ne sont pas reflétées dans la hiérarchie des rôles ARIA, ce qui rend indispensables les vérifications manuelles et avec lecteur d’écran.

Lien avec la réglementation d’accessibilité de la Turquie

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é web alignées sur WCAG 2.2 pour un large éventail d’entités opérant en Turquie. WCAG 1.3.1 est un critère de niveau A, ce qui signifie qu’il se situe au niveau fondamental de conformité — le niveau minimal acceptable d’accessibilité — et est donc entièrement obligatoire pour toutes les entités couvertes par la circulaire.

La circulaire définit deux calendriers de conformité. Les institutions publiques — y compris les organismes de l’administration centrale, les municipalités, les universités d’État et les hôpitaux publics — doivent atteindre une conformité complète de niveau A dans l’année suivant l’entrée en vigueur de la circulaire. Les entités du secteur privé couvertes par la réglementation disposent d’un délai de deux ans pour se conformer. Cependant, l’obligation n’est facultative pour aucun des deux groupes : la non-conformité expose les entités concernées à un contrôle réglementaire et à d’éventuelles mesures d’exécution.

Les entités du secteur privé explicitement couvertes par la circulaire comprennent les plateformes de commerce électronique, les banques et institutions financières, les hôpitaux privés et prestataires de soins de santé, les entreprises de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage agréées, les entreprises de transport privées et les écoles privées opérant sous autorisation du ministère de l’Éducation nationale (MoNE). Toute entité de ce type exploitant un site web public ou une application web mobile doit s’assurer que 1.3.1 est respecté sur l’ensemble de ses propriétés numériques.

Pour la conformité pratique, 1.3.1 est l’un des critères de niveau A les plus impactants car il régit la structure fondamentale de la page. Un site de commerce électronique turc dont les pages de catégories de produits utilisent des éléments <div> stylés pour les titres, dont les champs du formulaire de paiement manquent d’associations d’étiquettes ou dont le récapitulatif de commande est un tableau non structuré sans attributs scope échouerait de manière globale à 1.3.1. La remédiation n’est pas seulement une obligation légale — elle améliore directement l’expérience des quelque 700,000 personnes aveugles et malvoyantes ou plus en Turquie qui s’appuient sur des technologies d’assistance pour faire leurs achats, gérer leurs opérations bancaires, accéder aux soins de santé et interagir avec les services publics en ligne.

Les organisations souhaitant démontrer leur conformité sont invitées à effectuer à la fois des analyses automatisées avec axe-core et des audits manuels avec lecteur d’écran couvrant l’ensemble de leur contenu numérique. L’accessibilité structurelle — le fondement que 1.3.1 impose — doit être intégrée dans les systèmes de conception et les bibliothèques de composants afin que la conformité soit maintenue au fur et à mesure de la création et de la mise à jour du contenu, plutôt que traitée comme un exercice de remédiation ponctuel.