Saisie redondante WCAG (3.3.7) et aide cohérente (3.2.6) dans un tunnel de commande

Saisie redondante WCAG 3.3.7 : ce que dit exactement le critère

L'objectif affiché par le W3C est simple : rendre plus facile la réalisation des processus en plusieurs étapes. La consigne pratique tient en une phrase : ne demandez pas deux fois la même information dans la même activité. La raison est tout aussi directe : certaines personnes ayant des handicaps cognitifs ont des difficultés à se souvenir de ce qu'elles ont saisi auparavant.

Le texte du critère prévoit deux façons de se conformer lorsqu'une information doit être saisie à nouveau dans le même processus :

• la pré-remplir automatiquement (auto-populated) ;
• la rendre disponible à la sélection pour l'utilisateur (available for the user to select).

Pourquoi éviter de redemander une information

Le W3C explique que l'information qu'il faut mémoriser pour la ressaisir peut constituer un obstacle important pour les personnes ayant des difficultés cognitives ou de mémoire. Tous les utilisateurs ressentent une fatigue mentale naturelle et progressive au fil des étapes d'un processus, et cette fatigue est accélérée par l'effort de rappel depuis la mémoire de travail à court terme. Les personnes ayant des troubles d'apprentissage ou des handicaps cognitifs y sont particulièrement sensibles.

Conséquence concrète : obliger quelqu'un à se rappeler une information déjà saisie peut le pousser à abandonner, ou à ressaisir la même information de façon incorrecte. Le W3C cite trois profils de bénéficiaires :

• les personnes ayant des difficultés de mémoire de travail à court terme, pour qui ne pas avoir à se souvenir réduit le stress et le risque d'erreur ;
• les personnes qui ont du mal à former de nouveaux souvenirs ou à rappeler une information, qui peuvent aller au bout du processus sans dépendre inutilement de leur mémoire ;
• les personnes ayant un handicap moteur, par exemple utilisant un contacteur (switch control) ou la saisie vocale, qui ont moins de texte à saisir.

Le périmètre du critère 3.3.7 : processus, session et autocomplétion

L'autocomplétion du navigateur ne suffit pas. Le W3C précise que c'est le contenu, c'est-à-dire le site, qui doit fournir l'information déjà enregistrée, ou éviter de la redemander.

Le critère n'impose pas non plus de conserver les informations d'une session à l'autre. Un processus se définit par une activité ; il ne s'applique pas quand l'utilisateur revient après avoir fermé la session ou être allé ailleurs. En revanche, un processus peut s'étendre sur plusieurs domaines : si votre tunnel de commande passe par un prestataire de paiement tiers, cette étape entre dans le périmètre.

Le critère ne s'applique pas si l'information est fournie par une autre méthode, par exemple en téléversant un CV sous forme de document. Il ne contient pas d'exigence ni d'exception propre à la vie privée, mais le W3C rappelle qu'en mettant en place le pré-remplissage, vous devriez veiller à protéger les données conservées, même temporairement, pendant le processus : une mauvaise implémentation pourrait exposer davantage de données personnelles.

L'expression « disponible à la sélection » n'est pas prescriptive : elle laisse de la marge quand le pré-remplissage n'est pas possible. Les données proposées doivent cependant se trouver sur la même page, idéalement visibles par défaut et placées près du champ concerné, mais elles peuvent aussi être ailleurs sur la page, y compris dans un composant affichable et masquable. Concrètement, il peut s'agir de permettre à l'utilisateur de :

• Sélectionner une valeur pour remplir un champ, y compris depuis une liste déroulante.
• Sélectionner du texte affiché sur la page et le copier dans un champ.
• Cocher une case pour reprendre des valeurs déjà saisies, comme « mon adresse de facturation est identique à mon adresse de livraison ».

Les trois exceptions à la saisie redondante

Le critère prévoit trois cas où redemander l'information reste admis. Les voici, avec les précisions apportées par le W3C.

• La ressaisie est essentielle : par exemple un jeu de mémoire, qui n'aurait plus de sens si les réponses précédentes étaient fournies.
• L'information est nécessaire à la sécurité du contenu : par exemple empêcher qu'un mot de passe soit affiché ou copié. Si le système demande à l'utilisateur de créer manuellement un mot de passe qui n'est pas affiché, lui faire confirmer ce nouveau mot de passe est permis.
• L'information déjà saisie n'est plus valide : on peut alors demander à l'utilisateur de la saisir à nouveau.

Exemples dans un tunnel de commande

Les exemples du W3C se transposent directement à un parcours d'achat. À l'étape adresse, proposez une case permettant de confirmer que l'adresse de facturation et l'adresse de livraison sont identiques. Si un client valide le formulaire de paiement avec un numéro de carte incorrect, la page affiche un message d'erreur, mais les informations soumises, dont le numéro de carte, ne sont pas effacées du formulaire.

