Accéder au contenu principalAccéder à la navigationAccéder au pied de page
Page d'accueil IncluddyPage d'accueil Includdy
  • FAQ
  • Blog
  • Glossaire
  • Contact
Includdy

Rendons le web accessible à tous

Produit

  • Scan automatique
  • Correction guidée
  • Collaboration

Ressources

  • FAQ
  • Blog
  • Glossaire
  • Plan du site

Légal

  • CGU
  • CGV
  • Mentions légales
  • Politique de confidentialité

© 2026 Includdy. Tous droits réservés.

  1. Accueil
  2. Glossaire
  3. Changement de contexte

Changement de contexte


En accessibilité web, un changement de contexte désigne un bouleversement majeur de la page : ouverture d'une nouvelle fenêtre, déplacement du focus, redirection vers une autre page ou réorganisation significative du contenu. Les WCAG imposent que ces changements ne surviennent jamais automatiquement, sauf si l'utilisateur les a déclenchés ou en a été averti au préalable.


Vous appuyez sur Tab dans un formulaire, et le focus saute vers un champ imprévu. Vous sélectionnez une option dans un menu déroulant, et la page se recharge. Vous n'avez rien déclenché. Pour un utilisateur de lecteur d'écran, qui ne perçoit qu'une fraction de la page à la fois, ce type de surprise fait perdre pied.

#Ce que les WCAG appellent « changement de contexte »

Le glossaire des WCAG le définit comme un changement majeur qui, sans que l'utilisateur en soit conscient, risque de le désorienter. Quatre situations en relèvent :

  • ouverture d'une nouvelle fenêtre ou d'un nouvel onglet ;
  • déplacement du focus vers un autre composant ;
  • navigation vers une autre page ;
  • réorganisation significative du contenu.

À ne pas confondre avec un simple changement de contenu. Afficher un message d'erreur sous un champ, mettre à jour un compteur en temps réel : tant que le focus reste en place et que la structure de la page ne bouge pas, ce n'est pas un changement de contexte.

#Le piège classique : onchange sur un <select>

L'erreur la plus répandue est le menu déroulant qui déclenche une action dès qu'on choisit une option :

<!-- ❌ Changement de contexte automatique -->
<select onchange="window.location.href = this.value">
  <option value="/fr">Français</option>
  <option value="/en">English</option>
</select>
 
<!-- ✅ L'utilisateur déclenche l'action -->
<select id="lang">
  <option value="/fr">Français</option>
  <option value="/en">English</option>
</select>
<button type="button" onclick="window.location.href = document.getElementById('lang').value">
  Changer la langue
</button>

Un utilisateur au clavier parcourt le <select> avec les flèches. Avec onchange, chaque déplacement déclenche la redirection. L'utilisateur n'a pas le temps de lire les options.

Deux critères de succès encadrent ces situations au niveau A (le minimum requis par la plupart des législations) :

  • 3.2.1 Au focus : recevoir le focus ne doit jamais déclencher un changement de contexte.
  • 3.2.2 À la saisie : modifier la valeur d'un composant ne doit pas déclencher un changement de contexte, sauf avertissement préalable.

#Si le changement automatique est inévitable

Quand votre interface doit réagir à un changement de valeur, avertissez l'utilisateur avant le composant. Un texte visible, lié au champ par aria-describedby, suffit :

<p id="avertissement">La page sera mise à jour automatiquement.</p>
<select aria-describedby="avertissement">…</select>

La solution la plus fiable reste le bouton explicite. Pas d'ambiguïté, pas de mauvaise surprise.

#En résumé

Un changement de contexte, ce n'est pas un message d'erreur qui apparaît. C'est une fenêtre qui s'ouvre sans prévenir. Une redirection. Un focus qui saute ailleurs. Les WCAG exigent que l'utilisateur en soit à l'origine ou qu'il ait été prévenu. Le réflexe le plus sûr : toujours placer un bouton de validation avant une action qui modifie la page.

Retour au glossaire

Partagez cet article

Partagez cet article

Pour aller plus loin

Navigation

En accessibilité web, la navigation regroupe tous les mécanismes qui permettent de se déplacer dans un site : menu principal, moteur de recherche, plan du site, fil d'Ariane. Les WCAG exigent au moins deux de ces systèmes sur chaque ensemble de pages, pour couvrir les différentes façons dont les utilisateurs parcourent un site.

Composant d'interface

Un composant d'interface est un élément de page avec lequel l'utilisateur interagit : bouton, lien, champ de saisie, menu ou système d'onglets. Quand il s'agit d'un élément HTML natif, le navigateur gère l'accessibilité. Quand il est construit en JavaScript, c'est au développeur de reproduire ce comportement avec WAI-ARIA et la gestion clavier.

Formulaire

Un formulaire est un ensemble de champs et de boutons qui permettent à un utilisateur de transmettre des données sur un site web. Pour être accessible, chaque champ doit porter une étiquette reliée dans le code, les contrôles liés doivent être regroupés dans un fieldset, et les erreurs signalées en texte. Le RGAA y consacre 13 critères, sa thématique la plus fournie.