WCAG 4.1.2 : Nom, Rôle, Valeur

La norme WCAG 4.1.2 exige que tous les composants de l’interface utilisateur aient un nom et un rôle déterminables par des moyens programmatiques, et que les états, propriétés et valeurs puissent être à la fois lus et définis par les technologies d’assistance. Cela garantit que les lecteurs d’écran et autres outils peuvent identifier, décrire et interagir avec précision avec chaque élément de la page.

Ce que signifie cette règle

WCAG 4.1.2 — Nom, Rôle, Valeur est un critère de succès de niveau A relevant du principe de Robustesse. Il exige que pour chaque composant d’interface utilisateur — y compris les éléments de formulaire, boutons, liens, widgets personnalisés, frames et contrôles interactifs — les trois conditions suivantes soient remplies :

Nom : Chaque composant doit avoir un nom accessible que les technologies d’assistance peuvent lire à voix haute ou exposer via un afficheur braille. Le nom peut provenir du contenu de l’élément (par exemple, le texte à l’intérieur d’un <button>), d’un élément label, d’un attribut aria-label, d’une référence aria-labelledby ou d’un attribut title.
Rôle : Chaque composant doit avoir un rôle qui communique sa fonction aux technologies d’assistance. Les éléments HTML natifs portent des rôles implicites (un <button> a le rôle button, un <input type='checkbox'> a le rôle checkbox). Les widgets personnalisés construits à partir d’éléments génériques comme <div> ou <span> doivent déclarer explicitement un rôle à l’aide de l’attribut ARIA role.
Valeur (États et propriétés) : Tout état ou valeur actuel qui a un sens pour l’utilisateur — si une case à cocher est cochée, si un widget de divulgation est développé, si un champ est obligatoire — doit être exposé de manière programmatique afin que les technologies d’assistance puissent le signaler et que les utilisateurs puissent le modifier lorsque c’est applicable.

Un composant répond à ce critère lorsque son nom accessible n’est pas vide, que son rôle est valide et sémantiquement approprié, et que tous les états pertinents (tels que aria-checked, aria-expanded ou aria-required) sont correctement appliqués et maintenus en synchronisation avec l’interface visuelle. Un composant échoue lorsque l’un de ces trois éléments est absent, incorrect ou désynchronisé — par exemple, un bouton bascule personnalisé qui change de couleur visuellement mais ne met jamais à jour son état aria-pressed.

L’exception officielle des WCAG couvre les composants qui ne sont intentionnellement pas exposés aux API d’accessibilité — par exemple, les éléments purement décoratifs ou le contenu masqué avec aria-hidden='true'. Cependant, masquer du contenu actif ou focalisable avec aria-hidden (par exemple, l’appliquer à l’élément <body>) constitue en soi une violation, car cela retire tout le contenu de la page de l’arbre d’accessibilité.

Pourquoi c’est important

Environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, selon l’Organisation mondiale de la santé. Pour les utilisateurs aveugles ou malvoyants qui s’appuient sur des lecteurs d’écran tels que JAWS, NVDA ou VoiceOver, le nom accessible et le rôle de chaque composant interactif sont le principal — et souvent le seul — moyen de comprendre à quoi sert un contrôle et comment l’utiliser. Si un bouton n’a pas de nom accessible, l’utilisateur de lecteur d’écran n’entend que « button » sans indication de sa fonction. Si une liste déroulante personnalisée n’a pas de rôle, l’utilisateur ne peut pas la distinguer d’un texte statique.

Les utilisateurs ayant des limitations motrices qui utilisent des logiciels via un accès par contacteur, des outils de commande vocale comme Dragon NaturallySpeaking ou la navigation au clavier dépendent également de ce critère. Les logiciels de commande vocale font correspondre les commandes prononcées (« click Submit ») aux noms accessibles. Si le nom accessible d’un bouton ne correspond pas à son libellé visible, les commandes vocales échouent complètement.