Autre cas cité : un formulaire d'achat d'ordinateur demande l'identifiant professionnel de l'utilisateur à la première étape ; à la troisième, il réaffiche cet identifiant, permet de le modifier, mais propose par défaut celui déjà saisi. De même, une page de résultats de recherche pré-remplit le champ de recherche avec le terme saisi précédemment dans le même processus.

L'extrait ci-dessous illustre la case « adresse identique » : cochée, elle reprend les valeurs de livraison dans les champs de facturation. Parmi les techniques suffisantes listées par le W3C figurent G221, fournir les données d'une étape précédente du processus, et, comme technique future potentielle, le fait de ne pas demander deux fois la même information.

<fieldset>
  <legend>Adresse de facturation</legend>
  <input type="checkbox" id="same-address">
  <label for="same-address">Identique à l'adresse de livraison</label>

  <label for="bill-street">Adresse</label>
  <input id="bill-street" name="bill-street">
  <label for="bill-city">Ville</label>
  <input id="bill-city" name="bill-city">
</fieldset>

<script>
  // Valeurs saisies à l'étape « livraison » du même processus
  const shipping = JSON.parse(sessionStorage.getItem('shipping') || '{}');
  document.getElementById('same-address').addEventListener('change', (e) => {
    if (!e.target.checked) return;
    document.getElementById('bill-street').value = shipping.street || '';
    document.getElementById('bill-city').value = shipping.city || '';
  });
</script>

Aide cohérente WCAG 3.2.6 : garder l'aide au même endroit

Le critère 3.2.6 vise à rendre l'aide et le support plus faciles à trouver. Si une page contient l'un des mécanismes d'aide listés et que ce mécanisme est répété sur plusieurs pages d'un ensemble de pages web, il doit apparaître dans le même ordre par rapport aux autres contenus de la page, sauf si un changement est initié par l'utilisateur. Le mécanisme peut figurer directement sur la page ou passer par un lien direct vers une autre page qui contient l'information.

« Le même ordre » s'entend comme l'ordre du contenu quand la page est sérialisée. Pour tester, regardez l'aide par rapport au reste : les contenus présents sur l'ensemble des pages qui précèdent l'aide sur les autres pages doivent la précéder sur cette page, et ceux qui la suivent doivent la suivre. Une aide placée visuellement ailleurs mais dans le même ordre sériel n'échoue pas au critère, même si ce n'est pas utile pour l'utilisateur. Le W3C recense quatre types de mécanismes, sans ordre de priorité, avec des exemples typiques :

• coordonnées humaines, par exemple : numéro de téléphone, adresse e-mail, horaires d'ouverture ;
• mécanisme de contact humain, par exemple : messagerie, chat, formulaire de contact, réseau social ;
• option d'aide autonome, par exemple : FAQ à jour, page « Comment faire », page de support ;
• mécanisme de contact entièrement automatisé, comme un chatbot.

Exceptions et bonnes pratiques pour l'aide cohérente

Le critère n'oblige pas à fournir de l'aide : il s'applique seulement aux pages qui en contiennent, et l'absence d'aide sur certaines pages n'est pas une non-conformité. Il ne s'étend pas aux PDF ou autres documents statiques téléchargés, n'exige pas qu'un humain soit disponible en permanence, et permet à des ensembles de pages distincts (par exemple l'application et le site marketing) d'avoir des emplacements différents, même si le W3C juge préférable de rester aussi cohérent que possible entre des ensembles liés.

L'exception « changement initié par l'utilisateur » couvre par exemple le zoom, l'orientation ou la taille de la fenêtre : l'aide peut être placée autrement sur un petit écran, même si le W3C estime qu'un emplacement cohérent, visuellement et dans le code, reste le plus utilisable. Naviguer d'une page à l'autre n'en est pas un ; se connecter ou se déconnecter non plus, en général, sauf si la connexion mène à un ensemble de pages distinct.

Dans votre tunnel de commande, si vous affichez un lien « Contact » ou le numéro du service client sur le panier, l'étape livraison et l'étape paiement, gardez-le au même rang par rapport au reste du contenu, par exemple dans l'en-tête. La technique suffisante citée est G220, fournir un lien de contact à un emplacement cohérent ; l'échec répertorié est un emplacement d'aide incohérent. Enfin, dans une section de conseils que le critère n'exige pas, le W3C indique que les chatbots peuvent bien fonctionner, notamment pour les personnes ayant des handicaps cognitifs, s'ils reconnaissent les mots mal orthographiés, donnent des coordonnées humaines quand ils ne parviennent pas à fournir une réponse satisfaisante après 3 tentatives, et peuvent être fermés en une seule interaction puis rappelés par un lien ou un bouton.

Questions fréquentes

À lire aussi sur Conformly

• Comprendre le référentiel RGAA 5
• Accessibilité des sites e-commerce
• Fiche détaillée du critère RGAA 11.12

Sources

Article appuyé sur les sources officielles citées en fin de page.

• W3C — Comprendre 3.3.7
• W3C — Comprendre 3.2.6