WCAG 3.2.5 : Changement sur demande

Ce que signifie cette règle

WCAG 3.2.5 Changement sur demande est un critère de niveau AAA relevant du principe Compréhensible. Il stipule que les changements de contexte doivent être initiés uniquement par l’utilisateur, et non déclenchés automatiquement par le système. Un « changement de contexte » est défini dans les WCAG comme une modification majeure du contenu de la page web qui, sans que l’utilisateur en ait conscience, peut désorienter les utilisateurs qui ne peuvent pas voir la page entière en une seule fois. Cela inclut les changements de l’agent utilisateur (navigateur), de la fenêtre d’affichage (viewport), du focus ou du contenu qui modifient de manière significative la signification de la page.

Plus précisément, le critère interdit tout mécanisme qui provoque un changement de contexte sans demande explicite de l’utilisateur. Il étend les exigences de 3.2.1 (Au focus) et 3.2.2 (À la saisie) en couvrant tous les scénarios restants où des changements de contexte automatiques pourraient se produire — y compris, sans s’y limiter : les pages qui se rafraîchissent automatiquement, les carrousels qui avancent automatiquement et entraînent une navigation, les balises meta de redirection avec des délais courts, la navigation déclenchée par JavaScript à la fin de la saisie d’un champ de formulaire, et l’ouverture de nouvelles fenêtres ou onglets sans initiative de l’utilisateur.

Pour satisfaire ce critère, l’une des deux conditions suivantes doit être remplie : soit les changements de contexte ne sont déclenchés que par une action explicite et délibérée de l’utilisateur (comme l’activation d’un bouton ou d’un lien), soit un mécanisme est fourni permettant à l’utilisateur de désactiver les changements de contexte automatiques avant qu’ils ne se produisent. Par exemple, si une page se rafraîchit automatiquement toutes les 30 secondes et navigue vers un nouveau contenu, elle échoue — à moins qu’un contrôle clairement étiqueté n’existe pour désactiver ce comportement avant que le premier rafraîchissement n’ait lieu. Se contenter de fournir un avertissement après coup n’est pas suffisant.

Le critère s’applique largement à tout contenu web interactif et dynamique. Les éléments et comportements couramment concernés incluent : les redirections via <meta http-equiv='refresh'>, les appels JavaScript à window.location ou history.pushState déclenchés par des minuteries, les gestionnaires d’événement onchange sur les éléments <select> qui naviguent vers une nouvelle URL, les formulaires soumis automatiquement, la navigation déclenchée par le focus, et tout composant qui fait défiler automatiquement, fait avancer des diapositives ou modifie l’ensemble de contenu visible sans intervention de l’utilisateur.

Une exception officielle importante : si le changement de contexte répond à un paramètre que l’utilisateur a configuré explicitement et en connaissance de cause — par exemple, un panneau de préférences utilisateur où l’utilisateur sélectionne « rafraîchissement automatique toutes les minutes » — le comportement automatique est autorisé parce que l’utilisateur l’a demandé. La distinction clé est de savoir si l’utilisateur a fait un choix informé et délibéré pour activer le comportement automatique, ou s’il le rencontre de manière inattendue.

Pourquoi c’est important

Les changements de contexte inattendus comptent parmi les expériences les plus désorientantes sur le web, et leur impact varie considérablement selon les différents groupes d’utilisateurs en situation de handicap.

Pour les personnes aveugles qui s’appuient sur des lecteurs d’écran, une navigation soudaine vers une autre page ou un rafraîchissement du contenu peut faire sauter le curseur de lecture à un endroit complètement différent de la page — ou le réinitialiser en haut — sans aucune annonce. Si un utilisateur est en milieu de phrase dans un long article et que la page se redirige automatiquement vers une nouvelle URL, il perd complètement sa position et peut ne pas comprendre ce qui s’est passé ni comment revenir en arrière. Les lecteurs d’écran comme NVDA, JAWS et VoiceOver n’annoncent pas toujours les événements de navigation au niveau de la page de manière cohérente ou en temps voulu, de sorte que les utilisateurs peuvent être confus quant à l’endroit où ils se trouvent et à ce qui a changé.

Pour les utilisateurs ayant des limitations motrices qui naviguent au clavier, avec un pointeur de tête, un contacteur ou une technologie de suivi oculaire, les changements de focus inattendus peuvent être catastrophiques. Si le focus est déplacé par programmation sans action de l’utilisateur — par exemple, lorsqu’un formulaire passe automatiquement au champ suivant dès que le précédent est complété — l’utilisateur peut perdre la notion de sa position et être contraint de renaviguer laborieusement pour retrouver l’endroit où le système l’a envoyé. Pour les utilisateurs dont les dispositifs d’entrée exigent un effort physique important par frappe, cette renavigation représente un véritable obstacle d’accessibilité.