L’accessibilité cognitive est tout aussi pertinente. Un étiquetage cohérent et prévisible réduit la charge cognitive pour les utilisateurs ayant une dyslexie, des troubles de la mémoire ou des troubles de l’attention. Lorsque les changements d’état — comme l’ouverture d’une fenêtre modale ou le passage d’un champ de formulaire à l’état obligatoire — ne sont pas annoncés par les technologies d’assistance, les utilisateurs peuvent être désorientés et incapables de terminer leurs tâches.

Considérons un scénario concret du monde réel : une plateforme de e-commerce turque affiche un bouton « Ajouter au panier » construit comme un <div> avec un gestionnaire de clic et une icône de panier. Visuellement, il ressemble à un bouton. Mais comme il n’a pas de role='button', pas de nom accessible et pas de tabindex='0', un utilisateur de lecteur d’écran naviguant au clavier ne rencontre rien — l’élément est complètement invisible pour sa technologie d’assistance. Il ne peut pas ajouter de produits à son panier, ce qui l’exclut de fait de toute l’expérience d’achat.

Au-delà de l’accessibilité, des composants correctement nommés et structurés améliorent le référencement (SEO), car les robots d’indexation des moteurs de recherche s’appuient sur le balisage sémantique pour comprendre la structure de la page et l’intention interactive. Ils améliorent également la testabilité, car les frameworks de tests automatisés peuvent localiser et interagir plus fiablement avec des éléments qui ont des rôles et des libellés significatifs.

Règles axe-core associées

Les règles axe-core suivantes sont directement associées à WCAG 4.1.2. Chacune cible une catégorie spécifique d’échec de nom, de rôle ou de valeur :

aria-allowed-attr : Vérifie que les attributs ARIA appliqués à un élément sont autorisés pour le rôle de cet élément. Par exemple, appliquer aria-checked à un élément avec role='link' est invalide et signalé, car le rôle link ne prend pas en charge aria-checked.
aria-command-name : S’assure que les éléments avec des rôles de commande ARIA (link, button, menuitem) ont un nom accessible non vide. Un bouton composé uniquement d’une icône, sans texte de libellé et sans aria-label, serait signalé ici.
aria-hidden-body : Signale le cas spécifique où aria-hidden='true' a été appliqué à l’élément <body>, ce qui retire toute la page de l’arbre d’accessibilité et rend tout le contenu invisible pour les lecteurs d’écran.
aria-input-field-name : Vérifie que les éléments avec des rôles d’entrée ARIA (textbox, searchbox, spinbutton, slider, combobox) ont un nom accessible. Un champ de recherche personnalisé construit avec role='textbox' mais sans libellé serait signalé.
aria-meter-name : Vérifie que les éléments avec role='meter' ont un nom accessible, afin que les utilisateurs de lecteurs d’écran comprennent quelle quantité le compteur mesure (par exemple, l’utilisation du stockage ou le niveau de batterie).
aria-progressbar-name : S’assure que les éléments avec role='progressbar' portent un nom accessible, afin que les utilisateurs sachent quel processus ou opération est en cours plutôt que d’entendre simplement « progress bar ».
aria-required-attr : Vérifie que les éléments utilisant un rôle ARIA donné incluent tous les attributs requis par la spécification ARIA pour ce rôle. Par exemple, role='slider' requiert aria-valuenow, aria-valuemin et aria-valuemax ; l’omission de l’un d’eux est signalée.
aria-roles : Valide que toutes les valeurs attribuées à l’attribut role sont des rôles ARIA valides et non abstraits. Les fautes de frappe, les rôles inventés ou les rôles abstraits (comme role='widget') utilisés directement sur des éléments sont tous signalés.
aria-tooltip-name : Vérifie que les éléments avec role='tooltip' ont un nom accessible. Un élément d’infobulle vide n’apporte aucune valeur aux utilisateurs de lecteurs d’écran et représente un échec d’étiquetage.
button-name : Vérifie que les éléments <button> et les éléments avec role='button' ont un nom accessible non vide. Cela permet de détecter les boutons d’icône sans aria-label et les boutons vides utilisés comme déclencheurs décoratifs.
frame-title : Exige que les éléments <iframe> et <frame> aient un attribut title non vide décrivant le contenu de la frame. Sans cela, les utilisateurs de lecteurs d’écran ne peuvent pas déterminer la fonction du contenu intégré et peuvent ne pas savoir s’ils doivent entrer dans la frame ou la passer.
input-button-name : Vérifie que les éléments <input> de type submit, reset, button et image ont un nom accessible — soit via un attribut value, soit, pour les entrées image, un attribut alt.

