1177 sujets

Accessibilité du Web

[Résolu] Utilisation du role="alert" et aria-invalid

Bonjour,

je cherche à améliorer le retour aux erreurs suite à une mauvaise validation.

L'exemple est ici : Saisie de nombre dans limesurvey

Le champs est un champ texte ne devant contenir que des nombre. Je sais que je peux utiliser un type="number", et j'ai un theme de question qui le fait, mais je souhaite conserver aussi le fonctionnement avec le type="texte".

J'ai donc :
- aria-invalid="true" lors de la saisie de texte
- aria-describedby sur l’élément d'aide «Only numbers may be entered in this field.»
- Cet élément d'aide qui prend le role="alert" en cas d'erreur.

Mais un utilisateur avec Jaws m'a fait remonter : «However, my colleague asks if it is possible to highlight the wrong answers. I guess she would like to be taken back where the wrong answer was typed. Is this possible?» après la tentative de soumission invalide semble t'il.

Je pensais pourtant que c'était le rôle de role="alert" , faut il en plus que j'ajoute le aria-live lors du changement de aria-invalid ?

Merci
PS : le même système permet une utilisation en utilisant setCustomValidity, mais je ne l'active pas par défaut.
Modifié par Shnoulle (27 Oct 2020 - 15:22)
Modérateur
Bonjour,

Il est possible que l'utilisateur veuille simplement que le focus soit dans l'input invalide (ou le 1er input invalide s'il y en a plusieurs).

Amicalement,
Oui,

C'est peut être cela … j'ai demandé plus de détail à la personne avec le contact (la personne qui a remonté la demande n'écrit pas anglais semble t'il …)
Bonjour,

C'est sans doute trop tard, mais mieux vaut tard que jamais.

Ajouter, modifier ou enlever l'attribut aria-live après que l'élément a été ajouté au DOM ne fonctionne pas.
Pour qu'une live region soit correctement prise en compte avec tous les navigateurs et lecteurs d'écran compatibles, il faut que l'élément possède l'attribut aria-live au moment où il est ajouté au DOM.

La contrainte est la même avec role=alert, car role=alert implique implicitement aria-live=assertive.
Ce n'est jamais trop tard (surtout que j'ai pas de bonnes solution)

aria-live est donc prévu pour indiquer qu'une zone pourrait être mise à jour lors du chargement de la page ?

Ici je ne vois pas réellement comment faire alors … sans empêcher la soumission via le customvalidty : https://demo.sondages.pro/594324#
Ceci entraîne un problème : sans empêcher la soumission mais passer à la page suivante : les données sont enregistrées sur le serveur.

Le statut de l'élément passe bien de valide à invalide. L'erreur est attachée via aria-describedby
Mais bon, si j'ai aucun moyen pour indiquer que le invalid est du à cette erreur sans empêcher la soumission : je vois pas comment faire mieux Smiley decu .
Non, aria-live indique que la zone doit être surveillée, et qu'à chaque changement de contenu, elle doit être relue par le lecteur d'écran.

Le contenu d'une zone aria-live est lue ou relu à deux occasions:

- Quand elle est ajoutée au DOM
- Quand son contenu change


Mais PAS quand l'attribut aria-live est ajouté ou modifié.
Meilleure solution
Oui OK, j'ai compris …

Je reste sur le cumul de aria-describedby et aria-invalid je ne vois pas d'autre solution ppour indiquer que l'erreur vient de cette partie; Avec l'option pour le gestionnaire d'utiliser le customvalidty qui fonctionne plutôt bien.
a écrit :
Je reste sur le cumul de aria-describedby et aria-invalid je ne vois pas d'autre solution ppour indiquer que l'erreur vient de cette partie;


Il n'y a aucun problème avec ça, bien au contraire. Utiliser aria-invalid pour indiquer que le champ est invalide, et mettre le message d'erreur spécifique à ce champ dans un élément lié avec aria-describedby, c'est même très exactement ce qu'il faut faire.
En plus, la bonne pratique veut que le focus soit remis dans le premier champ invalide du formulaire.
Sujet clos
Aller à