WCAG 3.3.2 : Libellés ou instructions

Ce que signifie cette règle

Le critère de succès 3.3.2 des WCAG — Étiquettes ou instructions (Niveau A) stipule : « Des étiquettes ou des instructions sont fournies lorsque le contenu nécessite une saisie de l’utilisateur. » En pratique, chaque champ de formulaire, contrôle de saisie, zone de texte et élément select qui demande à un utilisateur de saisir ou de sélectionner une information doit avoir une étiquette visible et significative ou un ensemble d’instructions qui clarifie la finalité du champ avant que l’utilisateur n’interagisse avec lui.

Le critère est volontairement large dans sa portée. Il couvre tout mécanisme par lequel un utilisateur fournit des données : les éléments <input> de tous types (text, email, password, number, date, checkbox, radio, file upload), les éléments <textarea> pour le texte multi‑ligne, et les listes déroulantes <select>. Il s’applique également aux contrôles interactifs personnalisés construits avec des rôles ARIA tels que role='combobox' ou role='listbox'.

Une étiquette peut être fournie de plusieurs façons qui satisfont à ce critère. La plus robuste est un élément <label> associé de manière programmatique, visuellement présent et lié au contrôle via une paire for/id correspondante. Alternativement, un texte d’étiquette visible peut être associé à l’aide de aria-labelledby pointant vers un élément existant, ou des instructions supplémentaires peuvent être reliées avec aria-describedby. L’exigence clé est que l’étiquette ou l’instruction soit fournie — elle doit exister sous une forme que l’utilisateur peut percevoir. Le texte d’espace réservé (placeholder) seul ne satisfait pas ce critère, car il disparaît dès que l’utilisateur commence à taper et n’est pas transmis de manière fiable par toutes les technologies d’assistance comme étiquette persistante.

Un succès exige que chaque champ de saisie ait une étiquette visible (ou au minimum déterminable de manière programmatique), présente avant que l’utilisateur ne s’engage à remplir le champ, et suffisamment descriptive pour indiquer quelles données sont attendues. Un échec se produit lorsqu’un champ n’a aucune étiquette, lorsque la seule étiquette est un attribut placeholder, lorsque l’étiquette est visuellement présente mais non associée de manière programmatique, ou lorsque les instructions sur le format requis (par exemple, « Saisir la date au format JJ/MM/AAAA ») sont totalement absentes.

Les WCAG mentionnent une exception étroite : lorsqu’un formulaire contient un seul champ évident — comme une barre de recherche globale avec un bouton d’envoi clairement étiqueté directement adjacent — le contexte lui‑même peut fournir des instructions suffisantes. Cependant, cette exception est limitée et ne doit pas être utilisée comme justification générale pour omettre les étiquettes dans les formulaires comportant plusieurs champs.

Pourquoi c’est important

Les étiquettes de formulaire sont la fonctionnalité d’accessibilité la plus déterminante pour un large éventail d’utilisateurs. Leur absence crée des obstacles qui peuvent rendre impossible pour de nombreuses personnes de finaliser des transactions, de s’inscrire à des services ou de contacter une organisation.

Pour les personnes aveugles ou malvoyantes qui s’appuient sur des lecteurs d’écran, un champ sans étiquette est simplement annoncé comme « zone de texte » ou « vide » sans contexte. L’utilisateur n’a aucun moyen de savoir s’il doit saisir son nom, son adresse e‑mail ou son numéro de carte bancaire. Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, et des millions d’entre elles utilisent des lecteurs d’écran comme principal moyen d’interagir avec le web.

Pour les personnes ayant des troubles cognitifs et d’apprentissage — y compris la dyslexie, le TDAH et les troubles de la mémoire — le texte d’espace réservé est particulièrement problématique. Comme les placeholders disparaissent au focus ou à la saisie, une personne qui fait une pause au milieu d’un formulaire n’a plus de référence sur ce qui était attendu dans un champ qu’elle a déjà commencé à remplir. Elle est obligée d’effacer le champ pour relire l’instruction, ce qui introduit confusion et frustration. Des étiquettes visibles et persistantes éliminent entièrement cette charge cognitive.

Pour les personnes ayant un handicap moteur qui naviguent au clavier, avec un dispositif de commande ou par la voix, les étiquettes remplissent une fonction supplémentaire : elles fournissent les mots prononcés utilisés pour activer un champ via un logiciel de commande vocale tel que Dragon NaturallySpeaking. Si le texte de l’étiquette visible ne correspond pas au nom accessible programmatique, la commande vocale échoue silencieusement.