Il est important de noter que, bien que les outils automatisés détectent de nombreux échecs de nom, de rôle et de valeur, certaines violations nécessitent des tests manuels. Les analyseurs automatisés ne peuvent pas vérifier si un nom accessible est significatif — un bouton étiqueté « click here » passe techniquement la vérification automatisée pour la présence d’un nom, mais ne communique pas réellement sa fonction. De même, le fait de savoir si les changements d’état (comme le basculement de aria-expanded lorsqu’un menu s’ouvre) sont correctement annoncés pendant l’interaction en direct ne peut être confirmé que par des tests pratiques avec un lecteur d’écran.

Comment tester

Analyse automatisée avec axe DevTools ou Lighthouse : Installez l’extension de navigateur axe DevTools (Chrome ou Firefox) ou lancez un audit Lighthouse dans Chrome DevTools sous l’onglet Accessibilité. Activez l’analyse de page complète et filtrez les résultats par le tag WCAG 4.1.2. Recherchez spécifiquement les violations de button-name, frame-title, aria-required-attr, aria-roles et aria-input-field-name. Chaque résultat inclura l’élément en cause, une description de l’échec et une correction suggérée. Exportez les résultats et priorisez d’abord les éléments de gravité Critique et Sérieuse.
Test de navigation au clavier : Débranchez votre souris et naviguez sur toute la page à l’aide de la touche Tab. Vérifiez que chaque élément focalisable reçoit un focus visible, que l’indicateur de focus natif du navigateur (ou un indicateur personnalisé) est clairement visible, et que vous pouvez activer tous les contrôles avec Entrée ou Espace. Tout élément que vous atteignez et que vous ne pouvez pas identifier par le contexte seul — sans regarder l’écran — indique probablement un échec de nom accessible.
Tests avec lecteur d’écran NVDA et Firefox : Ouvrez NVDA (Windows, gratuit), lancez Firefox et naviguez sur la page en utilisant Tab pour parcourir les éléments interactifs et la liste des éléments NVDA (Insert+F7) pour parcourir tous les boutons, liens et champs de formulaire. Pour chaque élément interactif, écoutez ce que NVDA annonce. Il doit lire le nom de l’élément, son rôle et tout état pertinent (par exemple, « Subscribe, button » ou « Email address, required, edit text »). Signalez tout élément annoncé sans nom ou avec un rôle incorrect.
Tests avec lecteur d’écran VoiceOver et Safari (macOS/iOS) : Activez VoiceOver (Commande+F5 sur macOS), ouvrez Safari et utilisez VO+Flèche droite pour naviguer entre les éléments. Utilisez le Rotor VoiceOver (VO+U) pour lister tous les contrôles de formulaire et les boutons. Vérifiez que les noms sont descriptifs, que les rôles sont appropriés et que les états sont mis à jour dynamiquement lorsque vous interagissez (par exemple, le basculement d’un accordéon personnalisé doit amener VoiceOver à annoncer « expanded » ou « collapsed »).
Tests avec lecteur d’écran JAWS et Chrome : Lancez JAWS et ouvrez Chrome. Utilisez la touche Tab pour naviguer entre les éléments interactifs et le curseur virtuel JAWS (Insert+F3 pour une liste des champs de formulaire) pour examiner les libellés. Portez une attention particulière aux widgets personnalisés construits avec ARIA — vérifiez que les changements d’état déclenchés par l’interaction au clavier se reflètent dans ce que JAWS annonce en temps réel.
Vérification de l’état des widgets personnalisés : Pour tout widget personnalisé (accordéon, panneau à onglets, combobox, modale), interagissez avec lui entièrement en utilisant uniquement le clavier. À chaque étape, vérifiez que le lecteur d’écran annonce la mise à jour correcte de l’état — par exemple, l’ouverture d’un widget de divulgation doit déclencher une annonce « expanded », et sa fermeture doit annoncer « collapsed ». Si l’état visuel change mais que le lecteur d’écran reste silencieux, aria-expanded est soit manquant, soit non basculé de manière programmatique.

