aria-required

Quand l’utiliser

Uniquement quand l’attribut HTML required n’est pas disponible. Les champs de formulaire natifs — <input>, <select>, <textarea> — doivent utiliser required. L’attribut HTML est annoncé par tous les lecteurs d’écran, participe à la validation native du navigateur et active la pseudo-classe CSS :required. aria-required ne fait rien de tout cela par lui-même ; c’est une annonce purement déclarative.

Les cas légitimes d’utilisation de aria-required :

• Un role="combobox" personnalisé construit sur un <div> ou un <input> stylisé dont vous avez pris en charge la validation.
• Un role="radiogroup" dont le groupe dans son ensemble est obligatoire (vous ne pouvez pas mettre required sur un <div>).
• Un sélecteur de date, de fichier ou de widget de notation personnalisé qui n’est pas un champ natif.

Si vous pouvez utiliser HTML required à la place, faites-le.

Comment il se comporte

Booléen. aria-required="true" amène la technologie d’assistance à annoncer « obligatoire » (ou équivalent selon le lecteur d’écran) aux côtés du nom et du rôle du champ. aria-required="false" équivaut à omettre l’attribut et est rarement nécessaire.

aria-required n’empêche pas la soumission. Il n’ajoute pas d’astérisque rouge. Il ne bascule pas de pseudo-classe CSS. C’est uniquement un signal destiné aux technologies d’assistance. La logique de validation, les messages d’erreur et l’indicateur visible de champ obligatoire restent de votre responsabilité.

L’indicateur visible de champ obligatoire (un *, le mot « obligatoire », etc.) doit également figurer dans le nom accessible — soit dans le texte du label visible, soit dans une description — afin qu’un utilisateur voyant et un utilisateur de technologie d’assistance reçoivent la même information.

Erreurs fréquentes

• Utiliser aria-required="true" sur un <input> natif au lieu de l’attribut HTML required. Cela fonctionne, mais vous abandonnez la validation du navigateur et le style :required sans raison.
• Définir aria-required="true" sur un élément qui n’est pas un contrôle de formulaire — un bouton, un titre, un div sans rôle. L’attribut est ignoré.
• Omettre l’indicateur visible de champ obligatoire. Les utilisateurs voyants voient un champ non marqué ; les utilisateurs de technologie d’assistance entendent « obligatoire ». Problème WCAG SC 1.3.3.
• Marquer un champ comme obligatoire en ARIA mais l’ignorer dans la logique de validation côté serveur. L’annonce dit obligatoire ; le serveur accepte les valeurs vides sans problème.
• Associer aria-required à aria-invalid="true" trop tôt. Le champ n’est invalide qu’après que l’utilisateur a tenté de soumettre le formulaire en laissant le champ vide, pas au chargement de la page.
• Localiser l’indicateur visible "*" tout en oubliant que le texte destiné au lecteur d’écran dans le label est désormais incohérent.

Exemple

<!-- Champ natif : privilégier l'attribut HTML -->
<label for="email">
  Email <span aria-hidden="true">*</span>
</label>
<input id="email" type="email" required aria-describedby="email-hint">
<p id="email-hint">Required. We will only use this to send your receipt.</p>

<!-- Combobox personnalisé où HTML required n'est pas disponible -->
<div
  role="combobox"
  aria-required="true"
  aria-labelledby="country-label"
  aria-controls="country-listbox"
  aria-expanded="false"
>
  <input type="text" id="country-input">
</div>
<span id="country-label">Country (required)</span>