Critères de succès WCAG · Level AAA

WCAG 1.4.7 : Faible ou absence d’audio de fond

La norme WCAG 1.4.7 exige que le contenu audio préenregistré contenant de la parole n’ait soit aucun son de fond, permette de désactiver les sons de fond, ou maintienne les sons de fond au moins 20 dB plus faibles que la parole au premier plan. Cela protège les personnes malentendantes et celles ayant des handicaps cognitifs qui ont du mal à distinguer la parole d’autres sources audio concurrentes.

Ce que signifie cette règle

Le critère de succès 1.4.7 des WCAG — Faible ou absence de son de fond — s’applique au contenu audio uniquement pré-enregistré qui contient de la parole au premier plan. Il ne s’applique pas à l’audio qui est en soi une performance musicale, comme une chanson, ni à l’audio qui est principalement un paysage sonore ambiant sans composante de parole prévue. Lorsque du contenu audio basé sur la parole est présent, le critère exige qu’au moins une des trois conditions suivantes soit remplie :

  • Aucun son de fond : La piste audio contient de la parole sans aucun son de fond — silence derrière la voix.
  • Contrôle par l’utilisateur : Tout son de fond peut être désactivé par l’utilisateur, indépendamment de la parole au premier plan, sans affecter le contenu de la parole.
  • Règle des 20 dB : Les sons de fond sont au moins 20 décibels en dessous du volume de la parole au premier plan. Une différence de 20 dB équivaut approximativement à un son de fond quatre fois plus faible que la parole, ce qui représente un écart perceptif significatif pour la plupart des auditeurs.

Un succès est enregistré lorsque l’une de ces trois conditions est entièrement satisfaite. Un échec se produit lorsque la parole au premier plan est en concurrence avec un son de fond qui ne peut pas être désactivé et dont la différence de volume est inférieure à 20 dB par rapport au signal de parole. Notez que les effets sonores occasionnels — comme un bref son de notification — qui ne durent qu’une ou deux secondes sont explicitement exemptés de cette exigence par la spécification WCAG.

Ce critère s’applique à la piste audio, que cet audio soit diffusé comme un fichier audio autonome, comme composante audio d’une vidéo, ou intégré via un lecteur de podcast, un élément HTML5 <audio> ou un widget média tiers. L’exigence concerne la production du contenu audio lui-même, et non un élément HTML spécifique ou un attribut ARIA — c’est pourquoi les outils d’analyse automatisée ne peuvent pas détecter de manière fiable les violations et qu’un examen manuel du contenu audio réel est toujours nécessaire.

Pourquoi c’est important

Environ 1,5 milliard de personnes dans le monde vivent avec un certain degré de perte auditive, selon l’Organisation mondiale de la Santé. Même une perte auditive modérée peut rendre extrêmement difficile — parfois impossible — l’isolement de la voix d’un·e locuteur·rice lorsque la musique de fond, le bruit ambiant ou d’autres éléments audio sont mixés à des niveaux de volume similaires ou concurrents. Pour les utilisateurs qui dépendent d’appareils auditifs ou d’implants cochléaires, les interférences du son de fond sont amplifiées en même temps que la parole, ce qui rend l’intelligibilité nettement pire plutôt que meilleure.

Les utilisateurs ayant des handicaps cognitifs, y compris ceux présentant des troubles de l’attention, des troubles du traitement auditif ou des lésions cérébrales traumatiques, sont également confrontés à des difficultés importantes lorsque les pistes audio contiennent des sons concurrents. Même lorsque l’auditeur ne présente aucune perte auditive mesurable, son cerveau peut avoir du mal à filtrer les signaux audio non pertinents et à se concentrer sur le contenu de la parole, ce qui entraîne fatigue, échec de compréhension ou exclusion totale du contenu.

