aria-describedby

Quand l’utiliser

Pour les informations complémentaires situées à côté d’un contrôle : une indication de format sous un champ de date (« JJ/MM/AAAA »), une liste de règles de complexité pour un mot de passe, un message d’erreur en ligne, les instructions au-dessus d’un widget complexe. Le label répond à qu’est-ce que c’est ? ; la description répond à y a-t-il autre chose à savoir ?.

Utilisez-le sur les champs de formulaire, les boutons, les dialogues et tout widget personnalisé où un contexte supplémentaire doit venir après le nom.

Comportement

La valeur est une liste d’IDs d’éléments séparés par des espaces, de la même forme que aria-labelledby. Les lecteurs d’écran annoncent la description après le nom accessible et le rôle, généralement après une courte pause — « Email, champ de saisie, Nous vous contacterons uniquement au sujet de cette commande. » Plusieurs IDs sont concaténés dans l’ordre indiqué.

La description n’est pas le nom. Elle n’apparaît pas dans le champ nom de l’arbre d’accessibilité ; axe-core ne la comptabilisera donc pas comme label du contrôle. Si le contrôle n’a pas de nom, aria-describedby ne peut pas y suppléer.

Si la description change (par exemple lors de l’apparition d’une erreur), mettez à jour le contenu textuel de l’élément référencé plutôt que de modifier la valeur de aria-describedby — beaucoup de technologies d’assistance ne ré-annoncent pas lorsque l’attribut lui-même change, mais elles ré-annoncent lorsque le texte référencé fait partie d’une région live ou lorsque le focus revient sur le champ.

Erreurs courantes

• Utiliser aria-describedby à la place d’un label. Le contrôle reste sans nom ; l’utilisateur entend la description mais jamais le nom.
• Pointer vers un ID inexistant ou retiré du DOM par un rendu.
• Ajouter aria-describedby sur un élément non-focusable. La plupart des navigateurs n’exposent la description que lorsque l’élément reçoit le focus ou est interrogé directement.
• Utiliser du texte marketing long comme description — des annonces verbeuses poussent les utilisateurs à désactiver les descriptions globalement.
• Oublier d’associer les erreurs de formulaire en ligne. aria-describedby="email-error" associé à aria-invalid="true" est le pattern canonique ; sans la référence, l’erreur est visible mais silencieuse.
• Réutiliser le même ID de description pour de nombreux champs avec aria-describedby="hint" — cela fonctionne, mais vérifiez que le même texte s’applique bien à chaque champ.

Exemple

<label for="password">Mot de passe</label>
<input
  id="password"
  type="password"
  aria-describedby="pw-rules pw-error"
  aria-invalid="true"
>
<p id="pw-rules">Au moins 12 caractères, dont un chiffre.</p>
<p id="pw-error">Le mot de passe est trop court.</p>