WCAG 3.2.2 : Lors de la saisie

Ce que signifie cette règle

WCAG 3.2.2 Sur saisie fait partie du principe Compréhensible et relève de la Règle 3.2 Prévisible. Elle stipule que la modification du paramètre de tout composant d’interface utilisateur ne doit pas entraîner automatiquement un changement de contexte, sauf si l’utilisateur a été informé à l’avance qu’un tel comportement se produira.

Un changement de contexte est une modification majeure du contenu d’une page web qui peut désorienter les utilisateurs qui ne peuvent pas voir la page entière en une fois. Selon la spécification WCAG, les changements de contexte incluent : les changements d’agent utilisateur (navigateur), les changements de fenêtre d’affichage (viewport), les changements de focus et les changements de contenu qui modifient de manière significative la signification de la page. L’envoi d’un formulaire, l’ouverture d’une nouvelle fenêtre ou la navigation vers une autre page constituent tous des changements de contexte. Le simple fait de révéler du contenu supplémentaire, comme un accordéon qui se déploie, n’en constitue pas un.

Le critère s’applique spécifiquement à la modification du paramètre d’un composant d’interface — par exemple, sélectionner un bouton radio, cocher une case ou choisir une option dans une liste déroulante <select> — par opposition à l’activation d’un contrôle (comme cliquer sur un bouton). Si une action nécessite une étape d’activation explicite (appuyer sur Entrée, cliquer sur Envoyer), elle ne relève généralement pas de ce critère. Le schéma problématique est celui où le simple fait de sélectionner une valeur déclenche instantanément une navigation ou un rechargement important de la page sans aucun avertissement.

Ce qui est considéré comme conforme : Un formulaire qui utilise un bouton d’envoi pour traiter les sélections de l’utilisateur, même si ces sélections incluent des listes déroulantes ou des cases à cocher, respecte ce critère. Une liste déroulante qui filtre les résultats sur la même page sans rechargement ni déplacement significatif du focus est conforme. Une page qui informe les utilisateurs à l’avance — par exemple, avec une note visible du type « La sélection d’une langue rechargera la page » — qu’une saisie particulière déclenchera un changement de contexte est également conforme.

Ce qui est considéré comme non conforme : Un sélecteur de pays ou de langue qui redirige automatiquement l’utilisateur vers une nouvelle URL au moment où une option est choisie n’est pas conforme. Un formulaire qui se soumet automatiquement et navigue ailleurs lorsqu’un bouton radio est sélectionné, sans aucun bouton d’envoi, n’est pas conforme. Un widget d’autocomplétion qui déplace le focus clavier vers une nouvelle région de la page sans avertissement lors de la sélection n’est pas conforme non plus.

Exceptions officielles : La spécification WCAG précise que si l’utilisateur est informé du comportement avant d’utiliser le composant, le changement de contexte automatique est acceptable. Cet avertissement doit être présent avant que l’interaction ne se produise, et non après.

Pourquoi c’est important

Les changements de contexte inattendus sont l’une des expériences les plus désorientantes sur le web, et leur impact est considérablement amplifié pour les utilisateurs en situation de handicap. Lorsqu’une page navigue, se recharge ou déplace le focus sans avertissement, les utilisateurs qui ne peuvent pas voir la mise en page visuelle complète de la page perdent totalement leurs repères.

Les utilisateurs de lecteurs d’écran sont particulièrement vulnérables. Lorsqu’une personne aveugle utilisant NVDA ou JAWS sélectionne une option dans une liste déroulante et que la page se recharge ou navigue immédiatement, le lecteur d’écran annonce le nouveau contexte de page depuis le début. L’utilisateur perd la trace de l’endroit où il se trouvait, de ce qu’il faisait, et doit renaviguer sur toute la page pour retrouver ses repères. Ce n’est pas un simple désagrément — cela peut rendre la tâche totalement impossible à accomplir de manière autonome.

Les utilisateurs au clavier uniquement, y compris les personnes ayant des troubles moteurs qui ne peuvent pas utiliser une souris, rencontrent un problème similaire. Ils peuvent naviguer dans un formulaire à l’aide de la touche Tab et des flèches et déclencher accidentellement un changement de contexte qu’ils n’avaient pas l’intention de provoquer. Sans contrôle moteur fin, se remettre d’une navigation de page involontaire peut demander un effort considérable.

Les handicaps cognitifs aggravent encore le problème. Les utilisateurs ayant des troubles de l’attention, des troubles d’apprentissage ou des troubles de la mémoire s’appuient sur des interfaces prévisibles et stables pour comprendre ce qui se passe. Les changements de contexte soudains brisent le modèle mental qu’ils ont construit au cours de la session, les obligeant souvent à recommencer ou à abandonner la tâche.

