WCAG 1.4.2 : Contrôle de l’audio

Ce que signifie cette règle

WCAG 1.4.2 — Contrôle du son est un critère de succès de niveau A relevant du principe « Perceptible ». Il stipule : Si un son est diffusé automatiquement sur une page Web pendant plus de 3 secondes, un mécanisme est disponible pour mettre le son en pause ou l’arrêter, ou un mécanisme est disponible pour contrôler le volume du son indépendamment du volume global du système.

Ce critère est déclenché par tout contenu audio qui commence à être diffusé sans action explicite de l’utilisateur et se poursuit pendant plus de trois secondes. Cela inclut la musique de fond intégrée à une page, les vidéos en lecture automatique avec une bande sonore audible, les publicités audio, les effets sonores en boucle et les introductions vocales qui se déclenchent au chargement de la page. L’expression clé est automatiquement — l’audio que l’utilisateur lance délibérément (en cliquant sur un bouton de lecture, en activant un lien) n’est pas régi par cette règle.

Pour satisfaire à ce critère, au moins une des conditions suivantes doit être remplie :

• L’utilisateur dispose d’un contrôle de pause ou d’arrêt qui interrompt complètement l’audio ou le suspend jusqu’à ce que l’utilisateur le relance.
• L’utilisateur dispose d’un contrôle de volume indépendant du volume principal du système d’exploitation, afin qu’il puisse réduire ou couper le son sans affecter les autres applications ou sons système.

Un mécanisme qui n’apparaît qu’en haut de la page et qui est accessible au clavier est acceptable, mais il doit être atteignable et utilisable avant que l’audio ne devienne perturbant. La meilleure pratique consiste fortement à placer ce contrôle comme tout premier élément interactif dans l’ordre de tabulation afin que les utilisateurs de clavier et de lecteurs d’écran le rencontrent immédiatement.

La seule exception officielle définie dans les WCAG concerne l’audio qui dure trois secondes ou moins. Les sons de notification brefs ou les courts carillons qui s’arrêtent d’eux-mêmes sont exemptés. Il n’existe aucune exception pour l’audio à faible volume, l’audio en boucle ou l’audio intégré dans des widgets tiers — tous relèvent de cette règle s’ils se déclenchent automatiquement et dépassent trois secondes.

Pourquoi c’est important

L’audio en lecture automatique non contrôlé crée des obstacles importants pour plusieurs groupes de personnes handicapées, et provoque même des frictions pour les utilisateurs non handicapés dans des environnements calmes ou partagés.

Les utilisateurs de lecteurs d’écran sont le groupe le plus gravement touché. Les lecteurs d’écran tels que JAWS, NVDA et VoiceOver produisent une synthèse vocale pour transmettre le contenu de la page. Lorsqu’une page Web diffuse simultanément un son de fond ou la bande sonore d’une vidéo, les deux flux audio se superposent. La voix du lecteur d’écran devient difficile voire impossible à comprendre, ce qui exclut de fait l’utilisateur de la page jusqu’à ce qu’il puisse localiser et activer un contrôle d’arrêt — qu’il ne peut pas trouver facilement, car le lecteur d’écran ne peut pas lire la page par-dessus le bruit. Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, et une part significative d’entre elles s’appuie sur les lecteurs d’écran comme principal outil de navigation.

Les utilisateurs ayant des troubles cognitifs et de l’attention, y compris ceux avec TDAH, des troubles du spectre autistique ou des troubles anxieux, peuvent trouver un son inattendu extrêmement désorientant ou pénible. L’apparition soudaine de musique ou de parole peut briser la concentration, déclencher une surcharge sensorielle ou provoquer une confusion quant à savoir si le son fait partie du contenu de la page ou d’une notification externe.

Les utilisateurs ayant des troubles du traitement auditif ou des aides auditives peuvent subir des boucles de rétroaction ou une distorsion amplifiée lorsque le son est diffusé à des volumes inattendus via leurs dispositifs auditifs. Un contrôle de volume indépendant leur permet de gérer leur environnement d’écoute sans modifier les paramètres système globaux qui affectent les autres applications.

