Comprendre les WCAG 2.0

Aller au contenu (appuyer sur entrée)

-

Prévention des erreurs (juridiques, financières, de données) :
Comprendre le CS 3.3.4

3.3.4 Prévention des erreurs (juridiques, financières, de données) : pour les pages Web qui entraînent des engagements juridiques ou des transactions financières de la part de l'utilisateur, qui modifient ou effacent des données contrôlables par l'utilisateur dans des systèmes de stockages de données, qui enregistrent les réponses de l'utilisateur à un test ou un examen, au moins l'une des conditions suivantes est vraie : (Niveau AA)

  1. Réversible : les actions d'envoi sont réversibles.

  2. Vérifiée : les données saisies par l'utilisateur sont vérifiées au niveau des erreurs de saisie et la possibilité est donnée à l'utilisateur de les corriger.

  3. Confirmée : un mécanisme est disponible pour revoir, confirmer et corriger les informations avant leur soumission finale.

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'éviter aux utilisateurs en situation de handicap de graves conséquences résultant d'une erreur lorsqu'elles accomplissent une action irréversible. Par exemple, l'achat de billets d'avion non remboursables ou la soumission d'un ordre d'achat d'action à un compte de courtage, sont des transactions financières ayant d'importantes conséquences. Si l'utilisateur a fait une erreur sur la date du voyage, il ou elle peut se retrouver avec un billet non échangeable, ne correspondant pas au bon jour. Si l'utilisateur a fait une erreur sur le nombre d'actions à acheter, il ou elle peut se retrouver avec un nombre supérieur d'actions à celui désiré. Ces deux types d'erreurs impliquent des transactions qui se déroulent dans l'instant et ne peuvent être modifiées après coup, et peuvent s'avérer très coûteuses. De même, il peut s'agir d'une erreur irrécupérable si les utilisateurs modifient ou effacent de façon non intentionnelle des données stockées dans une base de données à laquelle ils auront besoin d'accéder ultérieurement, tel que leur profil de voyage sur un site de services de voyages. Les données liées à un test font partie de cette recommandation car, pour que les tests soient valides, les utilisateurs ne sont pas autorisés à modifier leurs réponses une fois soumises ; les utilisateurs doivent donc avoir la possibilité de s'assurer que leur envoi est correct.

Les utilisateurs en situation de handicap peuvent avoir plus de probabilité de faire des erreurs. Les utilisateurs ayant des difficultés de lecture peuvent inverser les chiffres et les lettres, et ceux ayant une limitation motrice peuvent appuyer sur des touches par erreur. Fournir la possibilité d'annuler des actions permet aux utilisateurs de corriger des erreurs pouvant entraîner de graves conséquences. Fournir la possibilité de relire et corriger des informations donne à l'utilisateur l'occasion de détecter une erreur, avant d'effectuer une action ayant de graves conséquences.

Des données contrôlables par l'utilisateur sont des données destinées à être consultées par les utilisateurs (Ex. nom et adresse pour le compte utilisateur). Ceci ne se réfère pas aux éléments comme les journaux de connexions (logs) Internet ou les données de supervision des moteurs de recherche.

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

  • Le fait de fournir des garde-fous pour éviter des conséquences graves résultant d'erreurs, aide les utilisateurs ayant tout type de limitations fonctionnelles et étant plus susceptibles de faire des erreurs.

Exemples pour le critère de succès 3.3.4

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.4 - Prévention des erreurs (juridiques, financières, de données)

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 (recommandées) supplémentaires pour 3.3.4

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 CS 3.3.4

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

(Aucun échec n'est actuellement documenté

Mots clés

contrôlable par l'utilisateur

donnée auxquelles les utilisateurs ont accès

Note : ceci ne concerne pas les journaux de connexions (logs) Internet et les données de supervision des moteurs de recherche.

Exemple : les champs nom et adresse d'un compte utilisateur.

engagements juridiques

transactions par lesquelles la personne contracte une obligation ou reçoit un bénéfice de nature juridique

Exemple : un contrat de mariage, un échange d'actions (financier et juridique), un legs, un prêt, une adoption, un enrôlement dans l'armée, un contrat de tout type, etc.

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.

mécanisme

processus ou technique pour obtenir un résultat

Note 1 : le mécanisme peut être explicitement fourni par le contenu ou dépendre de plateforme ou de l'agent utilisateur, y compris les technologies d'assistance.

Note 2 : le mécanisme doit satisfaire à tous les critères de succès (d'un niveau donné) pour déclarer un niveau de conformité.

page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.