Considérez un scénario concret du monde réel : une agence gouvernementale turque publie un enregistrement audio explicatif sur la façon dont les citoyens peuvent demander une prestation sociale. La voix du narrateur est mixée sur une piste musicale de fond continue à des niveaux de volume approximativement égaux. Un utilisateur présentant une perte auditive neurosensorielle modérée consulte la page en utilisant un appareil auditif. Comme l’appareil auditif amplifie toutes les fréquences simultanément, la musique est en concurrence directe avec la parole du narrateur. L’utilisateur ne peut pas comprendre les instructions et manque la date limite pour sa demande de prestation. Si l’audio avait été enregistré sans musique de fond, ou si un contrôle de volume avait été fourni pour supprimer la piste de fond de manière indépendante, l’utilisateur aurait eu un accès égal à l’information.

Au-delà du handicap, un son clair avec un bruit de fond minimal améliore la compréhension pour tous les utilisateurs — ceux qui écoutent dans des environnements bruyants sur des appareils mobiles, les locuteurs non natifs de la langue parlée, et les utilisateurs dans des situations de faible bande passante où la qualité audio peut déjà être dégradée. Il existe également des avantages SEO indirects : les transcriptions d’un audio clairement intelligible produisent un contenu textuel de meilleure qualité que les moteurs de recherche peuvent indexer, améliorant la découvrabilité de votre contenu.

Règles Axe-core associées

WCAG 1.4.7 nécessite des tests manuels. Il n’existe aucune règle automatisée axe-core capable de détecter cette violation, et c’est intentionnel. Les analyseurs d’accessibilité automatisés tels qu’axe-core, Lighthouse ou IBM Equal Access Checker fonctionnent en analysant la structure du DOM, les attributs HTML, les rôles ARIA et les styles calculés d’une page web. Ils n’ont pas la capacité de :

  • Analyser le contenu audio d’un fichier : Les analyseurs ne peuvent pas ouvrir un fichier audio ou vidéo et mesurer les niveaux de décibels relatifs de la parole au premier plan par rapport au son de fond. Le faire nécessiterait un traitement du signal audio bien au-delà du champ d’application d’un vérificateur d’accessibilité basé sur le DOM.
  • Détecter si un contrôle séparé du son de fond existe et fonctionne correctement : Même si un contrôle d’interface utilisateur étiqueté « Turn off background music » est présent dans le DOM, un analyseur ne peut pas vérifier qu’il supprime effectivement la piste audio de fond sans affecter la piste de parole, ni vérifier que le contrôle fonctionne comme prévu dans tous les navigateurs.
  • Distinguer la parole des sons non vocaux : Les outils automatisés ne peuvent pas classer de manière fiable un fichier audio comme principalement parole, principalement musique ou principalement ambiant, ce qui est la détermination préalable avant même que le critère ne s’applique.

Parce que toute l’évaluation doit être effectuée par un examinateur humain écoutant le contenu et, si nécessaire, utilisant un logiciel d’analyse audio pour mesurer les niveaux de décibels, axe-core signale que ce critère nécessite un examen manuel. Lorsque vous exécutez axe DevTools sur une page contenant des éléments <audio> ou <video>, l’outil peut faire apparaître un avis général lié aux médias vous rappelant d’évaluer manuellement les critères de qualité audio, mais il ne produira pas automatiquement un verdict de succès ou d’échec pour 1.4.7.