Considérons un scénario concret : une personne malvoyante fait une demande de prestation gouvernementale sur le portail d’une institution publique turque. Le formulaire utilise du texte d’espace réservé au lieu d’étiquettes. Lorsque l’utilisateur zoome à 200 % pour lire l’écran, les placeholders disparaissent avant qu’il puisse les lire. Il remplit les champs en devinant et soumet un formulaire comportant des erreurs, pour ne recevoir qu’un message d’erreur générique sans indication des champs incorrects. Ce scénario aboutit à l’exclusion d’un service public essentiel — et il est entièrement évitable.

Au‑delà de l’accessibilité, les formulaires étiquetés améliorent le référencement (SEO) car les robots d’indexation des moteurs de recherche peuvent mieux comprendre la finalité du formulaire, et ils améliorent l’ergonomie pour tous les utilisateurs, y compris sur les appareils mobiles où les petites cibles tactiles bénéficient de zones d’étiquettes cliquables qui agrandissent la zone d’activation du champ associé.

Règles Axe-core associées

• label — Cette règle vérifie que chaque élément <input> (sauf ceux avec type='hidden', type='image', type='button', type='submit' et type='reset'), chaque <textarea> et chaque <select> possède un nom accessible. La règle signale les éléments dépourvus d’un <label> associé, d’un attribut aria-label, d’une référence aria-labelledby ou d’un attribut title. C’est le principal indicateur automatisé des violations du critère 3.3.2 sur les contrôles de formulaire standard.
• select-name — Cette règle cible spécifiquement les listes déroulantes <select> et vérifie qu’elles ont un nom accessible non vide. Les développeurs supposent parfois que les options d’une liste déroulante rendent sa finalité évidente, mais sans étiquette, les utilisateurs de lecteurs d’écran n’entendent que la valeur de l’option actuellement sélectionnée — qui peut être une valeur par défaut générique comme « Select a city » — sans indication de la catégorie dans laquelle ils choisissent. Axe signale les éléments <select> dépourvus de l’un des mécanismes d’étiquetage standard.
• textarea-label — Cette règle vérifie que les éléments <textarea> ont un nom accessible. Les zones de texte multi‑ligne sont fréquemment utilisées pour des commentaires, des messages ou des saisies détaillées, mais elles sont souvent laissées sans étiquette, dans l’idée erronée que le contexte environnant est suffisant. Axe signale tout <textarea> qui ne peut pas être associé de manière programmatique à une étiquette via <label for>, aria-label, aria-labelledby ou title.

Il est important de comprendre les limites des tests automatisés pour ce critère. Axe-core peut détecter l’absence d’une étiquette programmatique, mais ne peut pas déterminer si une étiquette présente est réellement significative ou exacte. Un champ étiqueté « Champ 1 » ou une étiquette qui se limite à « * » passera les vérifications automatisées tout en étant totalement inutilisable pour les utilisateurs. Un examen manuel est toujours nécessaire pour confirmer que les étiquettes décrivent clairement la saisie attendue, que les instructions de format sont présentes lorsque nécessaire (par exemple, formats de date, exigences de mot de passe) et que les champs obligatoires sont identifiés — idéalement à la fois visuellement et de manière programmatique.

Comment tester

1. Analyse automatisée avec axe DevTools ou Lighthouse : Ouvrez la page contenant le formulaire dans Chrome ou Firefox. Exécutez l’extension de navigateur axe DevTools et filtrez les résultats par les règles label, select-name et textarea-label. Notez chaque élément signalé. Exécutez Google Lighthouse (audit Accessibilité) comme vérification secondaire. Exportez ou capturez l’écran de toutes les violations. Gardez à l’esprit qu’un rapport automatisé sans erreur ne garantit pas la conformité — poursuivez avec les étapes manuelles.
2. Inspection visuelle : Sans utiliser de technologie d’assistance, examinez chaque champ de formulaire sur la page. Vérifiez que chaque champ possède une étiquette visible et statique — pas seulement un placeholder — positionnée clairement près du champ (généralement au‑dessus ou à gauche). Vérifiez que les exigences de format (par exemple, « Le mot de passe doit comporter au moins 8 caractères ») sont affichées avant ou au moment de la saisie, et non uniquement après un envoi échoué. Vérifiez que les champs obligatoires sont identifiés par autre chose que la couleur seule.
3. Test de navigation au clavier : Parcourez chaque champ de formulaire avec la touche Tab. Assurez‑vous qu’à mesure que chaque champ reçoit le focus, sa finalité est immédiatement claire grâce à l’étiquette visible. Aucun champ ne doit être atteignable au clavier sans qu’une étiquette adjacente et persistante soit visible à ce moment‑là.
4. Test avec lecteur d’écran NVDA et Firefox : Ouvrez le formulaire avec NVDA en cours d’exécution. Appuyez sur Tab pour passer d’un contrôle interactif à l’autre. NVDA doit annoncer l’étiquette, le rôle (par exemple, « zone de saisie », « liste déroulante ») et tout état (par exemple, « obligatoire »). Si NVDA n’annonce que le rôle et l’état sans étiquette, le champ échoue. Utilisez le mode formulaire de NVDA (déclenché automatiquement sur les éléments interactifs) pour simuler une navigation réaliste.
5. Test avec VoiceOver et Safari (macOS/iOS) : Activez VoiceOver (Command + F5 sur Mac). Utilisez Tab ou le balayage pour naviguer jusqu’à chaque champ de formulaire. VoiceOver doit annoncer l’étiquette avant le rôle. Sur iOS, touchez chaque champ et vérifiez que l’étiquette est lue à voix haute avant l’apparition du clavier. Les champs avec uniquement un placeholder seront généralement lus comme le placeholder au premier focus, mais deviendront silencieux une fois du texte saisi.
6. Test avec lecteur d’écran JAWS et Chrome : Ouvrez JAWS et naviguez dans le formulaire à l’aide de Tab. Utilisez le mode formulaire de JAWS. Vérifiez que le nom annoncé de chaque champ correspond exactement à son étiquette visible. Utilisez la commande Insert + F1 (aide sur le champ) de JAWS pour vérifier la présence de descriptions supplémentaires via aria-describedby.
7. Test de commande vocale avec Dragon NaturallySpeaking : Activez Dragon et tentez d’interagir avec chaque champ en prononçant son étiquette visible. Si l’étiquette prononcée ne correspond pas au nom accessible programmatique, le champ ne répondra pas à la commande vocale, ce qui indique un décalage qui enfreint à la fois le critère 3.3.2 et des critères connexes.

