WCAG 2.2.4 : Interruptions

Ce que signifie cette règle

WCAG 2.2.4 : Interruptions est un critère de succès de niveau AAA relevant de la Règle 2.2 (Temps suffisant). Il stipule : « Les interruptions peuvent être reportées ou supprimées par l’utilisateur, sauf les interruptions impliquant une situation d’urgence. » En pratique, cela signifie que tout contenu, alerte, notification, boîte de dialogue ou mise à jour qui apparaît sans être directement déclenché par l’utilisateur doit offrir à cet utilisateur un mécanisme pour le différer ou le désactiver — sauf si l’interruption communique une véritable urgence, comme une alarme incendie, une alerte médicale mettant la vie en danger ou une défaillance critique du système.

Une interruption, au sens des WCAG, est tout événement qui se produit indépendamment de l’action en cours de l’utilisateur et détourne son attention de ce qu’il est en train de faire. Cela inclut, sans s’y limiter : les notifications « toast », les alertes push, les widgets de chat qui s’ouvrent automatiquement, les bandeaux d’état qui se rafraîchissent ou changent, les médias en lecture automatique, les annonces de régions dynamiques injectées par JavaScript, les boîtes de dialogue modales déclenchées par un minuteur, et les bandeaux de consentement aux cookies qui apparaissent en cours de session. Le critère n’interdit pas ces modèles en soi ; il exige que les utilisateurs aient la maîtrise de ces interruptions.

Une page réussit 2.2.4 lorsque chaque interruption non urgente dispose d’au moins l’un des éléments suivants : un paramètre accessible à l’utilisateur qui désactive l’interruption avant qu’elle ne se produise, un mécanisme au sein même de l’interruption pour la rejeter ou la reporter, ou une préférence globale au niveau du site qui supprime entièrement ce type d’interruptions. Une page échoue lorsque des interruptions apparaissent automatiquement, ne proposent aucun mécanisme de rejet ou de report, et ne sont pas liées à une urgence. Par exemple, une bulle de chat en direct qui se déploie automatiquement après 10 secondes sans bouton de fermeture, ou un bandeau de notification qui fait défiler des messages marketing et ne peut pas être arrêté, seraient tous deux en échec.

La seule exception explicitement définie concerne les urgences. Si un contenu doit interrompre l’utilisateur pour communiquer un danger pour la santé, la sécurité ou la vie — par exemple, un portail hospitalier qui envoie une alerte critique de médication — cette interruption peut outrepasser les préférences de l’utilisateur. Cette exception est volontairement étroite ; les messages marketing de routine, les avertissements d’expiration de session avec un délai confortable restant, et les mises à jour de statut de faible priorité ne constituent pas des urgences.

Parce que WCAG 2.2.4 est de niveau AAA, il n’est pas requis pour les déclarations de conformité de base, mais il constitue une norme significative pour les organisations engagées dans une inclusion complète. Il s’applique à tout contenu web : applications web de bureau et mobiles, applications monopage utilisant des notifications pilotées par JavaScript, et applications web progressives exploitant l’API Web Notifications.

Pourquoi c’est important

Les interruptions inattendues sur une page web ne sont pas seulement agaçantes — pour de nombreux utilisateurs, elles représentent un obstacle sérieux à l’accomplissement de tâches et, dans certains cas, un risque direct pour la santé.

Les utilisateurs ayant des handicaps cognitifs ou liés à l’attention — y compris le TDAH, les traumatismes crâniens, les troubles du spectre autistique et la démence — s’appuient fortement sur un environnement stable et prévisible pour maintenir leur concentration. Une notification soudaine ou une alerte animée peut briser complètement leur concentration, les amenant à perdre le fil d’un processus en plusieurs étapes, comme remplir une demande de prestations, consulter un dossier médical ou compléter une déclaration d’impôts. Se réorienter après une interruption peut prendre beaucoup plus de temps pour ces utilisateurs que pour des utilisateurs neurotypiques, et dans certains cas, ils peuvent ne pas être capables de retrouver leur place du tout.

