Chapitre 5.3 — Nom, rôle, valeur

⏱️ TL;DR — Chaque nœud de l’arbre d’accessibilité expose trois choses, et c’est le critère 4.1.2 Nom, rôle, valeur : le rôle (ce que c’est — bouton, lien, case…), le nom accessible (comment on l’appelle — « Envoyer ») et la valeur/état (coché, développé, désactivé…). Le rôle vient surtout de la balise. Le nom se calcule selon un ordre de priorité strict : aria-labelledby > aria-label > contenu/<label> natif > title/placeholder en tout dernier recours. Une description (aria-describedby) peut s’ajouter. Maîtriser ce triptyque, c’est maîtriser ce qu’annonce le lecteur d’écran.

🎯 Objectifs

• Énoncer le modèle nom / rôle / valeur et le rattacher au critère 4.1.2.
• Comprendre d’où vient le rôle et pourquoi le natif est prioritaire.
• Maîtriser l’ordre de priorité du calcul du nom accessible.
• Distinguer nom et description (aria-describedby).
• Écrire des noms accessibles corrects (exemples mauvais → bon).

Le modèle nom / rôle / valeur (4.1.2)

Le critère WCAG 4.1.2 « Nom, rôle, valeur » exige que, pour tout composant d’interface, ces trois informations soient programmatiquement déterminables — c’est-à-dire présentes dans l’arbre d’accessibilité. C’est la colonne vertébrale de l’a11y technique : un lecteur d’écran n’annonce jamais rien d’autre que ça.

• Rôle : ce que c’est. Un bouton, un lien, une case à cocher, un titre, une région de navigation.
• Nom : comment ça s’appelle. Le libellé qui identifie l’élément : « Envoyer », « Accueil », « Se souvenir de moi ».
• Valeur / état : dans quel état c’est. Coché ou non, développé ou replié, désactivé, requis, la position dans une liste, le texte saisi dans un champ.

Quand un lecteur d’écran annonce « Se souvenir de moi, case à cocher, non cochée », il lit exactement nom + rôle + valeur.

Le rôle : ce que c’est

Le rôle dit à la technologie d’assistance comment traiter l’élément et quels raccourcis s’appliquent. Il vient, par ordre de préférence :

1. De la balise native — c’est la règle d’or. <button> → rôle button, <a href> → link, <input type="checkbox"> → checkbox, <nav> → navigation, <h2> → heading niveau 2. Gratuit, robuste, correct.
2. D’un attribut role ARIA — seulement quand aucun élément natif ne convient (role="tablist", role="dialog"…). L’ARIA remplace le rôle mais n’ajoute ni comportement clavier, ni focus : à toi de les recoder. D’où la première règle d’ARIA — ne pas utiliser ARIA quand un natif existe (voir Partie 6).

<!-- ❌ Rôle "generic" : la div n'est pas un bouton dans l'arbre -->
<div class="btn" onclick="envoyer()">Envoyer</div>
 
<!-- ✅ Rôle "button", focusable et activable au clavier, gratuitement -->
<button type="button" onclick="envoyer()">Envoyer</button>

Le nom accessible : comment ça s’appelle

C’est la partie la plus subtile — et la plus mal comprise. Le nom accessible (accessible name) n’est pas « le texte à l’écran » : c’est le résultat d’un calcul défini par la spec (l’Accessible Name Computation). Plusieurs sources peuvent fournir le nom ; le navigateur les départage selon un ordre de priorité. Simplifié, du plus fort au plus faible :

1. aria-labelledby — pointe vers l’id d’un ou plusieurs éléments dont le texte devient le nom. Gagne sur tout le reste.
2. aria-label — une chaîne fournie directement. Gagne sur le contenu et le label natif.
3. Le contenu textuel de l’élément (pour un <button>, un lien) ou le <label> associé (pour un champ de formulaire).
4. title, puis placeholder — en tout dernier recours, si rien d’autre n’est fourni.

Autrement dit : si tu mets à la fois un aria-label et du texte visible, c’est l’aria-label qui gagne et le texte visible est ignoré comme nom. Cette règle explique beaucoup de bugs (« le bouton s’annonce autrement que ce qui est écrit dessus »).

<!-- Nom = "Fermer la fenêtre" (aria-label gagne sur le contenu "✕") -->
<button aria-label="Fermer la fenêtre">✕</button>
 