Comment corriger

Étiquette manquante sur un champ texte — Incorrect

<!-- No label provided; placeholder is the only hint -->
<input type='text' name='email' placeholder='Email address' />

Étiquette manquante sur un champ texte — Correct

<!-- Visible <label> associated via matching for/id attributes.
     Placeholder may still be used as supplementary hint,
     but the label is the primary, persistent identifier. -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

Liste déroulante sans étiquette — Incorrect

<!-- No label; screen readers will only announce the selected option value -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Liste déroulante sans étiquette — Correct

<!-- Programmatically associated label makes the field's purpose clear
     before the user opens the dropdown. -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Zone de texte sans étiquette — Incorrect

<!-- The textarea has no label; surrounding paragraph text is not
     programmatically associated and will not be read by screen readers
     as the field's label. -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

Zone de texte sans étiquette — Correct

<!-- Using aria-labelledby to associate the existing visible heading
     with the textarea, or alternatively wrapping with a <label> element. -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

Instructions de format absentes pour un champ de date — Incorrect

<!-- Label present but no instruction about expected date format;
     users must guess whether to enter 01/06/2025 or 2025-06-01. -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

Instructions de format présentes pour un champ de date — Correct

<!-- Format instruction is visible and linked via aria-describedby
     so screen readers announce it when the field receives focus. -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

Erreurs courantes