Les utilisateurs de lecteurs d’écran sont particulièrement affectés par les interruptions dynamiques. Lorsqu’une région dynamique ou une alerte ARIA est injectée dans le DOM, des lecteurs d’écran comme NVDA, JAWS et VoiceOver sont conçus pour l’annoncer immédiatement, interrompant ce que la technologie d’assistance était en train de lire. Si un utilisateur écoute un long paragraphe d’instructions importantes et qu’un toast marketing se déclenche en plein milieu d’une phrase, le lecteur d’écran abandonne le paragraphe et annonce la notification. L’utilisateur doit alors revenir en arrière, retrouver sa place et relire — un processus bien plus lourd qu’il n’y paraît pour quelqu’un qui navigue uniquement au clavier et à l’audio.

Les utilisateurs souffrant de troubles anxieux et de SSPT peuvent éprouver des réactions physiques de stress — accélération du rythme cardiaque, perte de concentration ou panique — déclenchées par des changements visuels ou sonores soudains et inattendus. L’imprévisibilité d’un environnement d’interruptions non contrôlées peut rendre certains sites pratiquement inutilisables pour ces populations.

Les utilisateurs atteints d’épilepsie ou de troubles vestibulaires peuvent être lésés par certains types d’interruptions, en particulier celles impliquant des clignotements ou des mouvements rapides. Bien que la Règle 2.3 traite spécifiquement des risques de crises, les bandeaux de notification animés et les notifications vidéo en lecture automatique qui apparaissent de manière inattendue recoupent les deux critères.

Considérons un scénario concret : une personne ayant un TDAH utilise un portail bancaire en ligne pour transférer de l’argent entre comptes. Elle vérifie soigneusement le montant du transfert et le numéro de compte destinataire. Une notification d’offre promotionnelle glisse depuis le coin inférieur droit, déclenchant une annonce du lecteur d’écran et une animation d’entrée. L’utilisateur perd sa place, ne parvient pas à trouver le bouton de rejet parce que l’animation a détourné le focus, et soumet par erreur le mauvais montant. Ce n’est pas un cas limite hypothétique — c’est un résultat prévisible lorsqu’on ignore ce critère.

Au-delà du handicap, les interruptions non contrôlées nuisent aussi à l’ergonomie pour tous les utilisateurs, augmentent les taux de rebond (les utilisateurs quittent simplement les sites qui les bombardent) et peuvent réduire la conversion sur les actions mêmes que les interruptions étaient censées promouvoir. Du point de vue du référencement, des taux de rebond élevés et des durées de session faibles sont corrélés à des signaux de classement moins favorables, ce qui signifie qu’accessibilité et performance commerciale sont alignées ici.

Règles axe-core associées

WCAG 2.2.4 nécessite des tests manuels. Les outils automatisés, y compris axe-core, ne peuvent pas détecter de manière fiable si un site produit des interruptions incontrôlables, car cela exigerait que l’outil : observe tout le contenu dynamique injecté pendant une session utilisateur, évalue si chaque injection a été initiée par l’utilisateur, vérifie si un mécanisme de rejet ou de report existe et est accessible, et détermine si le contenu relève d’une urgence. Ce sont des jugements contextuels et comportementaux qui dépassent le cadre de l’analyse statique du DOM.