Comment tester

  1. Recenser tout le contenu audio de la page. Chargez la page et identifiez chaque élément <audio>, chaque élément <video> avec une piste audio, chaque podcast ou lecteur média intégré, et tout son de fond qui se lance automatiquement. Déterminez si chaque élément audio est pré-enregistré et contient de la parole au premier plan. S’il s’agit d’une piste purement musicale ou d’un son ambiant sans parole, 1.4.7 ne s’y applique pas.
  2. Lancer une analyse automatisée pour les problèmes de base. Utilisez axe DevTools, Lighthouse ou l’audit intégré du widget Accsible pour analyser la page. Bien que ces outils n’évaluent pas la qualité audio, ils peuvent signaler l’absence de sous-titres, l’absence d’attribut controls sur les éléments <audio>, ou d’autres problèmes d’accessibilité liés aux médias. Corrigez tous les problèmes signalés avant de passer à l’évaluation audio manuelle.
  3. Écouter chaque piste audio concernée dans son intégralité. Utilisez le lecteur intégré à la page ou téléchargez le fichier et ouvrez-le dans un lecteur multimédia. Écoutez spécifiquement la musique de fond, le son ambiant ou tout autre son non vocal qui joue simultanément avec la parole au premier plan.
  4. Évaluer si le son de fond peut être désactivé de manière indépendante. Si le lecteur fournit un contrôle séparé pour couper ou baisser la musique de fond sans affecter la piste vocale, vérifiez que ce contrôle fonctionne comme prévu sur Chrome, Firefox et Safari. Testez avec une navigation uniquement au clavier pour confirmer que le contrôle est accessible.
  5. Mesurer les niveaux de décibels si un son de fond est présent et ne peut pas être désactivé. Importez le fichier audio dans un éditeur audio gratuit comme Audacity. Utilisez l’affichage de forme d’onde ou de spectrogramme intégré et l’outil « Analyze > Contrast » (ou équivalent) pour mesurer le niveau RMS moyen des segments de parole par rapport au niveau RMS moyen des segments de son de fond. Confirmez que la différence est d’au moins 20 dB. Si vous n’avez pas accès à un logiciel d’analyse audio, utilisez votre jugement professionnel en tant qu’auditeur expérimenté : si une personne typique avec une légère perte auditive trouverait le son de fond distrayant ou masquant, considérez-le comme un échec probable.
  6. Tester avec des technologies d’assistance. En utilisant NVDA avec Firefox, VoiceOver avec Safari sur macOS, et JAWS avec Chrome, naviguez jusqu’à chaque lecteur audio. Confirmez que tous les contrôles — y compris tout bouton séparé de bascule du son de fond — sont accessibles au clavier (Tab/Shift+Tab), annoncés correctement par le lecteur d’écran et actionnables avec Entrée ou Espace. Cela ne teste pas directement la qualité audio, mais confirme que les contrôles correctifs que vous avez ajoutés sont accessibles.
  7. Documenter les résultats. Notez quels fichiers audio réussissent (aucun son de fond, contrôle utilisateur disponible ou différence de 20 dB confirmée), lesquels échouent et lesquels sont exemptés (effets sonores courts de moins de 2 secondes, ou audio principalement musical plutôt que basé sur la parole).

Comment corriger

Scénario 1 : Musique de fond mixée trop fort — Incorrect

<!-- Audio file contains a narrator speaking over background music
     mixed at roughly equal volume levels. No separate control exists.
     This fails WCAG 1.4.7 because background audio is not 20 dB below speech
     and cannot be turned off independently. -->
<audio controls src='product-explainer.mp3'>
  Your browser does not support the audio element.
</audio>

Scénario 1 : Musique de fond mixée trop fort — Correct

<!-- The audio file has been re-exported with no background music.
     If background music is desired for branding, produce two separate
     audio tracks: one speech-only and one with music. Offer the
     speech-only version as the default accessible option. -->
<audio controls src='product-explainer-speech-only.mp3'>
  Your browser does not support the audio element.
</audio>
<p>
  <a href='product-explainer-with-music.mp3'>
    Listen to version with background music (may be harder to follow for some users)
  </a>
</p>

Scénario 2 : Son de fond avec un contrôle de sourdine indépendant — Incorrect

<!-- A custom player claims to offer background audio control,
     but the button is not keyboard-accessible and has no accessible name.
     Sighted mouse users can click it, but screen reader users and
     keyboard-only users cannot reach or operate the control. -->
<div class='player'>
  <audio id='main-audio' src='lecture-with-ambience.mp3'></audio>
  <button onclick='document.getElementById("main-audio").play()'>Play</button>
  <div onclick='toggleBackground()' style='cursor:pointer'>
    <img src='music-icon.png'>
  </div>
</div>

Scénario 2 : Son de fond avec un contrôle de sourdine indépendant — Correct