Les utilisateurs ayant une déficience motrice qui naviguent au clavier ou via des dispositifs de commande doivent pouvoir atteindre le contrôle d’arrêt/pause au clavier, et celui-ci doit être positionné logiquement tôt dans la structure de la page. Si le contrôle n’est cliquable qu’à la souris ou s’il est enfoui tard dans l’ordre de tabulation, il n’offre aucun soulagement pratique pendant le temps nécessaire pour y accéder.

Considérons un scénario concret : une personne aveugle en recherche d’emploi visite la page « carrières » d’une entreprise qui lance automatiquement une vidéo promotionnelle avec une musique entraînante. L’utilisateur active son lecteur d’écran, qui commence immédiatement à lire le titre de la page et la navigation. La musique couvre entièrement la synthèse vocale. Le bouton d’arrêt est un <div> stylisé sans focus clavier, positionné visuellement dans le lecteur vidéo au milieu de la page. L’utilisateur ne peut pas l’atteindre au clavier, ne peut pas entendre suffisamment son lecteur d’écran pour naviguer efficacement et finit par abandonner la page. L’entreprise perd un candidat qualifié et s’expose à un risque juridique potentiel.

Du point de vue de l’ergonomie et du référencement, les pages avec audio en lecture automatique présentent souvent des taux de rebond élevés, car de nombreux utilisateurs — handicapés ou non — ferment immédiatement les onglets lorsque du son inattendu commence. Les moteurs de recherche interprètent des taux de rebond élevés comme un signal de qualité négatif, ce qui nuit indirectement à la découvrabilité.

Règles axe-core associées

WCAG 1.4.2 nécessite un test manuel. Aucune règle automatisée axe-core ne correspond directement à ce critère. La raison pour laquelle les outils automatisés ne peuvent pas détecter cette violation tient de manière fondamentale à la façon dont les navigateurs et JavaScript fonctionnent :

• Déclenchement dynamique de l’audio : L’audio peut être déclenché par des minuteries JavaScript, des écouteurs d’événements ou des scripts tiers qui s’exécutent après l’analyse initiale du DOM. Un analyseur automatisé qui inspecte le DOM statique ne peut pas déterminer de manière fiable si un son sera diffusé automatiquement, pendant combien de temps, ni si un contrôle est fonctionnellement relié à cette source audio spécifique.
• Présence et opérabilité des contrôles : Un curseur de volume ou un bouton de pause peut exister dans le DOM mais être non fonctionnel, caché hors écran ou inaccessible au clavier. Les outils automatisés peuvent détecter la présence d’un élément mais ne peuvent pas vérifier que son activation arrête réellement l’audio sans exécuter l’interaction et écouter le résultat — une tâche qui nécessite un jugement auditif humain.
• Seuil temporel : Déterminer si un son est diffusé pendant plus de trois secondes nécessite une évaluation basée sur le temps lors du chargement de la page, ce qui dépasse le champ d’action des outils d’analyse du DOM statique ou même en temps réel.
• Contenus tiers intégrés : L’audio intégré via des iframes, des SDK tiers ou des réseaux publicitaires peut ne pas être inspectable par le bac à sable JavaScript de l’outil de test, rendant la détection impossible de manière programmatique.

En raison de ces limitations, les auditeurs doivent visiter eux-mêmes les pages, écouter la présence d’audio en lecture automatique et vérifier manuellement que des contrôles de pause/arrêt/volume existent, sont atteignables au clavier et fonctionnent correctement.

Comment tester