• Tests manuels requis — Contrôle des interruptions : Les testeurs doivent interagir manuellement avec la page sur une certaine durée pour observer si des mises à jour de contenu, notifications, boîtes de dialogue ou médias se déclenchent sans initiation de l’utilisateur. Pour chaque interruption observée, le testeur doit vérifier qu’il existe un mécanisme accessible pour la reporter ou la supprimer, que ce mécanisme lui-même est accessible au clavier et annoncé par le lecteur d’écran, et que l’interruption ne se reproduit pas après son rejet sans que l’utilisateur ne la réactive.
• Tests manuels requis — Évaluation des régions dynamiques : Les pages utilisant aria-live, role='alert' ou role='status' doivent être examinées manuellement pour déterminer si les annonces sont déclenchées par des actions de l’utilisateur (acceptable) ou par des événements basés sur le temps ou des push serveur (potentiellement non conformes). Un outil automatisé peut signaler la présence de régions dynamiques mais ne peut pas déterminer si elles produisent des interruptions inattendues lors d’une session utilisateur réelle.
• Tests manuels requis — Utilisation de l’API de notification : Les applications web qui demandent l’autorisation d’envoyer des notifications push au niveau du navigateur doivent offrir un mécanisme clair permettant à l’utilisateur de gérer ou de supprimer ces notifications depuis l’application web elle-même, sans se reposer uniquement sur les contrôles du navigateur. Cela nécessite une inspection manuelle du flux d’autorisation de notification et de la disponibilité des préférences de notification dans l’application.

Comment tester

1. Exécuter un scan automatisé comme base de référence. Ouvrez la page dans Chrome ou Firefox et lancez axe DevTools ou Lighthouse. Bien qu’aucun de ces outils ne dispose d’une règle dédiée à 2.2.4, le scan automatisé signalera des problèmes connexes : rôles manquants sur le contenu dynamique, régions dynamiques mal configurées et problèmes de gestion du focus dans les boîtes de dialogue. Notez toute région aria-live ou tout élément role='alert' signalé, car ils nécessiteront un suivi manuel.
2. Observer la page passivement pendant au moins deux à trois minutes. Sans cliquer sur quoi que ce soit, regardez et écoutez tout contenu qui change, apparaît ou s’annonce. Utilisez un lecteur d’écran en arrière-plan (NVDA avec Firefox, ou VoiceOver avec Safari sur macOS) et écoutez toute annonce qui n’a pas été déclenchée par votre action. Notez chaque interruption, son moment et son contenu.
3. Tester les parcours interactifs qui déclenchent couramment des notifications. Connectez-vous à l’application si nécessaire, accédez à un formulaire ou à un processus en plusieurs étapes, et commencez à le remplir lentement. Notez toute interruption qui se produit : avertissements d’expiration de session, invitations au chat, bandeaux promotionnels, mises à jour de progression ou sollicitations d’abonnement. Pour chacune, essayez de la rejeter ou de la reporter en utilisant uniquement le clavier (Tab, Échap, Entrée, Espace). Vérifiez que le focus revient à un emplacement logique après le rejet.
4. Tester avec NVDA et Firefox. Activez NVDA, ouvrez Firefox et naviguez sur la page. Écoutez attentivement toute sortie vocale qui interrompt votre lecture en cours. Si une notification automatisée se déclenche, essayez de la rejeter à l’aide des commandes clavier et vérifiez que NVDA annonce la confirmation du rejet ou que le focus revient correctement.
5. Tester avec JAWS et Chrome. Répétez les tests d’observation passive et de parcours interactifs en utilisant JAWS avec Chrome. JAWS et NVDA gèrent différemment les régions dynamiques, il est donc important de tester avec les deux pour s’assurer que les interruptions sont annoncées de manière cohérente et que les mécanismes de rejet fonctionnent dans les deux lecteurs d’écran.
6. Tester avec VoiceOver et Safari sur iOS. Sur un appareil mobile ou un simulateur, utilisez VoiceOver avec Safari pour naviguer sur la page. Balayez le contenu et observez si des interruptions se produisent. Testez le mécanisme de rejet à l’aide des gestes tactiles (double-tape pour activer) et vérifiez que le focus revient à un emplacement pertinent.
7. Vérifier l’existence d’un paramètre de préférence de notification. Recherchez un profil utilisateur, un panneau de paramètres ou une section de préférences d’accessibilité dans l’application. Vérifiez qu’il existe un contrôle permettant de supprimer ou de configurer globalement les notifications, et testez que l’activation de ce paramètre empêche effectivement les interruptions de se produire lors d’une session ultérieure.
8. Examiner le code JavaScript ou l’activité réseau. Dans les DevTools du navigateur, observez les onglets Network et Console pendant la session. Recherchez des connexions WebSocket, des intervalles de polling ou des appels setTimeout/setInterval qui injectent du contenu dans le DOM. Chacun de ces éléments est une source potentielle d’interruptions et doit être analysé pour s’assurer qu’un contrôle utilisateur est mis en œuvre.