<!-- The background audio toggle is now a proper <button> element with
     an accessible name, keyboard focus, and an aria-pressed state so
     screen readers announce whether background audio is on or off. -->
<div class='player'>
  <audio id='main-audio' src='lecture-with-ambience.mp3'></audio>
  <audio id='bg-audio' src='background-ambience.mp3' loop></audio>
  <button onclick='document.getElementById("main-audio").play()'>Play lecture</button>
  <button
    id='bg-toggle'
    aria-pressed='true'
    onclick='toggleBackground()'
  >
    Background audio: on
  </button>
</div>
<script>
  function toggleBackground() {
    var bg = document.getElementById('bg-audio');
    var btn = document.getElementById('bg-toggle');
    if (bg.paused) {
      bg.play();
      btn.setAttribute('aria-pressed', 'true');
      btn.textContent = 'Background audio: on';
    } else {
      bg.pause();
      btn.setAttribute('aria-pressed', 'false');
      btn.textContent = 'Background audio: off';
    }
  }
</script>

Scénario 3 : Lecture automatique du son de fond au chargement de la page — Incorrect

<!-- Background audio autoplays when the page loads and there is
     no way to turn it off. If a narrator audio also plays, the
     background audio will compete with it and cannot be suppressed. -->
<audio autoplay loop src='ambient-background.mp3'></audio>
<audio controls src='welcome-message.mp3'></audio>

Scénario 3 : Lecture automatique du son de fond au chargement de la page — Correct

<!-- Background audio does not autoplay. A clearly labeled, keyboard-
     accessible button allows the user to opt in if desired. The speech
     audio is presented independently and cleanly without competition. -->
<audio id='bg' loop src='ambient-background.mp3'></audio>
<button onclick='document.getElementById("bg").play()'>
  Play background music (optional)
</button>
<audio controls src='welcome-message.mp3'>
  Your browser does not support the audio element.
</audio>

Erreurs courantes

  • Mixer la musique de fond à -10 dB au lieu des -20 dB requis : Les producteurs appliquent souvent une réduction de volume modérée à la musique de fond et supposent que cela suffit. La norme WCAG exige une différence complète de 20 dB (environ quatre fois plus faible), et pas seulement une réduction perceptible. Vérifiez toujours avec un outil d’analyse audio plutôt que de vous fier uniquement à un jugement subjectif.
  • Confondre le contrôle de volume global du lecteur avec un contrôle indépendant du son de fond : Un curseur de volume principal qui baisse simultanément la parole et le son de fond ne satisfait pas la condition « l’utilisateur peut désactiver le son de fond ». Le contrôle doit supprimer uniquement le son de fond sans affecter la parole au premier plan.
  • Supposer que le critère ne s’applique qu’aux fichiers audio autonomes : De nombreux développeurs oublient que la piste audio d’un élément vidéo est tout autant soumise à 1.4.7. Une vidéo explicative avec une musique de fond forte mixée dans la piste audio échoue au critère tout comme le ferait un fichier de podcast.
  • Considérer que tous les sons courts sont exemptés : L’exemption WCAG pour les effets sonores brefs s’applique uniquement aux sons qui durent deux secondes ou moins. Un jingle court récurrent qui se répète toutes les quelques secondes, ou une boucle de sons courts en arrière-plan, n’est pas couvert par cette exemption et doit tout de même être conforme.
  • Ne pas tester la bascule du son de fond avec une navigation uniquement au clavier : Les équipes implémentent souvent un bouton de sourdine visuellement attrayant en utilisant un élément non interactif comme un <div> ou un <span>, qui n’est pas accessible via la touche Tab et n’est pas actionnable avec Entrée ou Espace. Utilisez un élément natif <button> afin que la prise en charge du clavier et des technologies d’assistance soit intégrée.
  • Oublier d’ajouter aria-pressed ou un état équivalent aux boutons de bascule du son de fond : Sans indicateur d’état, les utilisateurs de lecteurs d’écran peuvent actionner le bouton mais ne peuvent pas savoir si le son de fond est actuellement activé ou désactivé. Reflétez toujours l’état actuel dans le nom accessible du bouton ou via aria-pressed.
  • Produire un seul fichier audio mixé au lieu de proposer des pistes séparées : Lorsque le son de fond est essentiel à l’intention créative, les équipes exportent souvent un seul fichier mixé plutôt que de proposer une alternative uniquement parole. Fournir une version séparée uniquement parole coûte très peu d’effort de production supplémentaire et élimine entièrement le risque de non-conformité.
  • Appliquer 1.4.7 aux flux audio en direct : Le critère couvre explicitement uniquement l’audio pré-enregistré. Les diffusions audio en direct ne sont pas soumises à cette règle spécifique, bien que d’autres critères tels que 1.4.4 (Redimensionnement du texte) et les exigences en matière de sous-titres puissent toujours s’appliquer au contenu associé.
  • Négliger de vérifier les lecteurs intégrés tiers : Lorsque le contenu est intégré à partir de plateformes externes (hébergeurs de podcasts, CDN vidéo, services de partage audio), les équipes supposent souvent que la conformité relève de la responsabilité de la plateforme. Cependant, le propriétaire de la page est responsable de l’accessibilité de tout le contenu sur ses pages, y compris les médias intégrés. Vérifiez que le lecteur tiers respecte les exigences de qualité audio ou offre les contrôles nécessaires.
  • Mesurer les niveaux de crête au lieu des niveaux RMS moyens lors de la vérification de l’exigence des 20 dB : Le seuil de 20 dB dans WCAG 1.4.7 se réfère au volume perçu de l’audio, le mieux approximé par les niveaux RMS (Root Mean Square) moyens, et non par les niveaux de crête instantanés. L’utilisation de mesures de niveau de crête peut produire des résultats trompeusement favorables qui ne reflètent pas l’expérience d’écoute réelle.

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é numérique pour un large éventail d’entités publiques et privées opérant en Turquie. La circulaire adopte WCAG 2.2 comme norme technique normative et définit des obligations de conformité spécifiques en fonction du type d’organisation.