Les utilisateurs ayant des troubles vestibulaires peuvent ressentir un inconfort physique ou une désorientation lorsque les pages changent de manière inattendue, en particulier si le changement implique une animation ou des déplacements de la position de défilement.

Un scénario concret du monde réel : imaginez une page de paiement d’un site e-commerce en Turquie où un utilisateur sélectionne sa province dans une liste déroulante. Si cette sélection recharge instantanément la page pour mettre à jour les options de livraison, un utilisateur de lecteur d’écran peut soudainement se retrouver en haut de la page sans indication de ce qui s’est passé. Il devra renaviguer à travers tous les champs du formulaire pour retrouver l’endroit où il en était, sans savoir si ses saisies précédentes ont été conservées. Ce type de friction peut amener les utilisateurs à abandonner complètement l’achat.

D’un point de vue ergonomie et SEO, les pages qui se comportent de manière prévisible ont des taux de rebond plus faibles. Les utilisateurs sont moins susceptibles de partir par frustration, et les robots d’indexation des moteurs de recherche peuvent indexer le contenu plus fiablement sans que des redirections inattendues n’interfèrent avec les chemins d’exploration.

Règles Axe-core associées

WCAG 3.2.2 Sur saisie nécessite des tests manuels. Les outils automatisés comme axe-core ne peuvent pas détecter de manière fiable les violations de ce critère, car le comportement problématique est contextuel et dépend de l’intention derrière une interaction, et non simplement de la présence ou de l’absence d’un attribut ou d’une structure HTML spécifique. Un outil peut identifier qu’un élément <select> possède un gestionnaire d’événement onchange, mais il ne peut pas déterminer si ce gestionnaire déclenche un changement de contexte, si l’utilisateur a été averti de cela, ou si le comportement qui en résulte est désorientant en pratique.

• Test manuel requis — Modèles de navigation via onchange : Les analyseurs automatisés peuvent signaler les éléments <select>, <input type='radio'> et <input type='checkbox'> qui ont des gestionnaires d’événements JavaScript (en particulier onchange), mais ils ne peuvent pas déterminer si ces gestionnaires provoquent un changement de contexte. Un testeur humain doit interagir avec chacun de ces contrôles et observer si la page navigue, se recharge, déplace le focus vers une région très différente ou ouvre une nouvelle fenêtre sans étape d’activation explicite de la part de l’utilisateur.
• Test manuel requis — Présence et adéquation de l’avertissement préalable : Même si un changement de contexte est détecté, un outil automatisé ne peut pas déterminer si l’utilisateur en a été suffisamment averti avant d’interagir avec le contrôle. Un humain doit vérifier que tout avertissement préalable est visible avant que le composant ne soit rencontré, clairement formulé et décrit effectivement le comportement qui se produira.
• Test manuel requis — Gestion du focus après saisie : Certaines violations se manifestent par un déplacement du focus vers un emplacement inattendu lors d’un changement de saisie plutôt que par une navigation pure et simple. Les outils automatisés ne peuvent pas suivre de manière fiable les destinations du focus déclenchées par des événements onchange ni confirmer si le placement du focus qui en résulte constitue un changement de contexte désorientant.

Comment tester