Les utilisateurs ayant des handicaps cognitifs, y compris ceux ayant des troubles de l’attention, des troubles de la mémoire ou des troubles anxieux, sont particulièrement vulnérables aux changements inattendus. Les changements de page automatiques brisent leur modèle mental de l’interface. Un utilisateur qui fait une pause pour lire des instructions et constate ensuite que la page a été rechargée risque de se sentir confus ou en détresse. Cette perturbation peut rendre impossible la réalisation de transactions ou la consultation d’informations de manière autonome.

Pour les utilisateurs ayant des troubles vestibulaires, les changements visuels rapides et inattendus — comme un carrousel qui avance automatiquement et déclenche également une navigation — peuvent provoquer des symptômes physiques tels que des vertiges et des nausées. Même les utilisateurs voyants sans handicap diagnostiqué bénéficient d’interfaces prévisibles : les recherches montrent de manière constante que les navigations inattendues augmentent les taux d’erreur et d’abandon de tâche dans tous les groupes d’utilisateurs.

Un scénario concret du monde réel : un site de e-commerce turc soumet automatiquement un formulaire de filtre de produits au moment où un utilisateur sélectionne une valeur dans une liste déroulante — en naviguant vers une nouvelle URL de résultats de recherche. Un utilisateur n’utilisant que le clavier, qui parcourt les filtres avec la touche Tab pour sélectionner plusieurs critères, constate que la sélection de la première option recharge immédiatement la page et réduit le panneau de filtres. Il doit rouvrir le panneau, renaviguer jusqu’à sa position de départ et réessayer — potentiellement dans une boucle qui rend la fonctionnalité totalement inutilisable. Selon l’Organisation mondiale de la Santé, environ 1,3 milliard de personnes dans le monde vivent avec une forme de handicap, et des schémas comme celui-ci les excluent de manière disproportionnée des services numériques.

Du point de vue de l’ergonomie et du référencement (SEO), les pages qui se redirigent ou se rafraîchissent automatiquement ont également tendance à présenter des taux de rebond plus élevés, car les utilisateurs qui rencontrent un comportement inattendu partent souvent. Les moteurs de recherche peuvent également pénaliser les redirections inattendues qui diffèrent entre les sessions du robot d’indexation et celles de l’utilisateur, ce qui fait que la conformité à 3.2.5 est alignée avec une bonne hygiène de SEO technique.

Règles Axe-core associées

WCAG 3.2.5 nécessite des tests manuels, car les outils automatisés ne peuvent pas détecter de manière fiable si un changement de contexte a été initié par l’utilisateur ou déclenché automatiquement. La distinction dépend de la compréhension de l’intention de l’utilisateur et du flux d’interaction, ce qui requiert un jugement humain. Aucune règle axe-core ne correspond directement à la portée complète de ce critère. Cependant, les considérations suivantes s’appliquent aux tests automatisés et semi-automatisés :

• Aucune règle axe-core directe (tests manuels requis) : Axe-core et Lighthouse ne peuvent pas détecter les navigations déclenchées par JavaScript, les pages qui se rafraîchissent automatiquement ou les formulaires soumis automatiquement, car ces comportements dépendent des conditions d’exécution, du timing et de l’état d’interaction de l’utilisateur que des analyses statiques ou scriptées ne peuvent pas reproduire. Un analyseur qui observe le DOM à un instant donné ne peut pas déterminer si window.location.href est défini en réponse à une minuterie ou à un clic utilisateur.
• Détection de meta refresh (automatisation partielle possible) : Certains outils automatisés, y compris d’anciennes règles axe et des extensions de navigateur, peuvent signaler la présence de <meta http-equiv='refresh' content='0; url=...'> dans l’en-tête du document. Cependant, axe-core ne dispose pas d’une règle de production dédiée pour cela dans la version 4.10. Une inspection manuelle du code source de la page et des en-têtes HTTP est nécessaire pour vérifier qu’aucune redirection automatique n’a lieu.
• Analyse des écouteurs d’événements (manuelle) : La détection des gestionnaires onchange sur les éléments <select> qui déclenchent une navigation nécessite une revue de code manuelle ou l’utilisation des outils de développement du navigateur pour inspecter les écouteurs d’événements attachés. Les analyses automatisées observent le DOM rendu mais pas les conséquences comportementales de l’interaction avec chaque élément.
• Vérification de la gestion du focus (manuelle) : Le fait de savoir si le focus se déplace de manière inattendue à la suite d’un changement de contexte initié par le système — plutôt que par une action de l’utilisateur — nécessite qu’un testeur interagisse réellement avec la page et observe le comportement du focus en temps réel, en utilisant un clavier et éventuellement un lecteur d’écran.