1. Pré-analyse automatisée : Exécutez axe DevTools ou Google Lighthouse sur la page. Bien qu’aucun de ces outils ne signale directement une violation de 1.4.2, ils feront remonter des problèmes connexes tels que l’absence de focus clavier sur les contrôles, des éléments de lecteur multimédia inaccessibles ou des libellés ARIA manquants sur des widgets audio personnalisés. Résolvez ces problèmes avant de commencer les tests manuels afin de ne pas confondre des problèmes distincts.
2. Détection manuelle de l’audio : Chargez la page avec vos haut-parleurs ou votre casque activés. Notez si un son commence à être diffusé dans les premières secondes sans aucune interaction de l’utilisateur. Le cas échéant, utilisez un minuteur pour confirmer qu’il dure plus de trois secondes. Vérifiez tous les principaux types de pages : page d’accueil, pages d’atterrissage, pages produit et toute page connue pour contenir des médias intégrés ou des emplacements publicitaires.
3. Localiser le contrôle d’arrêt/pause/volume : Sans utiliser la souris, appuyez sur Tab immédiatement après le chargement de la page. Comptez le nombre d’arrêts de tabulation avant d’atteindre le contrôle audio. Vérifiez que le contrôle reçoit un indicateur de focus visible. Appuyez sur Entrée ou Espace pour l’activer et confirmez que le son s’arrête ou que son volume peut être ajusté indépendamment.
4. Test avec lecteur d’écran NVDA et Firefox : Lancez NVDA, ouvrez Firefox et accédez à la page. Laissez l’audio démarrer. Essayez d’utiliser les commandes de lecture de NVDA (touches fléchées, curseur virtuel) pour localiser et activer le contrôle audio. Confirmez que NVDA annonce correctement le rôle et le libellé du contrôle (par exemple, « Mettre le son en pause, bouton ») et que son activation fait taire l’audio concurrent.
5. Test avec VoiceOver et Safari (macOS/iOS) : Activez VoiceOver avec Commande + F5. Accédez à la page et balayez ou utilisez les touches fléchées pour trouver le contrôle audio. Vérifiez que VoiceOver énonce un libellé pertinent et que le contrôle fonctionne comme prévu. Sur iOS, testez également le comportement de lecture automatique, car les navigateurs mobiles gèrent différemment les autorisations audio.
6. Test avec JAWS et Chrome : Avec JAWS actif, chargez la page dans Chrome. Utilisez la touche Tab et la liste des contrôles de formulaire de JAWS (Insert + F5) pour localiser les éléments interactifs. Confirmez que le contrôle audio apparaît dans la liste et qu’il est opérable.
7. Vérification des contenus tiers : Si la page contient des vidéos de réseaux sociaux intégrées, des unités publicitaires ou du contenu dans des iframes, chargez-les indépendamment lorsque c’est possible et vérifiez qu’ils sont également conformes, ou que la page hôte fournit un contrôle de neutralisation.
8. Vérification de l’indépendance du volume : Si la page propose un contrôle de volume plutôt qu’un contrôle de pause/arrêt, vérifiez que l’ajustement du volume de la page ne modifie pas le volume principal du système d’exploitation. Ouvrez une autre application (par exemple, un lecteur multimédia local) et confirmez que son volume n’est pas affecté après l’utilisation du contrôle de la page.

Comment corriger

Audio de fond en lecture automatique sans contrôles — Incorrect

<!-- Audio starts automatically with no visible or keyboard-accessible control -->
<audio src='background-music.mp3' autoplay loop></audio>

Audio de fond en lecture automatique avec contrôle de pause accessible — Correct

<!-- Control is the first focusable element, announced properly by screen readers -->
<button id='audio-toggle' aria-label='Pause background music' aria-pressed='true' onclick='toggleAudio()'>
  Pause Music
</button>

<audio id='bg-audio' src='background-music.mp3' autoplay loop></audio>

<script>
  function toggleAudio() {
    var audio = document.getElementById('bg-audio');
    var btn = document.getElementById('audio-toggle');
    if (audio.paused) {
      audio.play();
      btn.setAttribute('aria-pressed', 'true');
      btn.setAttribute('aria-label', 'Pause background music');
      btn.textContent = 'Pause Music';
    } else {
      audio.pause();
      btn.setAttribute('aria-pressed', 'false');
      btn.setAttribute('aria-label', 'Play background music');
      btn.textContent = 'Play Music';
    }
  }
</script>

<!-- The native <button> element is keyboard-accessible by default.
     aria-pressed communicates toggle state to screen readers.
     aria-label updates dynamically to reflect current action. -->

Vidéo en lecture automatique avec bande sonore et sans contrôle d’arrêt accessible au clavier — Incorrect

<!-- The video autoplays with sound; the only stop control is a mouse-only overlay -->
<div class='hero-video-wrapper'>
  <video src='promo.mp4' autoplay loop></video>
  <div class='stop-btn' onclick='stopVideo()'>Stop</div>