• Utiliser placeholder comme seule étiquette : Le texte d’espace réservé disparaît à la saisie, n’est pas annoncé de manière fiable comme étiquette par tous les lecteurs d’écran et pénalise les personnes ayant des troubles cognitifs qui ont besoin d’un texte de référence persistant. Fournissez toujours un élément <label> visible en plus de tout placeholder.
• Positionner visuellement une étiquette près d’un champ sans association programmatique : Un <p> ou un <span> placé visuellement au‑dessus d’un champ ressemble à une étiquette pour les utilisateurs voyants mais est ignoré par les lecteurs d’écran. Utilisez <label for='id'>, aria-labelledby ou encapsulez le champ dans un élément <label>.
• Utiliser aria-label avec un texte qui ne correspond pas à l’étiquette visible : Lorsque le nom accessible programmatique diffère du texte visible, les utilisateurs de commande vocale ne peuvent pas activer le champ en prononçant ce qu’ils lisent à l’écran, ce qui enfreint le critère 2.5.3 (Étiquette dans le nom) et crée de la confusion pour les utilisateurs de lecteurs d’écran.
• Étiqueter un groupe de boutons radio sans fournir de légende de groupe : Les boutons radio individuels peuvent chacun être étiquetés avec leur texte d’option, mais si la question globale (par exemple, « Mode de paiement ») n’est pas fournie via un <fieldset> et un <legend>, les utilisateurs qui naviguent au clavier entendent chaque option isolément sans comprendre ce qu’ils sont en train de choisir.
• Identifier les champs obligatoires uniquement par la couleur ou un astérisque, sans explication : Un astérisque (*) à côté d’une étiquette ne signifie rien pour les utilisateurs de lecteurs d’écran si sa signification n’est pas expliquée (par exemple, une note en haut du formulaire indiquant « Les champs marqués d’un * sont obligatoires ») et si les champs obligatoires ne portent pas également l’attribut required ou aria-required='true'.
• Omettre les instructions de format jusqu’après un envoi échoué : Afficher les règles de mot de passe ou les formats de date uniquement dans les messages d’erreur après soumission oblige les utilisateurs à commettre une erreur avant de pouvoir savoir ce qui est attendu. Les instructions doivent être présentes avant ou au moment où l’utilisateur interagit avec le champ.
• Masquer les étiquettes avec display:none ou visibility:hidden : Ces propriétés CSS retirent complètement les étiquettes de l’arbre d’accessibilité. Si une étiquette doit être masquée visuellement (par exemple, pour un design minimaliste), utilisez une classe CSS de masquage visuel qui maintient l’élément dans l’arbre d’accessibilité tout en le déplaçant hors écran.
• Utiliser l’attribut title comme seule étiquette en supposant qu’il est suffisant : Bien que axe-core ne signale pas forcément une étiquette basée uniquement sur title, cet attribut n’apparaît que sous forme d’infobulle au survol et est inaccessible aux utilisateurs uniquement au clavier et aux utilisateurs mobiles. Il doit être utilisé comme description complémentaire, et non comme étiquette principale.
• Appliquer un unique aria-label à un conteneur <div> en pensant qu’il étiquettera les champs enfants : Les étiquettes ARIA sur les éléments conteneurs ne sont pas héritées par les contrôles de formulaire enfants. Chaque contrôle interactif doit être étiqueté individuellement.
• Ne pas réassocier les étiquettes après des mises à jour dynamiques du contenu : Lorsque des champs de formulaire sont injectés dynamiquement via JavaScript (par exemple, ajout d’une ligne d’adresse), les champs nouvellement insérés manquent souvent d’étiquettes associées parce que le développeur n’a ajouté que le texte d’étiquette visible comme élément frère, sans liaison correcte for/id.

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

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires en matière d’accessibilité web alignées sur les WCAG 2.2. Le critère de succès 3.3.2 des WCAG — Étiquettes ou instructions — est une exigence de niveau A, ce qui signifie qu’il se situe au niveau de base de la conformité et fait partie des dispositions les plus strictement appliquées dans le cadre de la circulaire.

La circulaire couvre un large éventail de types d’entités, et les délais de conformité diffèrent selon les secteurs. Les institutions publiques — y compris les ministères, les municipalités, les agences d’État et les organisations financées sur fonds publics — doivent atteindre une conformité complète de niveau A dans un délai de un an à compter de la publication de la circulaire. Les entités du secteur privé concernées doivent se conformer dans un délai de deux ans. Les entités privées explicitement couvertes comprennent les plateformes de commerce électronique, les banques et institutions financières, les hôpitaux et prestataires de soins de santé privés, les entreprises 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 (MoNE).

Pour toutes ces entités, l’absence d’étiquetage des champs de formulaire n’est pas seulement un défaut d’ergonomie — elle constitue une non‑conformité réglementaire directe. Les formulaires sont omniprésents dans tous les services numériques couverts : les citoyens soumettent des demandes sur les portails gouvernementaux, les patients prennent des rendez‑vous sur les sites des hôpitaux, les clients finalisent des achats sur les plateformes de commerce électronique et les étudiants s’inscrivent via les portails des écoles. Chacun de ces parcours repose sur des formulaires, et chaque champ non étiqueté dans ces formulaires est une violation manifeste du critère 3.3.2 des WCAG que les auditeurs peuvent documenter et signaler.

Les organisations soumises à la circulaire devraient considérer la conformité au critère 3.3.2 comme un prérequis à tout audit ou processus de certification en accessibilité. Étant donné qu’il s’agit d’un critère de niveau A, il ne peut pas être levé ni reporté — les déclarations de conformité partielle qui excluent des éléments de niveau A ne sont pas reconnues. Les entités qui ne peuvent pas démontrer la présence d’étiquettes sur l’ensemble de leurs formulaires accessibles au public s’exposent à des constats réglementaires, à une publication de leur non‑conformité et à des dommages réputationnels sur un marché où la confiance numérique est de plus en plus liée à la conception inclusive.

D’un point de vue pratique, atteindre la conformité au critère 3.3.2 fait partie des mesures les moins coûteuses et les plus impactantes qu’une organisation puisse prendre. Associer des étiquettes aux contrôles de formulaire existants nécessite généralement seulement des modifications HTML mineures et n’a aucun effet sur le design visuel lorsqu’il est mis en œuvre correctement. Pour les organisations utilisant le SDK d’overlay d’Accsible, la détection automatisée des étiquettes manquantes peut faire remonter ces violations lors des analyses de routine, fournissant aux équipes de développement des recommandations de correction exploitables avant l’échéance réglementaire.