Comment tester

1. Analyse automatisée (base) : Exécutez axe DevTools ou Lighthouse sur la page pour détecter tout problème signalé lié aux redirections ou à la gestion du focus. Dans Chrome DevTools, ouvrez le panneau Lighthouse et lancez un audit Accessibilité. Dans l’extension axe DevTools, cliquez sur « Analyze » et examinez les résultats. Notez qu’un résultat automatisé sans problème ne confirme pas la conformité à 3.2.5 — les tests manuels sont essentiels.
2. Inspection des meta refresh : Ouvrez la page dans un navigateur, faites un clic droit et sélectionnez « Afficher le code source de la page », puis recherchez (Ctrl+F / Cmd+F) http-equiv ou refresh. Toute balise <meta http-equiv='refresh'> avec une URL ou avec un délai de plus de 72 heures sans mécanisme pour la désactiver constitue un échec.
3. Observation du comportement de la page dans le temps : Chargez la page et attendez sans interagir pendant 2–5 minutes. Surveillez tout changement automatique de contenu, rechargement de page, événement de navigation ou ouverture de nouvelles fenêtres. Vérifiez les changements dans la barre d’adresse et le titre de l’onglet du navigateur. Si quelque chose se produit sans votre intervention, le critère est probablement non respecté.
4. Test des contrôles de formulaire et des listes déroulantes : En utilisant uniquement le clavier (Tab, flèches, Entrée, Espace), naviguez jusqu’à chaque élément <select>, groupe de boutons radio ou case à cocher. Modifiez les valeurs et observez si une navigation ou un changement majeur de contenu se produit immédiatement après la sélection — avant que vous n’activiez un bouton de soumission. Si c’est le cas, il s’agit d’un échec, sauf si un contrôle permettant de désactiver ce comportement était fourni avant que vous n’atteigniez l’élément.
5. Test avec NVDA + Firefox : Activez NVDA (Insert+Espace pour le mode navigation), parcourez la page avec les flèches et Tab. Effectuez des interactions avec les formulaires et notez si le focus ou la position de lecture est déplacé de manière inattendue. Écoutez les annonces de changements de page. Si le lecteur d’écran annonce une nouvelle page ou si le curseur virtuel est réinitialisé sans votre action explicite, cela indique un changement de contexte.
6. Test avec VoiceOver + Safari (macOS/iOS) : Activez VoiceOver (Cmd+F5 sur Mac), naviguez avec VO+Flèche. Interagissez avec les contrôles et écoutez les annonces de page inattendues ou les réinitialisations du curseur. Sur iOS, balayez les éléments et notez tout changement soudain dans la structure de l’arbre d’accessibilité que vous n’avez pas initié.
7. Test avec JAWS + Chrome : Activez JAWS et naviguez avec Tab et les flèches. Soumettez des formulaires et interagissez avec des composants dynamiques. Vérifiez que le focus et la position du curseur virtuel restent prévisibles et sous votre contrôle en permanence.
8. Revue du code source JavaScript : Dans Chrome DevTools, utilisez l’onglet Sources ou la recherche (Ctrl+Shift+F) pour trouver des motifs comme window.location, location.href, history.pushState, setTimeout combiné avec des appels de navigation, et les attributs onchange. Évaluez si certains de ces éléments sont déclenchés par des minuteries ou des événements système plutôt que par des actions explicites de l’utilisateur.
9. Vérification des carrousels et curseurs à avance automatique : Identifiez tout carrousel, diaporama ou bannière rotative sur la page. Vérifiez s’ils avancent automatiquement. Si c’est le cas, vérifiez s’ils déclenchent également une navigation (par exemple, en renvoyant vers de nouvelles pages) lors de l’avance automatique. Les carrousels à avance automatique qui ne font que changer le contenu visible peuvent relever de 2.2.2, mais s’ils provoquent également une navigation, ils relèvent de 3.2.5.

Comment corriger

Redirection par meta refresh — Incorrect

<!-- This meta tag automatically redirects the user after 5 seconds.
     The user has no control over this navigation. -->
