Comprendre les WCAG 2.0

Aller au contenu (appuyer sur entrée)

-

Identification des erreurs :
Comprendre le CS 3.3.1

3.3.1 Identification des erreurs : si une erreur de saisie est détectée automatiquement, l'élément en erreur est identifié et l'erreur est décrite à l'utilisateur sous forme de texte. (Niveau A)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que les utilisateurs sont avertis qu'une erreur s'est produite et qu'ils peuvent déterminer la nature de l'erreur. Le message d'erreur devra être aussi précis que possible. Dans le cas d'un échec d'envoi d'un formulaire, afficher de nouveau le formulaire en indiquant les champs erronés est insuffisant pour certains utilisateurs pour leur indiquer qu'une erreur s'est produite. Les utilisateurs de lecteurs d'écrans par exemple, n'auront pas connaissance de l'erreur tant qu'ils ne seront pas parvenus jusqu'à l'indicateur. Ils peuvent ainsi abandonner complètement le formulaire avant même de rencontrer l'indicateur d'erreur, en pensant tout simplement que la page n'est pas fonctionnelle.

L'identification et la description d'une erreur peuvent être combinées avec des informations programmées que les agents utilisateurs ou les technologies d'assistance peuvent utiliser pour identifier une erreur et fournir des informations concernant cette erreur à l'utilisateur. Par exemple, certaines technologies peuvent indiquer que la saisie de l'utilisateur ne doit pas dépasser une longueur spécifique, ou bien qu'un champ du formulaire est obligatoire. Actuellement, peu de technologies supportent ce genre d'informations programmées, mais le critère de succès ne les requiert pas, ni ne les interdit.

Il est parfaitement envisageable d'indiquer des erreurs d'une autre façon, comme par exemple à l'aide d'une image, d'une couleur spécifique, etc.., en plus de la description textuelle.

Voir aussi Comprendre le critère de succès 3.3.3 Suggestion après une erreur.

Avantages spécifiques du critère de succès 3.3.1 :

  • Fournir des informations concernant des erreurs de saisie dans un texte permet aux utilisateurs aveugles ou daltoniens de comprendre qu'une erreur a été commise.

  • Ce critère de succès peut aider les personnes ayant des limitations cognitives, de langage, ainsi que celles ayant des difficultés d'apprentissage qui ont des difficultés à comprendre la signification des informations présentées sous forme d'icône, ou par d'autres repères visuels.

Exemples pour le critère de succès 3.3.1

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.1 - Identification des erreurs

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 répondre aux exigences de 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.

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 A : si un formulaire contient des champs dont les informations utilisateurs sont obligatoires.

  1. G83 : Fournir une description textuelle pour identifier un champ obligatoire qui n'a pas été rempli (en anglais)

  2. SCR18 : Fournir une alerte de validation côté client (en anglais) (programmation par script)

Situation B : si une information fournie par l'utilisateur requiert d'être dans un format de données spécifique ou contenir certaines valeurs.

  1. G84 : Fournir une description textuelle lorsque l'utilisateur fournit une information qui n'est pas dans la liste des valeurs permises (en anglais)

  2. G85 : Fournir une description textuelle quand la saisie de l'utilisateur n'entre pas dans les formats ou les valeurs requises (en anglais)

  3. SCR18 : Fournir une alerte de validation côté client (en anglais) (programmation par script)

  4. SCR32 : Fournir une validation côté client et ajouter un texte décrivant l'erreur via le DOM (en anglais) (programmation par script)

  5. FLASH12 : Fournir une validation côté client et ajouter le texte des erreurs via la description accessible (en anglais) (Flash)

Techniques (recommandées) supplémentaires pour 3.3.1

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques recommandées 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.

Échecs fréquents pour le CS3.3.1

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.3.1.

(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 :

  1. L'information qui est demandée par la page web mais oubliée par l'utilisateur

  2. L'information qui est fournie par l'utilisateur mais qui ne correspond pas au format ou aux valeurs des données attendus.