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)
Réversible : les actions d'envoi sont réversibles.
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.
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). Cela 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
Confirmation d'une commande.
Un revendeur par Internet permet aux clients de faire des achats en ligne. Lorsqu'une commande est envoyée, les informations concernant la commande, dont les articles commandés, la quantité pour chaque article commandé, l'adresse d'expédition et le moyen de paiement, sont affichées de façon à ce que l'utilisateur puisse vérifier qu'elles sont correctes. L'utilisateur peut soit confirmer la commande soit effectuer des modifications.
Vente d'actions :
Un site Web de services financiers permet aux utilisateurs d'acheter et vendre des actions en ligne. Lorsqu'un utilisateur envoie un ordre d'achat ou de vente d'actions, le système vérifie que le marché est ouvert ou non. Si cela se passe durant les heures de fermeture, l'utilisateur est prévenu que la transaction sera une transaction hors ouverture, est averti des risques qu'il y a à traiter en dehors des heures d'ouverture du marché, et se voit offrir la possibilité d'annuler ou de confirmer son ordre.
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 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
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 : lorsqu'une application implique la réalisation d'une transaction légale comme un achat ou le paiement d'un impôt sur le revenu :
Techniques (recommandées) supplémentaires pour 3.3.4
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
Informer l'utilisateur de l'action irréversible qui va advenir (lien à venir)
SCR18 : Fournir une alerte de validation côté client (en anglais) (programmation par script)
Placer le focus dans le champ contenant l'erreur (lien à venir)
Éviter d'utiliser les mêmes mots ou combinaisons de lettres au début de chaque élément d'une liste déroulante (lien à venir)
G199 : Fournir un retour de réussite lorsque les données ont été envoyées avec succès (en anglais)
É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ées auxquelles les utilisateurs ont accès
Note : cela 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 :
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.
- 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 la 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.