<head>
  <meta http-equiv='refresh' content='5; url=https://example.com/new-page'>
</head>
<body>
  <p>You will be redirected shortly...</p>
</body>

Redirection par meta refresh — Correct

<!-- Remove the automatic redirect entirely.
     Provide an explicit link that the user can activate on their own terms.
     This gives users full control over when navigation occurs. -->
<head>
  <!-- No meta refresh tag -->
</head>
<body>
  <p>This page has moved. Please visit the new location:</p>
  <a href='https://example.com/new-page'>Go to the updated page</a>
</body>

Élément select qui navigue automatiquement au changement — Incorrect

<!-- The onchange handler immediately navigates when the user selects a value.
     Keyboard users have no chance to review their selection before navigation. -->
<label for='category'>Choose a category:</label>
<select id='category' onchange='window.location.href = this.value'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>

Élément select qui navigue automatiquement au changement — Correct

<!-- The select element no longer triggers navigation on change.
     A clearly labeled button gives the user explicit control over when to proceed.
     This pattern works for all users, including keyboard and screen reader users. -->
<label for='category'>Choose a category:</label>
<select id='category'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>
<button type='button' onclick='navigateToCategory()'>Go to category</button>

<script>
function navigateToCategory() {
  var select = document.getElementById('category');
  if (select.value) {
    window.location.href = select.value;
  }
}
</script>

Carrousel à avance automatique qui déclenche une navigation — Incorrect

<!-- This carousel auto-advances every 3 seconds and each slide links to a new page.
     When the slide changes automatically, clicking anywhere on it navigates unexpectedly. -->
<div id='carousel'>
  <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale'></a>
</div>
<script>
var slides = ['/promo/summer', '/promo/winter', '/promo/spring'];
var current = 0;
setInterval(function() {
  current = (current + 1) % slides.length;
  document.querySelector('#carousel a').href = slides[current];
}, 3000);
</script>

Carrousel à avance automatique qui déclenche une navigation — Correct

<!-- The carousel no longer auto-advances.
     Navigation between slides and to destination pages is entirely user-controlled.
     Pause and next/previous controls satisfy both 2.2.2 and 3.2.5. -->
<div id='carousel' aria-roledescription='carousel' aria-label='Featured promotions'>
  <div role='group' aria-roledescription='slide' aria-label='1 of 3'>
    <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale — Shop now'></a>
  </div>
</div>
<div>
  <button type='button' aria-label='Previous slide' onclick='prevSlide()'>‹</button>
  <button type='button' aria-label='Next slide' onclick='nextSlide()'>›</button>
</div>

Erreurs courantes

• Utiliser onchange sur les éléments <select> pour déclencher immédiatement une navigation via window.location.href sans fournir de bouton de soumission séparé, forçant les utilisateurs au clavier à subir un changement de page immédiat avant de pouvoir confirmer leur sélection.
• Mettre en œuvre <meta http-equiv='refresh' content='30; url=...'> pour la gestion de l’expiration de session sans donner aux utilisateurs un mécanisme pour prolonger leur session ou désactiver la redirection automatique avant qu’elle ne se produise.
• Utiliser setTimeout ou setInterval pour appeler location.replace() ou history.pushState() pour des fonctionnalités de « commodité » comme la sauvegarde automatique avec mise à jour de l’URL, ce qui déplace de manière inattendue les utilisateurs vers de nouveaux états d’historique du navigateur.
• Ouvrir de nouvelles fenêtres ou onglets de navigateur à l’aide de window.open() déclenché par une minuterie ou un processus automatisé plutôt que par un geste utilisateur tel qu’un clic ou une pression de touche, ce que de nombreux navigateurs peuvent bloquer comme une fenêtre pop-up et qui constitue toujours un changement de contexte non sollicité.
• Soumettre automatiquement un formulaire de recherche ou de filtre à l’aide de form.submit() dans une fonction de debounce déclenchée par oninput sur un champ de texte — même avec un délai — sans fournir de bouton de soumission visible comme mécanisme de contrôle alternatif.
• Fournir un contrôle « désactiver l’avance automatique » qui n’apparaît qu’après la première navigation automatique déjà survenue, plutôt qu’avant. Le mécanisme de désactivation doit être disponible pour les utilisateurs avant que le premier changement de contexte ne se produise.
• Confondre les mises à jour de contenu avec les changements de contexte : les régions dynamiques (live regions) qui mettent à jour du texte sur place (par exemple, un bandeau de cotations boursières) ne sont pas des changements de contexte et sont acceptables, mais le remplacement automatique de toute la page visible ou la navigation vers une nouvelle URL est un changement de contexte et relève de ce critère.
• Supposer que fournir une boîte de dialogue d’avertissement avant une navigation automatique satisfait le critère lorsque la boîte de dialogue elle-même est déclenchée automatiquement et piège le focus clavier. L’utilisateur doit pouvoir désactiver le comportement, pas seulement en être averti.
• Utiliser des gestionnaires d’événements onblur ou onfocusout pour déclencher une validation de formulaire et une redirection automatique vers une page d’erreur ou une étape différente dans un formulaire multi-étapes, sans que l’utilisateur ait explicitement demandé à continuer.
• Déployer un routage d’application monopage (SPA) qui met à jour history.pushState en fonction de la profondeur de défilement ou du temps passé sur une section — un schéma parfois utilisé pour l’analytique — ce qui constitue un changement de contexte non initié et peut perturber les utilisateurs de lecteurs d’écran dont le tampon virtuel est lié à l’état de l’URL.

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 alignées sur les WCAG 2.2 pour un large éventail d’entités opérant en Turquie. La circulaire couvre les institutions et agences publiques, les plateformes de e-commerce, les banques et institutions financières, les hôpitaux et prestataires de soins de santé, les entreprises de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE).