Comment corriger

Bouton uniquement icône sans nom accessible — Incorrect

<!-- Icon button with no accessible name: screen readers announce only "button" -->
<button>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Bouton uniquement icône sans nom accessible — Correct

<!-- aria-label provides the accessible name when no visible text is present -->
<button aria-label='Search'>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Widget bascule personnalisé sans rôle ni état — Incorrect

<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
  Dark Mode
</div>

Widget bascule personnalisé sans rôle ni état — Correct

<!-- role='switch' communicates purpose; aria-checked reflects current state;
     tabindex='0' makes it keyboard reachable; keydown handler enables Space/Enter -->
<div
  role='switch'
  aria-checked='false'
  tabindex='0'
  onclick='toggleDarkMode(this)'
  onkeydown='if(event.key==="Enter"||event.key===" "){toggleDarkMode(this);event.preventDefault();}'
>
  Dark Mode
</div>

<script>
function toggleDarkMode(el) {
  const isOn = el.getAttribute('aria-checked') === 'true';
  el.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode', !isOn);
}
</script>

iframe sans libellé — Incorrect

<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>

iframe sans libellé — Correct

<!-- title describes the frame's content so users can decide whether to enter it -->
<iframe
  src='https://maps.example.com/embed?q=istanbul'
  title='Interactive map showing our Istanbul office location'
></iframe>

Barre de progression personnalisée sans attributs ARIA requis — Incorrect

<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
     screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>

Barre de progression personnalisée sans attributs ARIA requis — Correct

<!-- All required attributes present; aria-label provides the accessible name -->
<div
  role='progressbar'
  aria-valuenow='60'
  aria-valuemin='0'
  aria-valuemax='100'
  aria-label='File upload progress'
>
  60%
</div>

Erreurs courantes

Utiliser role='button' sur un <div> sans ajouter tabindex='0' — l’élément est annoncé comme un bouton par les lecteurs d’écran mais reste inatteignable via la navigation au clavier avec Tab, ce qui le rend inutilisable pour les utilisateurs ne disposant que du clavier.
Appliquer aria-label à un élément non interactif — ajouter aria-label à un <div> ou un <span> sans rôle n’a aucun effet ; le libellé est ignoré par la plupart des navigateurs car l’élément n’a pas de rôle à nommer.
Laisser aria-expanded statique après avoir implémenté un widget de divulgation — définir aria-expanded='false' en HTML et ne jamais le basculer avec JavaScript signifie que l’attribut est toujours erroné après le premier clic, annonçant l’état opposé aux utilisateurs de lecteurs d’écran.
Utiliser aria-hidden='true' sur un conteneur qui contient des éléments focalisables — cela masque le conteneur dans l’arbre d’accessibilité mais pas du focus clavier, de sorte que les utilisateurs de lecteurs d’écran peuvent atteindre par Tab des éléments qu’ils ne peuvent pas entendre, ce qui provoque une confusion extrême.
Fournir un placeholder comme seul libellé pour un <input> — le texte d’espace réservé disparaît à la saisie, n’est pas annoncé de manière fiable comme libellé par tous les lecteurs d’écran et ne satisfait pas à l’exigence de nom accessible pour les champs de formulaire.
Utiliser un rôle ARIA invalide ou abstrait comme role='widget' ou role='structure' — ce sont des rôles de base dans la spécification ARIA et ils ne sont pas destinés à être utilisés directement ; ils ne fournissent aucune information sémantique significative et peuvent être ignorés ou provoquer des erreurs dans les technologies d’assistance.
Référencer un ID d’élément inexistant dans aria-labelledby — si l’ID indiqué par aria-labelledby n’existe pas dans le DOM, le calcul du nom accessible échoue et l’élément se retrouve sans nom.
Utiliser value au lieu de aria-label pour <input type='image'> — les boutons d’entrée image nécessitent un attribut alt pour leur nom accessible ; l’attribut value est ignoré pour le calcul du nom sur les entrées image.
Omettre l’attribut title sur les éléments <iframe> qui chargent du contenu tiers — les développeurs supposent souvent que les contenus intégrés bien connus (cartes, widgets de paiement, lecteurs vidéo) se décrivent d’eux-mêmes, mais les utilisateurs de lecteurs d’écran doivent connaître la fonction de la frame avant de décider d’y entrer.
Oublier de mettre à jour dynamiquement les noms accessibles lorsque le contenu change — si le libellé d’un bouton passe visuellement de « Play » à « Pause » mais que le aria-label reste « Play », les utilisateurs de lecteurs d’écran reçoivent une information incorrecte sur l’état et l’action actuels.

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 exigences obligatoires en matière d’accessibilité numérique alignées sur WCAG 2.2. WCAG 4.1.2 — Nom, Rôle, Valeur est un critère de niveau A, ce qui signifie qu’il se situe au niveau le plus fondamental de conformité. En vertu de la circulaire, la conformité de niveau A n’est pas optionnelle — c’est le socle que toutes les entités concernées doivent atteindre.