Les entités soumises à la conformité obligatoire en vertu de la circulaire comprennent les institutions publiques et les agences gouvernementales à tous les niveaux, les plateformes de commerce électronique, les banques et prestataires de services financiers, les hôpitaux et établissements de santé, les opérateurs 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 autorisées par le ministère de l’Éducation nationale (MoNE). Ces organisations sont tenues de respecter au minimum les niveaux A et AA de WCAG 2.2.

WCAG 1.4.7 — Faible ou absence de son de fond — est un critère de niveau AAA. Cela signifie qu’il ne fait pas partie des critères que les entités couvertes sont légalement tenues de respecter dans le cadre des exigences de base de la circulaire 2025/10. Cependant, plusieurs considérations importantes s’appliquent. Premièrement, les organisations qui s’engagent volontairement à une conformité AAA — ou qui servent des populations avec une forte proportion d’utilisateurs malentendants, comme les hôpitaux, les cliniques d’audiologie ou les agences de services sociaux — devraient considérer 1.4.7 comme effectivement obligatoire dans leur contexte. Deuxièmement, toute entité dont les services numériques incluent du contenu pédagogique audio, des enregistrements de service client, des modules d’e-learning ou des diffusions d’information destinées au public constatera que le respect de 1.4.7 améliore considérablement l’utilisabilité réelle de ces services pour les citoyens turcs ayant des handicaps auditifs.

La Turquie compte une population importante de personnes malentendantes, et la circulaire reflète un engagement gouvernemental à garantir une participation numérique égale. Bien que les critères AAA soient présentés comme ambitieux dans la norme technique, les institutions publiques turques en particulier sont encouragées à dépasser les exigences minimales lorsque leur contenu et leurs ressources le permettent. Démontrer la conformité à 1.4.7 témoigne de la maturité organisationnelle, réduit les risques juridiques et de réputation, et positionne les services numériques turcs comme des leaders du design inclusif, tant au niveau national que sur les marchés internationaux où la conformité AAA peut être exigée contractuellement.