Comment corriger

Widget de chat s’ouvrant automatiquement — Incorrect

<!-- Chat widget opens automatically after 10 seconds with no close button -->
<div id='chat-widget' role='dialog' aria-label='Live chat'>
  <p>Hi! Can we help you today?</p>
  <button>Start chat</button>
</div>

<script>
  setTimeout(function() {
    document.getElementById('chat-widget').style.display = 'block';
  }, 10000);
</script>

Widget de chat s’ouvrant automatiquement — Correct

<!-- Chat widget includes a dismiss button and respects a user preference -->
<div id='chat-widget' role='dialog' aria-label='Live chat' aria-modal='true'>
  <p>Hi! Can we help you today?</p>
  <button id='chat-start'>Start chat</button>
  <!-- Dismiss button allows user to postpone the interruption -->
  <button id='chat-dismiss' aria-label='Dismiss chat offer'>No thanks</button>
</div>

<script>
  // Check whether the user has previously dismissed the chat offer
  if (!sessionStorage.getItem('chat-dismissed')) {
    setTimeout(function() {
      var widget = document.getElementById('chat-widget');
      widget.removeAttribute('hidden');
      // Move focus into the dialog so screen reader users are aware of it
      document.getElementById('chat-dismiss').focus();
    }, 10000);
  }

  document.getElementById('chat-dismiss').addEventListener('click', function() {
    // Suppress for the remainder of the session
    sessionStorage.setItem('chat-dismissed', 'true');
    var widget = document.getElementById('chat-widget');
    widget.setAttribute('hidden', '');
    // Return focus to the element the user was on before the interruption
    document.getElementById('main-content').focus();
  });
</script>

Notification marketing « toast » incontrôlable — Incorrect

<!-- Toast fires every 30 seconds, no way to stop it -->
<div role='alert' id='promo-toast'>
  <p>Use code SAVE20 for 20% off your next order!</p>
</div>

<script>
  setInterval(function() {
    document.getElementById('promo-toast').style.display = 'block';
    setTimeout(function() {
      document.getElementById('promo-toast').style.display = 'none';
    }, 5000);
  }, 30000);
</script>

Notification marketing « toast » incontrôlable — Correct

<!-- Toast fires once, includes a dismiss control, and respects a preference -->
<div role='status' id='promo-toast' hidden>
  <p>Use code SAVE20 for 20% off your next order!</p>
  <!-- Dismiss button suppresses future promos in this session -->
  <button id='promo-dismiss' aria-label='Dismiss promotion'>&times;</button>
</div>

<script>
  // Only show once, and only if the user has not opted out
  if (!localStorage.getItem('promos-suppressed')) {
    setTimeout(function() {
      document.getElementById('promo-toast').removeAttribute('hidden');
    }, 30000);
  }

  document.getElementById('promo-dismiss').addEventListener('click', function() {
    // Suppress all future promotional interruptions permanently
    localStorage.setItem('promos-suppressed', 'true');
    document.getElementById('promo-toast').setAttribute('hidden', '');
  });
</script>

Fenêtre modale d’expiration de session sans contrôle utilisateur — Incorrect

<!-- Modal fires automatically, traps focus with no postpone option -->
<div id='timeout-modal' role='dialog' aria-label='Session expiring'>
  <p>Your session will expire in 60 seconds.</p>
  <button id='logout-now'>Log out</button>