</div>
<!-- Problem: <div> is not keyboard-focusable and has no role or label -->

Vidéo en lecture automatique avec contrôle d’arrêt accessible — Correct

<div class='hero-video-wrapper'>
  <!-- Stop control appears first in DOM and focus order -->
  <button
    id='video-stop-btn'
    aria-label='Stop promotional video'
    onclick='stopVideo()'
  >
    Stop Video
  </button>

  <video id='promo-video' src='promo.mp4' autoplay loop muted='false'></video>
</div>

<script>
  function stopVideo() {
    var video = document.getElementById('promo-video');
    var btn = document.getElementById('video-stop-btn');
    video.pause();
    video.currentTime = 0;
    btn.disabled = true;
    btn.textContent = 'Video Stopped';
  }
</script>

<!-- Using a native <button> ensures keyboard access without additional ARIA.
     Placing the button before the video in DOM order puts it early in tab sequence. -->

Widget audio tiers intégré avec contrôle de volume indépendant — Correct

<!-- When a third-party widget auto-plays, provide a host-level mute control -->
<button
  id='mute-widget-audio'
  aria-label='Mute podcast player'
  aria-pressed='false'
  onclick='muteWidget()'
>
  Mute Podcast
</button>

<iframe
  id='podcast-frame'
  src='https://embed.example.com/podcast/ep42?autoplay=1'
  title='Episode 42: Web Accessibility Deep Dive'
  allow='autoplay'
></iframe>

<script>
  function muteWidget() {
    <!-- postMessage API used to communicate with cross-origin iframe player -->
    var frame = document.getElementById('podcast-frame');
    var btn = document.getElementById('mute-widget-audio');
    var isMuted = btn.getAttribute('aria-pressed') === 'true';
    frame.contentWindow.postMessage({ action: isMuted ? 'unmute' : 'mute' }, 'https://embed.example.com');
    btn.setAttribute('aria-pressed', String(!isMuted));
    btn.setAttribute('aria-label', isMuted ? 'Mute podcast player' : 'Unmute podcast player');
  }
</script>

<!-- Note: host-level volume/mute control satisfies 1.4.2 when
     the iframe player's own controls may be inaccessible. -->

Erreurs courantes

• Utiliser un <div> ou un <span> comme bouton d’arrêt audio sans ajouter tabindex='0', un role='button' et des gestionnaires d’événements clavier. De tels éléments sont invisibles pour la navigation au clavier et les lecteurs d’écran, rendant le contrôle inutile pour les utilisateurs qui en ont le plus besoin.
• Placer le contrôle audio après le contenu principal dans le DOM, de sorte que les utilisateurs au clavier doivent parcourir des dizaines de liens et de champs de formulaire avant de l’atteindre — moment où l’audio peut avoir été diffusé pendant une minute ou plus. Le contrôle doit être le premier ou le deuxième élément focalisable de la page.
• Mettre l’audio en sourdine par défaut avec l’attribut HTML muted et considérer cela comme conforme. Un élément audio en lecture automatique mais muet n’est pas un contrôle opérable par l’utilisateur ; celui-ci n’a aucun moyen de savoir que de l’audio existe ni de choisir sa propre préférence de volume.
• Fournir un curseur de volume qui appelle window.AudioContext.destination.gain et modifie les niveaux audio du système, plutôt que d’ajuster uniquement la propriété .volume de l’élément média spécifique. Cela ne respecte pas l’exigence d’indépendance.
• Supposer que les navigateurs mobiles bloquent la lecture automatique et qu’aucun contrôle n’est donc nécessaire. De nombreux navigateurs mobiles autorisent la lecture automatique lorsque l’audio est intégré dans un élément vidéo ou lorsque l’utilisateur a déjà interagi avec le domaine. Implémentez toujours des contrôles, quelle que soit la supposée configuration du navigateur.
• Ne pas mettre à jour le libellé accessible du bouton lorsque son état change. Un bouton libellé « Pause » qui relance désormais l’audio doit mettre à jour son aria-label en « Lecture » — sinon les utilisateurs de lecteurs d’écran entendent une annonce incorrecte et peuvent déclencher la mauvaise action.
• Se fier uniquement aux contrôles multimédia natifs du navigateur (attribut controls) sans vérifier qu’ils apparaissent avant que l’audio en lecture automatique ne devienne intrusif. Les contrôles natifs s’affichent sous l’élément média, qui peut se trouver sous la ligne de flottaison, les rendant inatteignables au clavier avant qu’une perturbation significative ne se produise.
• Ne pas tester les publicités audio diffusées via des réseaux publicitaires. Les emplacements publicitaires injectés dynamiquement après le chargement de la page font partie de l’expérience de la page et sont soumis à 1.4.2. Si le réseau publicitaire ne peut pas garantir la conformité, fournissez un contrôle global de coupure du son pour la page.
• Considérer l’exemption de trois secondes comme une échappatoire en découpant une piste audio continue en segments de moins de trois secondes chacun. L’intention des WCAG est claire : un son qui est diffusé en continu ou en boucle est soumis au critère, quelle que soit la manière dont il est techniquement segmenté.
• Ne pas fournir d’indicateur de focus visible sur le contrôle audio. Même si le contrôle est atteignable au clavier, les utilisateurs voyants au clavier ne peuvent pas le trouver s’il n’y a pas d’anneau de focus, ce qui viole à la fois l’intention d’ergonomie de ce critère et la WCAG 2.4.7 (Focus visible).

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 publiques et privées opérant en Turquie. WCAG 1.4.2 — Contrôle du son est un critère de niveau A, ce qui le place dans le niveau le plus fondamental des exigences. La non-conformité aux critères de niveau A constitue un échec de base au regard de la Circulaire.

