Informations et relations

Ce que ce critère demande

Tout ce qui est perceptible en un coup d’œil — que ce grand texte en gras est un titre, que ces lignes forment un tableau de données, que ce groupe de champs correspond à « adresse de facturation », que cet astérisque indique un champ obligatoire — doit également être présent dans le code sous-jacent. Les lecteurs d’écran, les logiciels de contrôle vocal et les moteurs de reformatage ne voient que le balisage. Si une relation est purement visuelle (une police plus grande, une bordure plus épaisse, un retrait), les technologies d’assistance ne perçoivent rien.

Comment satisfaire ce critère

• Utiliser de véritables éléments de titre (<h1> à <h6>) dans un ordre hiérarchique logique — jamais un <div> stylisé pour simuler un titre.
• Baliser les listes avec <ul>, <ol> et <li> — non avec des paragraphes séparés par des sauts de ligne ou des caractères de puce.
• Utiliser <table> avec <th scope="col"> / <th scope="row"> pour les tableaux de données, avec <caption> décrivant l’objet du tableau.
• Chaque contrôle de formulaire doit avoir une étiquette programmatique : <label for="...">, aria-labelledby ou aria-label. Le texte de substitution n’est pas une étiquette.
• Regrouper les champs de formulaire connexes dans <fieldset> avec <legend>, ou utiliser role="group" avec aria-labelledby pour les composants personnalisés.
• Pour les figures et les légendes, utiliser <figure> et <figcaption>. Pour les paires définition/terme, utiliser <dl> / <dt> / <dd>.
• Indiquer les champs obligatoires à la fois visuellement (astérisque) et de façon programmatique (aria-required="true" ou l’attribut required).

Échecs courants

• <div class="heading-1"> au lieu de <h1> — l’apparence est correcte, mais le lecteur d’écran n’annonce rien.
• Tableaux de mise en page utilisés pour des colonnes visuelles, ou tableaux de données construits avec des grilles <div> sans cellules <th>.
• Champs de formulaire avec étiquettes uniquement en texte de substitution — l’étiquette disparaît au focus et les lecteurs d’écran peuvent ne pas l’annoncer.
• Puces simulées avec <p>•&nbsp;Élément</p> au lieu d’un vrai balisage de liste.
• Astérisques de champs obligatoires affichés en CSS rouge sans attribut aria-required ou required.
• Boutons radio visuellement regroupés sans <fieldset> / <legend>, laissant les utilisateurs de lecteurs d’écran face à des options flottantes sans contexte.
• Tableaux de données dont la ligne d’en-tête est stylisée en gras mais utilise <td>, et non <th>.

Pourquoi c’est important

Le critère 1.3.1 est le plus cité dans les audits WCAG après les critères 1.1.1 et 1.4.3. Chaque page générée par un CMS, chaque page d’atterrissage marketing, chaque composant de formulaire personnalisé tend à échouer sur au moins une partie de ce critère. La correction est presque toujours de l’HTML sémantique, pas ARIA — lorsqu’on a recours à role="heading" pour corriger un <div> qui aurait dû être un <h2>, la partie est déjà perdue.