</div>

Fenêtre modale d’expiration de session sans contrôle utilisateur — Correct

<!-- Modal provides both a continue option and a postpone option,
     and announces itself clearly to screen readers -->
<div id='timeout-modal' role='alertdialog'
     aria-labelledby='timeout-heading'
     aria-describedby='timeout-description'
     aria-modal='true'>
  <h2 id='timeout-heading'>Session Expiring Soon</h2>
  <p id='timeout-description'>
    Your session will expire in <span id='countdown'>5 minutes</span>.
    Would you like to continue, or shall we log you out now?
  </p>
  <button id='continue-session'>Continue session</button>
  <button id='logout-now'>Log out now</button>
  <!-- Postpone option gives the user meaningful control -->
  <button id='remind-later'>Remind me in 5 more minutes</button>
</div>

Erreurs courantes

• Utiliser role='alert' pour des messages promotionnels ou de faible priorité. Le rôle alert signale l’urgence aux lecteurs d’écran et provoque une interruption immédiate de la lecture. Les messages marketing, conseils et annonces de fonctionnalités devraient utiliser role='status' ou aria-live='polite' à la place, ce qui annonce le contenu seulement après que le lecteur d’écran a terminé sa sortie en cours.
• Fournir un bouton de fermeture visible uniquement au survol ou au focus, le rendant pratiquement inaccessible. Si le mécanisme de rejet exige que l’utilisateur survole avec la souris pour le révéler, les utilisateurs uniquement au clavier et les utilisateurs de lecteurs d’écran ne peuvent ni le voir ni l’atteindre. Le bouton de rejet doit toujours être visible, ou au minimum toujours atteignable via l’ordre de tabulation du clavier.
• Renvoyer le focus vers document.body après avoir rejeté une notification. Lorsqu’une notification ou une boîte de dialogue est rejetée, le focus doit revenir à un élément significatif et contextuellement approprié — généralement l’élément avec lequel l’utilisateur interagissait avant l’apparition de l’interruption. Déposer le focus sur body oblige les utilisateurs de lecteurs d’écran à renaviguer toute la page.
• Déclencher plusieurs régions aria-live simultanément. Lorsque plusieurs régions dynamiques se mettent à jour en même temps, les lecteurs d’écran mettent en file d’attente ou abandonnent les annonces de manière imprévisible. Chaque interruption doit être gérée avec soin afin qu’une seule région dynamique se déclenche à la fois, et que les mises à jour soient regroupées autant que possible.
• Considérer que la boîte de dialogue d’autorisation de notification native du navigateur constitue un contrôle utilisateur suffisant. La boîte de dialogue d’autorisation du navigateur pour l’API Web Notifications fonctionne au niveau du système d’exploitation, et non au niveau de l’application. WCAG 2.2.4 exige que les utilisateurs puissent gérer les notifications depuis l’application web elle-même, et pas seulement en bloquant le site au niveau du navigateur.
• Réinitialiser une notification rejetée à chaque chargement de page. Si un utilisateur rejette une notification et qu’elle réapparaît la prochaine fois qu’il navigue vers la même page ou une autre page du site, l’action de rejet était dénuée de sens. Les préférences devraient persister au moins pour la session en utilisant sessionStorage, ou de manière permanente en utilisant localStorage ou une préférence côté serveur.
• Utiliser setInterval pour faire défiler des bandeaux ou conseils rotatifs sans contrôle de pause. Un contenu rotatif qui se rafraîchit sur un minuteur est une interruption. Si le contenu change pendant qu’un utilisateur de lecteur d’écran est en train de le lire, l’annonce recommencera. Ces carrousels et bandeaux rotatifs nécessitent un contrôle lecture/pause et ne doivent pas boucler indéfiniment sans le consentement de l’utilisateur.
• Injecter une notification dans le DOM à un emplacement provoquant des sauts de défilement inattendus. Si un bandeau de notification est injecté en haut de la page et que la page se décale vers le bas, les utilisateurs perdent leur position de lecture visuelle. Les notifications devraient être injectées de manière à ne pas affecter la mise en page du contenu que l’utilisateur est en train de consulter, généralement en utilisant un positionnement fixe ou absolu.
• Supposer qu’un court minuteur d’auto-fermeture satisfait le critère. Un toast qui disparaît après cinq secondes ne donne pas aux utilisateurs un contrôle significatif — beaucoup ne peuvent pas lire, traiter ou répondre à un contenu aussi rapidement, en particulier les personnes ayant des handicaps cognitifs ou utilisant des lecteurs d’écran. Fournir uniquement un minuteur d’auto-fermeture sans bouton de rejet contrôlé par l’utilisateur n’est pas conforme.
• Ne pas tester le comportement des interruptions lorsque le système d’exploitation ou le navigateur de l’utilisateur a activé des préférences de réduction de mouvement ou de notifications. Certains utilisateurs définissent des préférences au niveau du système d’exploitation pour réduire les mouvements ou supprimer les notifications. Ces signaux devraient être respectés par l’application, et les développeurs devraient tester avec la requête média prefers-reduced-motion: reduce active pour s’assurer que les interruptions animées sont correctement supprimées.

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 un cadre contraignant d’accessibilité web pour un large éventail d’organisations opérant en Turquie. La circulaire adopte WCAG 2.2 comme norme de référence technique et impose la conformité aux entités couvertes. Les types d’entités explicitement couverts par la circulaire incluent les institutions et agences publiques, les plateformes de commerce électronique, les banques et prestataires de services financiers, les hôpitaux et organisations de services de santé, les entreprises de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage agréées, les entreprises de transport privé et les écoles privées opérant sous autorisation du ministère de l’Éducation nationale (MoNE).