1. Base de scan automatisé : Exécutez axe DevTools ou Lighthouse sur la page pour identifier les problèmes signalés au titre de WCAG 3.2. Bien que 3.2.2 nécessite des tests manuels, axe peut faire remonter des problèmes connexes (tels que des étiquettes manquantes ou des problèmes de gestion du focus) qui fournissent un point de départ. Notez tous les contrôles de formulaire — en particulier les listes déroulantes <select>, les groupes de boutons radio et les cases à cocher — pour un suivi manuel.
2. Identifier tous les contrôles de saisie avec des gestionnaires de changement : Dans les outils de développement du navigateur, inspectez le JavaScript de la page ou utilisez le panneau Event Listeners pour identifier tout élément <select>, <input type='radio'>, <input type='checkbox'> ou widget personnalisé qui possède un écouteur d’événement onchange, oninput ou équivalent.
3. Test manuel d’interaction au clavier : En utilisant uniquement le clavier (Tab pour naviguer, flèches pour les options radio/select), interagissez avec chacun des contrôles identifiés. Observez si la sélection d’une option provoque la navigation ou le rechargement de la page, l’ouverture d’une nouvelle fenêtre ou le déplacement du focus vers une partie significativement différente de la page. Si oui, vérifiez si un avertissement visible était affiché avant que le contrôle ne soit rencontré.
4. Test NVDA + Firefox : Lancez Firefox avec NVDA actif. Naviguez jusqu’à chaque contrôle de formulaire à l’aide du curseur virtuel de NVDA (touches fléchées), puis interagissez en mode formulaire (Entrée ou Espace). Sélectionnez des options dans les listes déroulantes et les groupes de boutons radio et écoutez tout message inattendu indiquant un chargement de page, une navigation ou un changement majeur de contexte. Notez si NVDA lit un nouveau titre de page ou une région radicalement différente.
5. Test VoiceOver + Safari (macOS/iOS) : Activez VoiceOver et naviguez jusqu’à chaque contrôle à l’aide de VO+Flèche droite. Interagissez avec les listes déroulantes et les cases à cocher. Si un changement de contexte se produit, VoiceOver annoncera généralement la nouvelle page ou le déplacement du focus. Déterminez si l’utilisateur en avait été averti.
6. Test JAWS + Chrome : Utilisez JAWS en mode curseur virtuel pour naviguer sur la page. Interagissez avec les contrôles de formulaire et surveillez si JAWS annonce un changement de contexte (changement de titre de page, nouvelle URL, position de lecture déplacée) immédiatement après la saisie — sans qu’un bouton d’envoi ait été activé.
7. Test d’observation visuelle : Pour les utilisateurs voyants sans technologie d’assistance, sélectionnez des options dans chaque liste déroulante et groupe de boutons radio et observez si la page navigue ou se recharge de manière inattendue. Si c’est le cas, vérifiez si un texte d’instruction visible avant le contrôle avertissait de ce comportement.

Comment corriger

Liste déroulante à envoi automatique — Incorrect

<!-- BAD: Selecting a country immediately redirects the page -->
<label for='country'>Select Country</label>
<select id='country' name='country' onchange='window.location.href="/region/" + this.value'>
  <option value='tr'>Turkey</option>
  <option value='de'>Germany</option>
  <option value='us'>United States</option>
</select>

Liste déroulante à envoi automatique — Correct

<!-- GOOD: Selection is confirmed via a submit button; no automatic navigation -->
<form action='/region/' method='get'>
  <label for='country'>Select Country</label>
  <select id='country' name='country'>
    <option value='tr'>Turkey</option>
    <option value='de'>Germany</option>
    <option value='us'>United States</option>
  </select>
  <!-- Explicit submit button gives the user control over when navigation occurs -->
  <button type='submit'>Go</button>
</form>

Modèle de bouton radio à envoi automatique — Incorrect

<!-- BAD: Selecting a payment method immediately submits the form -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='this.form.submit()'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='this.form.submit()'>
    Bank Transfer
  </label>
</fieldset>

Modèle de bouton radio à envoi automatique — Correct

<!-- GOOD: onchange can update UI state without navigating; submit requires user action -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='showPaymentDetails(this.value)'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='showPaymentDetails(this.value)'>
    Bank Transfer
  </label>
</fieldset>
<!-- showPaymentDetails() reveals additional fields inline — no context change -->
<div id='payment-details' aria-live='polite'></div>
<button type='submit'>Confirm Payment</button>

Sélecteur de langue avec avertissement préalable — Correct

<!-- ACCEPTABLE: User is warned before interacting that selecting will reload the page -->
<p id='lang-notice'>Selecting a language will immediately reload the page.</p>
<label for='lang-select'>Language</label>
<select
  id='lang-select'
  name='lang'
  aria-describedby='lang-notice'
  onchange='window.location.href="/" + this.value + "/"'
>
  <option value='en'>English</option>
  <option value='tr'>Türkçe</option>
  <option value='de'>Deutsch</option>
</select>
<!-- The aria-describedby links the warning to the control for screen reader users -->

Erreurs courantes