La circulaire impose la conformité au niveau AA des WCAG 2.2 comme norme de base pour les entités concernées. WCAG 3.2.5 Changement sur demande est un critère de niveau AAA et n’est donc pas directement requis au regard du seuil légal minimal de la circulaire. Cependant, cela ne signifie pas qu’il doit être considéré comme non pertinent dans le contexte turc.

Plusieurs catégories d’entités couvertes ont de fortes raisons pratiques de viser la conformité AAA à 3.2.5. Les plateformes de e-commerce et les agences de voyage ayant de larges bases d’utilisateurs mettent souvent en œuvre des filtres dynamiques, une navigation par suggestion automatique et des carrousels promotionnels — précisément les schémas les plus susceptibles de violer ce critère. Les banques et prestataires de services financiers, qui gèrent des transactions sensibles où une navigation inattendue peut provoquer des erreurs ou des problèmes de sécurité, bénéficient fortement du fait de garantir que tous les changements de contexte sont explicitement contrôlés par l’utilisateur. Les portails de santé, où les utilisateurs peuvent être en situation de vulnérabilité et avoir besoin d’interfaces prévisibles et apaisantes, représentent une autre catégorie où dépasser le niveau AA avec des critères AAA comme 3.2.5 démontre à la fois un engagement éthique et une sécurité pratique pour les utilisateurs.

Les institutions publiques soumises à des obligations d’audit et de reporting au titre de la circulaire devraient documenter leur niveau de conformité. Bien que le niveau AAA ne soit pas légalement imposé, l’atteindre — et le documenter — fournit une preuve défendable d’un engagement d’accessibilité de premier plan. Pour les entités qui servent principalement ou de manière significative des utilisateurs en situation de handicap, comme l’autorité de sécurité sociale (SGK) ou les services de soutien au handicap, viser la conformité de niveau AAA est particulièrement aligné avec l’esprit de la réglementation.

Les organisations qui respectent volontairement WCAG 3.2.5 se positionnent également favorablement dans le contexte de l’alignement sur l’accessibilité de l’Union européenne, car les relations de commerce numérique de la Turquie avec les États membres de l’UE impliquent de plus en plus l’accessibilité comme critère de passation de marchés et de partenariat. L’Acte européen sur l’accessibilité (EAA), entré en vigueur en juin 2025, s’applique aux produits et services proposés sur les marchés de l’UE — y compris ceux fournis par des entreprises turques aux utilisateurs européens — et encourage fortement des schémas d’interaction contrôlés par l’utilisateur, conformes à 3.2.5.

Concrètement, les équipes de développement turques qui implémentent le SDK de surcouche d’Accsible devraient veiller à ce que tout composant injecté dynamiquement, panneau de préférences ou contrôle d’assistance n’introduise pas lui-même de changements de contexte non initiés. La barre d’outils et le panneau de paramètres du SDK doivent s’ouvrir et se fermer uniquement en réponse à des actions explicites de l’utilisateur, et toute navigation ou mise à jour de contenu déclenchée via la surcouche doit être initiée par l’utilisateur. Cela garantit que la solution d’accessibilité elle-même ne crée pas les obstacles mêmes qu’elle est censée supprimer.