WCAG 2.2.4 : Interruptions est un critère de niveau AAA, ce qui signifie qu’il ne fait pas partie des exigences de conformité de base prévues par la Circulaire présidentielle 2025/10 pour la plupart des entités couvertes. Les organisations qui atteignent et déclarent une conformité de niveau A et AA sont considérées comme légalement conformes aux exigences minimales de la circulaire. Cependant, les critères de niveau AAA comme 2.2.4 ont un poids pratique et réputationnel important dans le contexte du marché turc.

Plusieurs des types d’entités couvertes — en particulier les hôpitaux, les banques et les institutions publiques — servent des populations d’utilisateurs présentant des taux élevés de troubles cognitifs et neurologiques, de troubles anxieux et de difficultés d’attention liées à l’âge avancé. Pour ces organisations, les interruptions non contrôlées dans les interfaces numériques représentent non seulement un échec d’accessibilité, mais aussi un risque potentiel pour la sécurité des patients ou pour la sécurité financière. Un portail patient hospitalier qui déclenche des rappels de médication ou des notifications de rendez-vous incontrôlables pendant un flux critique de remplissage de formulaire, ou une application bancaire qui affiche des bandeaux promotionnels impossibles à supprimer pendant la vérification d’une transaction, crée un préjudice réel pour les utilisateurs de ces groupes.

Pour les organisations en Turquie qui cherchent à démontrer un leadership en accessibilité numérique — en particulier celles qui visent des déclarations volontaires de conformité WCAG 2.2 de niveau AAA, répondent aux exigences d’accessibilité des marchés publics ou ciblent les marchés européens où l’Acte européen sur l’accessibilité (EAA) fixe une norme plus élevée — la mise en œuvre de 2.2.4 constitue un facteur de différenciation significatif. Le SDK de surcouche Accsible aide les organisations à atteindre ces normes plus élevées en fournissant des fonctionnalités configurables de gestion des notifications, la persistance des préférences utilisateur et des comportements de widgets sensibles à l’accessibilité, alignés à la fois sur les attentes réglementaires turques et sur les meilleures pratiques internationales.