<!-- Nom = "Menu principal" (aria-labelledby gagne, pointe vers le titre) -->
<h2 id="titre-nav">Menu principal</h2>
<nav aria-labelledby="titre-nav"> ... </nav>
 
<!-- Nom = "Email" (le <label> associé fournit le nom du champ) -->
<label for="email">Email</label>
<input id="email" type="email">

⚠️ Piège — Le placeholder n’est pas un label. Un champ dont le seul « libellé » est un placeholder a un nom accessible fragile (dernier recours dans le calcul), et surtout le placeholder disparaît dès que l’utilisateur commence à taper : il ne peut plus vérifier ce qu’on lui demande. Certains lecteurs ne l’annoncent même pas comme nom. Toujours un vrai <label> (ou aria-label/aria-labelledby) ; le placeholder reste un simple exemple de saisie, en plus, jamais à la place.

<!-- ❌ Nom fragile : seul le placeholder "sert" de label, et il s'efface à la saisie -->
<input type="text" placeholder="Votre email">
 
<!-- ✅ Vrai label associé ; le placeholder reste un exemple facultatif -->
<label for="mail">Votre email</label>
<input id="mail" type="email" placeholder="prenom@exemple.fr">

La valeur et l’état

Le troisième pilier décrit la situation de l’élément. Pour les contrôles natifs, le navigateur la gère seul :

• une case cochée → état checked annoncé « cochée » ;
• un champ requis (required) → « requis » ;
• un contrôle disabled → « indisponible » ;
• la valeur saisie dans un <input> → lue à la relecture.

Pour un composant custom, c’est à toi de tenir ces états à jour via ARIA : aria-checked, aria-expanded (« développé »/« replié »), aria-selected, aria-disabled, aria-current. Un menu déroulant qui ne bascule pas aria-expanded s’annonce toujours « replié », même ouvert — l’utilisateur est perdu.

<!-- Le bouton reflète l'état d'ouverture du panneau qu'il contrôle -->
<button aria-expanded="false" aria-controls="panneau">Détails</button>
<!-- En JS, on passe aria-expanded à "true" quand on ouvre #panneau -->

Nom ≠ description

Le nom identifie ; la description informe en plus. aria-describedby pointe vers un texte lu après le nom et le rôle, souvent pour une aide ou une contrainte :

<label for="pwd">Mot de passe</label>
<input id="pwd" type="password" aria-describedby="aide-pwd">
<p id="aide-pwd">12 caractères minimum, une majuscule et un chiffre.</p>

Annoncé : « Mot de passe, zone d’édition protégée » puis « 12 caractères minimum… ». N’entasse pas tout dans le nom : le nom reste court et identifiant, la description porte le détail.

♿ Côté utilisateur — Le nom accessible, c’est le mot par lequel l’utilisateur cherche un élément dans la liste des liens ou des boutons de sa page. Dix boutons nommés « Voir » sont inutilisables : sa liste affiche « Voir, Voir, Voir… ». Nommés « Voir le cours React », « Voir le cours Symfony »…, ils deviennent repérables d’un coup. Le nom n’est pas un détail cosmétique : c’est son moyen de navigation.

🧭 Sur A11yLearn — Le tableau de bord d’A11yLearn alignait des cartes de cours, chacune avec un bouton « Continuer ». Dans la liste des boutons du lecteur d’écran : « Continuer, Continuer, Continuer… » — impossible de savoir quel cours. On a donné à chaque bouton un nom accessible explicite via aria-label, par exemple « Continuer : Introduction à React ». Même bouton visuel « Continuer » (le design ne bouge pas), mais un nom accessible unique et parlant. La liste des boutons devient une table des matières.

✏️ Exercices

Exercice 1 — Qui gagne ? Pour chaque élément, donne le nom accessible calculé : (a) <button aria-label="Rechercher">🔍</button>, (b) <button title="Envoyer">Valider</button>, (c) un champ avec <label for="x">Nom</label> et aria-label="Prénom" sur l’<input id="x">.

Exercice 2 — Répare le champ. Corrige ce code pour qu’il ait un nom accessible robuste et un état correct : <input type="checkbox" placeholder="Newsletter">.

<input id="news" type="checkbox">
<label for="news">Recevoir la newsletter</label>

🧠 Quiz de révision

Chapitre suivant : Utiliser un lecteur d’écran — prendre en main NVDA ou VoiceOver pour vérifier de tes oreilles ce que ton arbre annonce.