Pour chaque script qui initie un changement de contexte, l’utilisateur est-il averti ou en a-t-il le contrôle ?
Un utilisateur navigue sur votre site avec un lecteur d’écran. Il sélectionne une option dans un menu déroulant. La page se recharge instantanément. Zéro avertissement. Son lecteur d’écran reprend depuis le début de la page, et l’utilisateur a perdu sa position, son fil de lecture, son contexte de navigation.
Le critère 7.4 pose une règle claire : tout script qui déclenche un changement de contexte doit soit prévenir l’utilisateur avant de s’exécuter, soit être déclenché explicitement par un bouton ou un lien. L’utilisateur doit pouvoir anticiper ce qui va se passer, ou en être directement à l’initiative.
Un « changement de contexte » au sens RGAA va plus loin qu’un simple rechargement de page. Cela recouvre : l’ouverture d’une nouvelle page, une mise à jour majeure du contenu via AJAX, le déplacement automatique du focus, le lancement automatique d’un lecteur vidéo lors d’une sélection. En revanche, afficher un champ conditionnel ou mettre à jour un compteur de caractères sans déplacer le focus n’est pas un changement de contexte.
La correction la plus directe : remplacez l’événement automatique par un <button type="submit">. Cinq lignes de HTML suffisent.
Un test pour détecter les changements de contexte inattendus
Avertissement avant changement de contexte déclenché par script
- Identifiez tous les scripts qui déclenchent un changement de contexte dans la page. Cherchez notamment :
- Un
<select>avec un gestionnaireonchangequi navigue ou recharge la page - Une mise à jour AJAX d’une zone essentielle du contenu
- Un lecteur vidéo ou audio qui se lance automatiquement lors d’une sélection de playlist
- Un déplacement de focus qui repositionne l’utilisateur dans la page
- Un
- Pour chaque changement de contexte détecté, vérifiez qu’au moins une condition est remplie :
- L’utilisateur est informé par un texte visible du changement à venir, avant qu’il se produise
- Le changement est déclenché par un bouton explicite (
<button>,<input type="submit">,<input type="button">,<input type="image">) - Le changement est déclenché par un lien explicite (
<a href="...">)
- Si aucune condition n’est remplie, le test échoue.
Exemples
❌ Non conforme : Menu déroulant qui navigue automatiquement au changement de sélection
<form>
<label for="categorie">Filtrer par catégorie</label>
<select id="categorie" onchange="window.location.href = this.value;">
<option value="/actualites">Actualités</option>
<option value="/evenements">Événements</option>
<option value="/ressources">Ressources</option>
</select>
</form>La navigation se déclenche dès que la sélection change, sans aucune action supplémentaire de l’utilisateur. Un visiteur qui explore les options au clavier avec les touches fléchées est redirigé vers une nouvelle page à chaque flèche. C’est l’échec F37 des WCAG. Particulièrement désastreux pour les utilisateurs de lecteurs d’écran, qui perdent leur position à chaque déplacement dans la liste.
✅ Conforme : Menu déroulant avec bouton de validation explicite
<form action="/filtrer" method="get">
<label for="categorie">Filtrer par catégorie</label>
<select id="categorie" name="categorie">
<option value="actualites">Actualités</option>
<option value="evenements">Événements</option>
<option value="ressources">Ressources</option>
</select>
<button type="submit">Appliquer le filtre</button>
</form>L’utilisateur choisit son option, puis décide lui-même de soumettre via le bouton. Le <button type="submit"> est l’initiateur explicite du changement de contexte. Navigable au clavier sans surprise, compatible avec tous les lecteurs d’écran.
✅ Conforme : Mise à jour AJAX avec avertissement textuel préalable
<p id="info-tri">
La liste des résultats se met à jour automatiquement après votre sélection.
</p>
<select
id="tri"
aria-describedby="info-tri"
onchange="mettreAJourResultats(this.value)"
>
<option value="date">Par date</option>
<option value="pertinence">Par pertinence</option>
</select>L’avertissement textuel visible, placé avant le <select>, informe l’utilisateur du comportement dynamique avant qu’il interagisse. C’est la deuxième voie de conformité au critère 7.4 : prévenir avant le déclenchement. L’aria-describedby renforce le lien sémantique pour les technologies d’assistance.
Astuces et pièges
⚠️ Le onchange sur <select> est l’échec le plus fréquent en audit
Déclencher une navigation ou un rechargement via onchange sur un <select> est le cas le plus courant de non-conformité au critère 7.4. Techniquement simple à corriger (ajouter un bouton de soumission), c’est pourtant souvent laissé tel quel au nom du « confort utilisateur ». Ce confort est une illusion : les utilisateurs de lecteurs d’écran se retrouvent redirigés vers une nouvelle page à chaque déplacement dans la liste au clavier.
⚠️ Formulaire OTP à soumission automatique : cas limite accepté
Un formulaire de code OTP à 6 chiffres qui se soumet automatiquement après le dernier caractère saisi fait débat. L’interprétation RGAA la plus répandue est que le contexte de saisie (l’utilisateur sait qu’il saisit un code de confirmation) rend l’action suffisamment explicite. Un bouton de soumission reste la solution la plus sûre et la moins contestable lors d’un audit.
💡 Un bouton explicite règle la quasi-totalité des cas
La voie de conformité la plus directe : tout changement de contexte doit être déclenché par un <button> ou un <input type="submit">. Pas d’avertissement textuel à rédiger, pas d’ARIA supplémentaire. Le bouton lui-même atteste que l’utilisateur a choisi d’agir.
⚠️ La manipulation de focus compte aussi comme changement de contexte
Si un script déplace le focus vers une autre zone de la page sans que l’utilisateur l’ait demandé, c’est un changement de contexte au sens du critère 7.4. Les déplacements de focus automatiques après soumission de formulaire ou après un délai minuté doivent être prévus et communiqués à l’utilisateur.
⚠️ Le rechargement automatique sans interaction relève du critère 13.1
Un <meta http-equiv="refresh"> ou une redirection JavaScript qui se déclenche sans aucune interaction utilisateur relève du critère 13.1 (consultation), pas du 7.4. Le critère 7.4 s’applique uniquement aux changements de contexte déclenchés en réponse à une interaction de l’utilisateur avec un script.
Questions fréquentes
Comment distinguer un changement dynamique d'un changement de contexte selon le RGAA ?
Non. Un changement de contexte est un changement majeur susceptible de désorienter l’utilisateur : ouverture d’une nouvelle page, rechargement, déplacement de focus, mise à jour d’une zone essentielle via AJAX, lancement automatique d’un média. Afficher un champ conditionnel, mettre à jour un compteur de caractères ou rafraîchir une liste de suggestions sans déplacer le focus ne constitue pas un changement de contexte au sens du critère 7.4.
Comment traiter un <button type="button"> avec onclick qui provoque une navigation en RGAA ?
Oui. Ce qui compte, c’est que l’utilisateur actionne délibérément un élément interactif dont la sémantique est celle d’un bouton. Un <button type="button"> avec onclick qui déclenche une navigation est conforme. Ce n’est pas comparable à un onchange automatique sur un <select>, où le changement de contexte se produit sans action volontaire de soumission.
Comment auditer concrètement le critère 7.4 sur les changements de contexte RGAA ?
Naviguez dans la page uniquement au clavier. Parcourez tous les éléments de formulaire avec Tab, et utilisez les touches fléchées dans les listes déroulantes. Si un changement de contexte se produit sans que vous ayez appuyé sur Entrée ou activé un bouton ou un lien, c’est probablement un échec. Inspectez ensuite le code source pour identifier l’événement déclencheur (onchange, onfocus, oninput, etc.).
Quand aria-describedby doit-il signaler un changement de contexte selon le RGAA ?
Non. Le RGAA exige que l’utilisateur soit « averti par un texte » avant le déclenchement du changement. Ce texte doit être accessible à tous, pas uniquement via les technologies d’assistance. Un aria-describedby seul, pointant vers un contenu masqué visuellement, ne suffit pas. Le texte doit être visible dans le flux de la page, placé avant l’élément déclencheur.
Pourquoi un lien ouvrant une nouvelle fenêtre relève-t-il du critère RGAA 7.4 ?
Non. L’ouverture d’une nouvelle fenêtre via un lien est le comportement standard d’un lien : le critère 7.4 ne s’applique pas. En revanche, si un script force l’ouverture d’une nouvelle fenêtre en dehors de tout clic sur un lien ou un bouton explicite, le critère 7.4 s’applique. La mention de l’ouverture dans une nouvelle fenêtre dans l’intitulé du lien est, elle, traitée par le critère 6.1.