La circulaire s’applique à un large éventail de types d’entités opérant en Turquie. Les institutions publiques — y compris les ministères, les municipalités et les agences d’État — doivent atteindre la conformité dans un délai de un an à compter de la date de publication de la circulaire. Les entités du secteur privé — y compris les plateformes de e-commerce, les banques et institutions financières, les hôpitaux et prestataires 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) — doivent atteindre la conformité dans un délai de deux ans.

WCAG 4.1.2 est particulièrement déterminant pour les organisations turques parce que de nombreux sites web turcs modernes reposent sur des composants interactifs personnalisés — carrousels de produits, FAQ en accordéon, parcours de paiement étape par étape et tableaux de bord bancaires — qui sont fréquemment implémentés sans rôles ARIA, noms ou gestion d’état appropriés. Un bouton de paiement personnalisé qui n’a pas de nom accessible, ou un curseur de calcul de prêt qui n’a pas de aria-valuenow, ne constitue pas seulement une mauvaise expérience utilisateur : en vertu de la circulaire, il s’agit d’un manquement à la conformité légale.

Pour les banques et les plateformes de e-commerce soumises à la circulaire, les violations de WCAG 4.1.2 dans les parcours critiques de transaction — formulaires de paiement, fenêtres modales d’authentification, tableaux de bord de compte — sont particulièrement risquées. Une combobox personnalisée stylisée visuellement pour sélectionner une agence bancaire, mais dépourvue de balisage ARIA approprié, peut empêcher un utilisateur de lecteur d’écran de finaliser une transaction, exposant l’institution à la fois à des actions réglementaires et à des plaintes pour discrimination.

Les organisations utilisant le SDK de surcouche Accsible peuvent bénéficier de la détection automatisée et de la remédiation à l’exécution de nombreuses violations de Nom, Rôle, Valeur — y compris l’injection de noms accessibles manquants, la correction de rôles ARIA invalides sur des modèles de widgets connus et la synchronisation des attributs d’état sur les composants interactifs. Cependant, les organisations doivent considérer le support automatisé de surcouche comme un complément, et non un substitut, à un développement HTML sémantique approprié, en particulier pour les widgets personnalisés complexes où la gestion programmatique de l’état doit être intégrée à la logique de l’application dès le départ.

Sources et références

Articles connexes

AWCAG 1.1.1 : Contenu non textuel AWCAG 1.2.1 : Audio seul et vidéo seule (préenregistrés)AWCAG 1.2.2 : Sous-titres (préenregistré)