Suggestion après une erreur :
Comprendre le CS 3.3.3
3.3.3 Suggestion après une erreur : si une erreur de saisie est automatiquement détectée et que des suggestions de corrections sont connues, ces suggestions sont alors proposées à l'utilisateur à moins que cela puisse compromettre la sécurité ou la finalité du contenu. (Niveau AA)
Objectif de ce critère de succès
L'objectif de ce critère de succès est d'assurer que les utilisateurs obtiennent les suggestions appropriées pour corriger une erreur de saisie quand cela est possible.
Le critère de succès 3.3.1 fournit des notifications d'erreurs. Cependant, les personnes ayant des limitations cognitives peuvent rencontrer des difficultés pour corriger les erreurs. Les personnes ayant des limitations visuelles pourront ne pas être capables de comprendre ce qu'il faut faire pour corriger une erreur. Dans le cas d'un échec de l'envoi d'un formulaire, les utilisateurs sont susceptibles d'abandonner le formulaire parce que, bien qu'ils soient informés qu'une erreur s'est produite, ils peuvent ne pas être sûrs de la manière de la corriger, même s'ils sont alertés qu'elle s'est produite.
L'auteur du contenu doit pouvoir fournir une description de l'erreur, ou l'agent utilisateur doit pouvoir fournir la description d'une erreur basée sur une technologie spécifique, ou sur une information déterminée par un programme informatique.
Avantages spécifiques du critère de succès 3.3.3 :
Fournir une information sur la manière de corriger les erreurs de saisie permet aux utilisateurs ayant des difficultés d'apprentissage à remplir un formulaire avec succès. Les utilisateurs aveugles ou ayant une vision limitée comprennent plus facilement la nature de l'erreur de saisie et comment la corriger. Les personnes ayant des difficultés de mouvement peuvent réduire le nombre de fois où elles doivent changer une valeur à saisir.
Exemples pour le critère de succès 3.3.3
Aide complémentaire pour corriger une erreur de saisie
Le résultat affiché dans un formulaire incorrectement saisi décrit une erreur de saisie à son emplacement dans la page parmi les saisies correctes et offre une aide complémentaire pour le champ de formulaire qui a provoqué l'erreur.
Suggestions parmi une liste limitée de valeurs.
Un champ de saisie requiert qu'un nom de mois soit saisi. Si l'utilisateur saisit la valeur « 12 », la suggestion de correction peut inclure
Une liste des valeurs acceptées, comme par exemple « Choisissez parmi : janvier, février, mars, avril, mai, juin, juillet, août, septembre, octobre, novembre, décembre ».
Une description de la liste des valeurs, par exemple, « Indiquez le nom du mois ».
La conversion de la donnée saisie interprétée comme différente d'un format de mois, exemple, « Voulez-vous dire « Décembre » ?»
Ressources liées
Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.
(Aucune ressource n'est actuellement documentée)
Techniques et échecs pour le critère de succès 3.3.3 - Suggestion après une erreur
Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.
Note : dans certains cas, plus d'une de ces situations s'applique. Par exemple, quand un champ obligatoire requiert que la donnée soit dans un format spécifique.
Techniques suffisantes
Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.
Situation B : si un champ doit être dans un format de données spécifique :
SCR18 : Fournir une alerte de validation côté client (en anglais) (programmation par script)
SCR32 : Fournir une validation côté client et ajouter un texte décrivant l'erreur via le DOM (en anglais) (programmation par script)
Situation C : l'information saisie par l'utilisateur est requise parmi une liste limitée de valeurs :
SCR18 : Fournir une alerte de validation côté client (en anglais) (programmation par script)
SCR32 : Fournir une validation côté client et ajouter un texte décrivant l'erreur via le DOM (en anglais) (programmation par script)
Techniques (recommandées) supplémentaires pour 3.3.3
Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.
G139 : Créer un mécanisme permettant à l'utilisateur d'aller directement aux erreurs. (en anglais)
Rendre les messages d'erreurs faciles à comprendre et à distinguer du reste du texte de la page Web (lien à venir)
Valider l'envoi du formulaire sur le serveur (lien à venir)
Lorsque les informations obligatoires n'ont pas été fournies, ajouter des descriptions ou des exemples d'informations correctes en plus de l'identification du champ obligatoire (lien à venir)
Répéter et accentuer les suggestions pour la correction de chaque erreur de saisie dans le contexte de son champ de formulaire (lien à venir)
Donner à l'utilisateur un moyen d'aller de chaque élément dans une liste de suggestions vers son champ de formulaire correspondant (lien à venir)
Proposer une aide contextuelle supplémentaire pour le champ de formulaire qui doit être modifié (lien à venir)
Accepter la saisie de données dans des formats variés (lien à venir)
G199 : Fournir un retour de réussite lorsque les données ont été envoyées avec succès (en anglais)
Techniques permettant de proposer des suggestions à l'utilisateur. (recommandées)
Fournir une description textuelle contenant des informations sur le nombre d'erreurs de saisie, des suggestions de corrections pour chaque élément, et des instructions sur la façon de procéder (lien à venir)
Fournir une description textuelle contenant des suggestions de correction qui doit être le premier élément (ou l'un des premiers éléments) du contenu, ou mettre en évidence ces informations dans le contenu (lien à venir)
Afficher les erreurs et suggestions dans le contexte du formulaire original (par exemple, réafficher un formulaire dans lequel les erreurs de saisie et les suggestions de correction sont surlignées et affichées dans le contexte du formulaire original) (lien à venir)
Techniques HTML (recommandées)
Fournir « des exemples corrects » de données et de formats de données en tant que texte initial dans les champs de formulaires obligatoires (lien à venir)
Proposer des liens vers un texte suggérant une correction « à proximité » des champs de formulaire, ou fournir le texte suggérant la correction lui-même directement sur la page Web « à côté des » champs de formulaire (lien à venir)
Techniques de programmation par script côté client (recommandées)
SCR18 : Fournir une alerte de validation côté client (en anglais) (programmation par Script)
Fournir une validation côté client et ajouter un texte d'erreur via le DOM (lien à venir)
Appeler une fonction à partir de l'action d'envoi d'un formulaire afin d'effectuer une validation côté client (lien à venir)
Échecs fréquents pour le CS 3.3.3
Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.3.3.
(Aucun échec n'est actuellement documenté)
Mots clés
- erreur de saisie
information fournie par l'utilisateur qui n'est pas acceptée
Note : cela inclut :
L'information qui est demandée par la page web mais oubliée par l'utilisateur
L'information qui est fournie par l'utilisateur mais qui ne correspond pas au format ou aux valeurs des données attendus.