• Attacher des affectations window.location.href directement à l’attribut onchange d’un élément <select> sans bouton d’envoi, ce qui provoque une navigation immédiate de la page au moment où l’utilisateur choisit une option.
• Utiliser this.form.submit() dans le gestionnaire onchange d’un bouton radio, ce qui soumet l’ensemble du formulaire et navigue ailleurs dès qu’une option radio est sélectionnée — avant que l’utilisateur puisse vérifier ses choix.
• Placer l’avertissement préalable après le contrôle dans le DOM de sorte que les utilisateurs de lecteurs d’écran et les navigateurs au clavier rencontrent le contrôle avant d’entendre ou de lire l’avertissement concernant le comportement qu’il déclenche.
• Afficher l’avertissement préalable uniquement sous forme d’infobulle ou de texte d’espace réservé (placeholder) qui n’est pas exposé de manière fiable aux technologies d’assistance, laissant les utilisateurs de lecteurs d’écran sans indication qu’un changement de contexte suivra leur saisie.
• Construire des widgets de liste déroulante personnalisés à l’aide d’éléments <div> et <ul> qui déclenchent une navigation lors de la sélection via JavaScript mais manquent de structure sémantique permettant aux testeurs ou aux surcouches d’accessibilité de les identifier comme des contrôles interactifs nécessitant un examen au titre de 3.2.2.
• Déclencher un envoi automatique du formulaire sur le dernier champ d’un formulaire (par exemple, un champ de code PIN ou OTP) lorsque le nombre requis de caractères est atteint, sans informer l’utilisateur que cela se produira.
• Ouvrir une boîte de dialogue modale ou une nouvelle fenêtre de navigateur en réponse à la coche d’une case, sans aucun avertissement préalable — cela constitue un changement de contexte car cela déplace de manière significative la fenêtre d’affichage et le focus de l’utilisateur.
• Confondre des mises à jour de contenu prévisibles dans la page avec des changements de contexte et ajouter des boutons d’envoi inutiles autour d’interactions déjà acceptables (comme un filtre de recherche en direct), ce qui peut encombrer l’interface — les équipes doivent comprendre que les mises à jour en ligne non désorientantes ne nécessitent pas d’étape d’envoi.
• Se fier uniquement aux scans d’accessibilité automatisés et considérer que 3.2.2 est respecté parce qu’aucune règle automatisée ne l’a signalé, sans effectuer les tests manuels obligatoires au clavier et avec lecteur d’écran que ce critère exige.
• Appliquer un gestionnaire onchange qui change le contexte à un <select> utilisé pour trier ou filtrer dans une liste de résultats, provoquant un rechargement complet de la page plutôt qu’une mise à jour AJAX, et omettre d’avertir les utilisateurs que ce rechargement se produira lors de la sélection.

Lien avec la réglementation d’accessibilité de la Turquie

La Circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires en matière d’accessibilité web basées sur WCAG 2.2. WCAG 3.2.2 Sur saisie est un critère de Niveau A, qui représente le niveau minimal de conformité dans le cadre de la circulaire — ce qui signifie que la conformité n’est pas optionnelle mais légalement requise pour toutes les entités concernées.

La circulaire définit un calendrier de mise en œuvre à deux niveaux. Les institutions publiques — y compris les ministères, les municipalités, les universités d’État et les agences gouvernementales — doivent atteindre une conformité complète au Niveau A dans un délai de un an à compter de la publication de la circulaire. Les entités du secteur privé couvertes par la réglementation disposent d’une fenêtre de deux ans pour se mettre en conformité.

Les types d’entités suivants sont explicitement couverts par la circulaire et doivent donc veiller à ce que leurs services numériques respectent WCAG 3.2.2 : plateformes d’e-commerce, institutions publiques à tous les niveaux de gouvernement, banques et institutions financières, hôpitaux et prestataires de soins de santé, entreprises de télécommunications comptant 200,000 abonnés ou plus, agences de voyage agréées, entreprises de transport privées et écoles privées autorisées par le ministère de l’Éducation nationale (MoNE).

Pour ces entités, une violation de WCAG 3.2.2 — comme un sélecteur de langue sur un portail bancaire qui redirige automatiquement après la sélection, ou un formulaire de prise de rendez-vous d’hôpital qui se soumet automatiquement lorsqu’un bouton radio de service est choisi — constitue une non-conformité réglementaire directe. Étant donné que la Turquie compte une population importante d’utilisateurs en situation de handicap et que les services numériques gouvernementaux deviennent de plus en plus le canal principal permettant aux citoyens d’accéder aux services publics, les enjeux pratiques liés à l’ignorance de ce critère sont considérables.

Les organisations soumises à la circulaire doivent traiter les tests WCAG 3.2.2 comme une étape d’audit obligatoire pendant l’assurance qualité. Comme les outils automatisés ne peuvent pas détecter les violations de ce critère, des tests manuels réalisés par des spécialistes de l’accessibilité formés — couvrant l’interaction au clavier, le comportement des lecteurs d’écran avec NVDA et JAWS, et l’examen explicite de toutes les interactions déclenchées par onchange — doivent être intégrés au processus de conformité. Il est recommandé de documenter les résultats des tests et toute exception acceptée (avec avertissements préalables en place) afin de démontrer la diligence raisonnable auprès des autorités de régulation.