Critères de succès

WCAG 4.1.2 Nom, rôle et valeur

Le critère de succès 4.1.2 exige que, pour chaque composant d'interface, son nom et son rôle puissent être déterminés par programme, que ses états, propriétés et valeurs puissent être définis par la personne lorsque c'est pertinent, et que toute modification de ces éléments soit communiquée aux technologies d'assistance. C'est un critère de niveau A sous la règle 4.1 (Compatible) - et, en nombre de règles, le critère le plus largement représenté dans tout le jeu de règles d'axe-core : des dizaines de règles distinctes se rattachent à cette seule exigence.

Pourquoi il est formulé en trois éléments distincts

Nom : l'intitulé de la commande - le nom accessible d'un bouton, la fonction d'un lien, l'étiquette d'un champ de formulaire.

Rôle : le type de commande dont il s'agit - bouton, lien, case à cocher, onglet -, transmis automatiquement par les véritables éléments HTML, mais qu'un composant sur mesure construit sur une <div> doit déclarer explicitement par un role ARIA.

Valeur (et état) : pour les commandes qui portent une valeur ou un état - cochée ou non, dépliée ou repliée, sélectionnée -, cet état doit être exposé et tenu à jour au fil de ses changements.

Un composant auquel l'un de ces trois éléments manque est incomplètement décrit aux technologies d'assistance, même si les deux autres sont corrects.

Où ce critère se manifeste réellement

Parce que « nom, rôle et valeur » constitue une exigence aussi fondamentale, un très grand nombre de non-conformités plus précises et plus faciles à nommer sont en réalité, au fond, des défaillances du critère 4.1.2 :

• Un bouton réduit à une icône, sans nom accessible - voir Liens et boutons vides.
• Des attributs ARIA mal orthographiés, non valides, ou privés des attributs qu'ils exigent - voir Attributs ARIA invalides.
• Un cadre iframe sans title, laissant le contenu embarqué sans nom - voir Titres de cadres manquants.
• Un champ de formulaire sans étiquette programmatique - voir Étiquettes de formulaire manquantes.
• Un interrupteur ou une case à cocher sur mesure construits sur une <div> qui ne met jamais à jour aria-checked lorsque son état change.

La correction qui les unifie : privilégier le HTML natif

Presque toutes les non-conformités au critère 4.1.2 remontent à la même cause première : recréer sur un élément générique le comportement d'une commande HTML native au lieu d'utiliser la véritable commande. Un <button>, un <input type="checkbox"> ou un <select> authentiques satisfont automatiquement le nom, le rôle et la valeur, sans effort et sans aucun ARIA. C'est le sens pratique de la règle « n'utilisez pas ARIA si le HTML natif fait déjà le travail » : le critère 4.1.2 est celui que cette règle vise à protéger.

Questions fréquentes

Qu'est-ce que le critère WCAG 4.1.2 ?

Un critère de niveau A qui exige que chaque composant interactif expose par programme son nom (son étiquette), son rôle (le type de commande dont il s'agit) et son état ou sa valeur du moment.

Qu'est-ce qui échoue couramment au critère 4.1.2 ?

Des composants sur mesure construits à partir d'éléments div ou span génériques, sans rôle ni ARIA, qu'un lecteur d'écran annonce comme du texte dénué de sens au lieu d'un bouton, d'une case à cocher, etc.

Comment le satisfaire ?

Privilégiez les éléments HTML natifs (button, input), ou appliquez les rôles, noms et états ARIA corrects lorsque vous construisez des composants sur mesure.