La Circulaire impose les délais de conformité suivants : les institutions publiques doivent atteindre une conformité complète de niveau A dans un délai d’un an à compter de la date de publication de la Circulaire, tandis que les entités du secteur privé couvertes par la réglementation disposent de deux ans pour se mettre en conformité.

Les types d’entités suivants sont explicitement couverts par la Circulaire présidentielle et sont donc tenus de respecter WCAG 1.4.2 :

• Institutions publiques et organismes gouvernementaux à tous les niveaux, y compris les ministères, les municipalités et les agences affiliées à l’État dont les services numériques sont accessibles au public.
• Plateformes de commerce électronique opérant en Turquie, y compris les opérateurs de places de marché et les détaillants en ligne en vente directe aux consommateurs.
• Banques et institutions financières réglementées par la législation bancaire turque, y compris leurs portails de banque en ligne, interfaces Web mobiles et pages de produits numériques.
• Hôpitaux et prestataires de soins de santé, y compris les groupes hospitaliers privés et les portails de santé publics où les patients prennent des rendez-vous, accèdent à leurs dossiers ou reçoivent des informations de santé.
• Entreprises de télécommunications comptant 200,000 abonnés ou plus, dont les sites Web destinés aux clients, les portails en libre-service et les pages promotionnelles doivent être conformes.
• Agences de voyage et plateformes de voyage en ligne au service des consommateurs en Turquie, y compris les moteurs de réservation et les pages de contenu sur les destinations.
• Entreprises de transport privé fournissant des services de billetterie et d’information aux passagers en ligne.
• Écoles privées autorisées par le ministère de l’Éducation nationale (MoNE), y compris leurs portails d’inscription, systèmes de gestion de l’apprentissage et sites Web d’information.

Pour toutes ces entités, une page qui lance automatiquement un son — qu’il s’agisse d’une vidéo promotionnelle sur la page d’accueil d’une banque, d’une bande sonore de fond sur une page produit de commerce électronique ou d’un clip d’actualité intégré sur un portail gouvernemental — sans fournir un contrôle de pause ou de volume accessible et atteignable au clavier constitue une violation directe à la fois de WCAG 1.4.2 et des obligations imposées par la Circulaire présidentielle 2025/10. Il est fortement recommandé aux entités concernées d’auditer tous leurs modèles de page pour détecter les médias en lecture automatique et de mettre en œuvre des contrôles conformes bien avant la date limite qui leur est applicable, afin d’éviter des constats réglementaires et de servir équitablement tous les utilisateurs.