Aria-invalid=true
Définir la propriété `aria-invalid` sur « true » est un moyen simple et rapide d'indiquer qu'un champ n'a pas passé la validation. Cependant, son utilité du point de vue de l'accessibilité se limite aux situations suivantes :
- L'erreur est tellement évidente à l'œil nu, et
- Il n'est pas vraiment nécessaire de donner une description détaillée de l'erreur.
On peut citer, à titre d'exemple, les champs dont le libellé ou le texte d'instruction indique expressément :
- Format des données pour les dates, adresses e-mail, numéros de téléphone, etc.
- Plage minimale – maximale des valeurs attendues
Il arrive parfois que le texte de remplacement ou le texte par défaut indique également le format de données attendu avant même que l'utilisateur ne tente de remplir le champ (il convient de veiller à ce que cette information soit accessible). Selon le contexte, le format des données ou la plage attendue peuvent être évidents ou clairs d'après l'usage courant et ne sont pas nécessairement mentionnés explicitement dans toutes les situations.
- La valeur « Aria-invalid » peut également être attribuée à des champs « obligatoires » lorsqu'un utilisateur omet de les remplir.
Notifications d'erreur
Lorsqu’un champ a l’attribut `aria-invalid` défini sur « true », VoiceOver dans Safari annonce « données non valides » lorsque le champ reçoit le focus ; JAWS et NVDA signalent l’erreur comme une « saisie non valide ». Pour les utilisateurs malvoyants utilisant des technologies d’assistance compatibles avec ARIA, ces notifications sont essentielles pour identifier les champs dont la validation a échoué dans les situations décrites ci-dessus.
Cet attribut ARIA doit être défini / activé par programmation. Il ne doit pas être défini sur « true » avant que la validation des données saisies ne soit effectuée ou que le formulaire ne soit envoyé. Définir aria-invalid sur « false » revient à ne pas inclure du tout cet attribut pour le contrôle du formulaire. Dans ce cas, comme on peut s'y attendre, aucune information n'est transmise aux utilisateurs par les technologies d'assistance.
Lorsqu'il est nécessaire d'identifier le champ qui n'a pas passé la validation et d'afficher une description claire de l'erreur, définir l'attribut `aria-invalid` sur « true » est redondant et n'apporte pas grand-chose du point de vue de la conformité en matière d'accessibilité. Dans un tel cas, le simple fait d'indiquer qu'une erreur s'est produite et d'associer par programmation le message d'erreur détaillé au champ concerné permettra de satisfaire aux exigences des critères SC 3.3.1 et SC 1.3.1.
Lorsque la suggestion permettant de corriger l'erreur est présentée à l'utilisateur (afin de respecter la spécification SC 3.3.3, niveau AA), elle peut être formulée de manière à décrire également l'erreur. Là encore, l'attribut `aria-invalid="true"` est superflu.
Dans l'exemple 1, l'attribut `aria-invalid` est utilisé lorsque le code d'identification personnel (PIN), l'adresse e-mail ou la date de début ne respectent pas le format attendu. Un message d'erreur est associé au champ à l'aide de l'attribut `aria-describedby` lorsqu'aucune valeur n'est saisie dans les trois premiers champs ou lorsque la date de début demandée est antérieure à la date actuelle.
Dans l'exemple 2, l'attribut « aria-invalid » a été utilisé sur des champs obligatoires qui ne contiennent aucune donnée.
Référence :
- États et propriétés pris en charge : WAI-ARIA 1.1
- Aria-required=true : conformité aux WCAG 2.0 ou bonnes pratiques ?
Sailesh Panchang
Consultant principal en accessibilité, Deque Systems
