WCAG 1.2.9 : Audio uniquement (en direct)

Ce que signifie cette règle

Le critère de succès 1.2.9 des WCAG, Audio uniquement (en direct), relève de la directive 1.2 (Médias temporels) au niveau AAA. Il stipule : « Une alternative pour les médias temporels qui présente une information équivalente pour le contenu audio uniquement en direct est fournie. » Concrètement, cela signifie que chaque fois que votre site web ou votre application diffuse ou fournit du contenu audio en direct — et que ce contenu ne comporte aucun composant vidéo — les utilisateurs doivent disposer d’un équivalent textuel en temps réel qui transmet fidèlement la même information.

Une présentation audio uniquement en direct est tout flux audio diffusé en temps réel sans piste vidéo synchronisée. Parmi les exemples courants, on trouve les programmes de radio en direct intégrés à une page web, les commentaires audio en direct pendant un événement sportif, les conférences de presse en direct diffusées en format audio, les appels de résultats ou réunions d’investisseurs en direct, ainsi que les podcasts audio en direct ou les émissions de débat en direct sans flux vidéo accompagnant l’audio.

L’alternative textuelle exigée par ce critère doit être équivalente — c’est-à-dire qu’elle doit saisir non seulement les paroles prononcées, mais aussi les informations audio non verbales pertinentes telles que les bruits de foule, les alarmes, les effets sonores ou la musique qui ont une valeur informationnelle. Une transcription partielle ou différée ne satisfait pas ce critère ; l’alternative doit être mise à jour de manière synchrone (ou quasi synchrone) avec le flux en direct afin que les personnes sourdes ou malentendantes puissent suivre le contenu en temps réel.

Les techniques acceptables pour satisfaire ce critère incluent la mise à disposition d’un sténographe humain produisant du texte en temps réel (CART — Communication Access Realtime Translation), l’intégration de sous-titres en direct synchronisés générés par un service de sous-titrage qualifié, ou l’affichage d’un flux de texte en direct qui s’exécute en parallèle de la diffusion audio. Des sous-titres générés automatiquement par un logiciel de reconnaissance vocale peuvent également satisfaire le critère à condition que la précision soit suffisamment élevée et que le résultat soit présenté en quasi temps réel.

Ce qui est considéré comme conforme : La page fournit une alternative textuelle visible et synchrone — clairement liée ou affichée à proximité du lecteur audio — qui présente une information équivalente au flux audio en direct au fur et à mesure de son déroulement. L’alternative doit être perceptible par les utilisateurs qui ne peuvent pas entendre l’audio.

Ce qui est considéré comme non conforme : Aucune alternative textuelle n’est proposée ; une alternative textuelle est fournie mais avec un retard significatif (par exemple, une transcription publiée après l’événement) ; une alternative textuelle ne couvre qu’une partie de l’audio (par exemple, uniquement la parole de l’intervenant mais pas les questions du public) ; ou une alternative textuelle existe mais n’est pas accessible aux utilisateurs de technologies d’assistance (par exemple, elle est rendue dans un élément canvas non focalisable ou enfermée dans un widget Flash).

Exceptions officielles : Les WCAG ne prévoient pas d’exceptions spécifiques pour le critère 1.2.9 au-delà du principe général selon lequel l’exigence s’applique uniquement au contenu audio uniquement en direct. Le contenu audio uniquement préenregistré est couvert par le critère distinct 1.2.1. Il n’existe aucune exception pour les courts extraits audio ou les annonces brèves — si le contenu est en direct et audio uniquement, le critère s’applique.

Pourquoi c’est important

Environ 466 millions de personnes dans le monde présentent une perte auditive invalidante, selon l’Organisation mondiale de la Santé, et ce nombre devrait dépasser 900 millions d’ici 2050. Pour ces utilisateurs, le contenu audio uniquement en direct est totalement inaccessible sans équivalent textuel. Contrairement au contenu préenregistré — pour lequel une transcription peut être préparée à l’avance et jointe après coup — l’audio en direct pose un défi unique, car l’information est sensible au temps et éphémère. Une personne sourde ne peut pas simplement réécouter un flux en direct plus tard et s’attendre à la même expérience ; par définition, le contenu en direct perd son immédiateté une fois le moment passé.

Considérons un scénario concret : une société cotée en bourse organise un appel de résultats en direct diffusé en audio uniquement sur sa page de relations investisseurs. Les analystes, journalistes et investisseurs particuliers sourds ou malentendants ne peuvent pas participer à l’appel — ni même le suivre passivement — sans un flux de texte en temps réel. Des informations financières importantes, des mises à jour de prévisions et des réponses aux questions des analystes sont communiquées en temps réel, et tout retard dans la réception de ces informations place ces utilisateurs dans une situation de désavantage informationnel significatif. Dans les secteurs réglementés, cela peut même soulever des questions d’égalité d’accès à l’information publique.

Au-delà de la surdité, ce critère bénéficie à une population plus large. Les utilisateurs présentant des troubles du traitement auditif peuvent entendre l’audio mais avoir du mal à décoder la parole suffisamment rapidement pour suivre un flux en direct ; un flux de texte synchronisé leur permet de lire à leur propre rythme de compréhension pendant que l’audio est diffusé. Les utilisateurs se trouvant dans des environnements sensibles au bruit — tels que les bureaux ouverts, les bibliothèques ou les transports publics — qui ne peuvent pas diffuser l’audio à voix haute bénéficient d’une alternative textuelle. Les utilisateurs pour qui la langue de diffusion est une langue seconde trouvent également les alternatives textuelles plus faciles à suivre que la parole en direct à un rythme soutenu.

Du point de vue du référencement (SEO) et de la découvrabilité du contenu, une transcription textuelle en direct ou un flux de sous-titres crée du texte indexable que les moteurs de recherche peuvent explorer. Les événements en direct qui génèrent du texte en temps réel ont plus de chances d’apparaître dans les résultats de recherche et les agrégateurs d’actualités, élargissant la portée de l’audience bien au-delà de la fenêtre de diffusion initiale.

Pour les organisations opérant dans des secteurs réglementés — services financiers, santé, secteur public — fournir un accès équitable à l’information audio en direct est de plus en plus une attente plutôt qu’une simple courtoisie. Ne pas satisfaire ce critère peut exposer les organisations à des plaintes, à un risque de réputation et, dans certaines juridictions, à une responsabilité juridique.

Règles Axe-core associées

Le critère WCAG 1.2.9 nécessite un test manuel ; aucune règle axe-core automatisée ne peut détecter de manière fiable si un flux audio uniquement en direct dispose d’une alternative textuelle synchrone. Les raisons de cette limitation sont intrinsèquement liées à la nature du critère :

• Pourquoi l’automatisation ne peut pas détecter cette violation : Les outils automatisés comme axe-core opèrent sur des instantanés statiques du DOM ou des états de page à un moment donné. Ils peuvent détecter la présence d’un élément <audio> ou d’un lecteur multimédia, mais ils ne peuvent pas déterminer si le contenu associé est en direct ou préenregistré, si une zone de texte visible sur la page se met réellement à jour en synchronisation avec un flux audio, si le contenu textuel est sémantiquement équivalent à l’audio (couvrant toutes les informations audio verbales et non verbales), ou si un service de sous-titrage externe lié est effectivement actif et précis. Tous ces jugements nécessitent un examen humain de la diffusion en direct elle-même.
• Ce que l’auditeur manuel doit vérifier : L’auditeur doit accéder à la page pendant que le flux audio en direct est actif, identifier comment (ou si) une alternative textuelle est présentée, confirmer que l’alternative textuelle se met à jour en temps réel au fur et à mesure de la progression de l’audio, vérifier que le texte couvre tout le contenu audio significatif, y compris l’identification des intervenants, les sons non verbaux et les transitions, et confirmer que l’alternative textuelle est accessible aux technologies d’assistance — par exemple, qu’une région en direct utilisant aria-live='polite' ou aria-live='assertive' annonce correctement les mises à jour aux utilisateurs de lecteurs d’écran.
• Signaux d’automatisation partielle : Bien qu’axe-core ne puisse pas signaler directement l’absence d’une alternative textuelle en direct, les auditeurs doivent noter qu’axe-core signalera des problèmes connexes qui aggravent le problème — par exemple, si une zone de transcription textuelle existe mais est masquée avec display:none, ou si un lecteur multimédia ne dispose pas de commandes accessibles. Ces signaux constituent des points de départ utiles lors d’un examen manuel.

Comment tester

1. Analyse automatisée comme base : Exécutez axe DevTools ou Lighthouse sur la page hébergeant le flux audio en direct. Notez tout problème signalé concernant les éléments multimédias, les étiquettes manquantes ou les commandes inaccessibles. Bien qu’aucun de ces outils ne signale directement l’absence d’une alternative textuelle en direct, ils peuvent faire apparaître des obstacles connexes — comme un lecteur audio sans nom accessible ou un conteneur de transcription masqué de l’arbre d’accessibilité. Documentez ces constats et considérez-les comme faisant partie de l’évaluation globale de l’accessibilité.
2. Identifier le contenu audio en direct : Pendant que la diffusion en direct est active, confirmez que le flux audio est en direct (et non un enregistrement) et qu’il ne comporte aucune piste vidéo. Vérifiez le code source de la page et les requêtes réseau pour trouver des indices — les flux en direct utilisent généralement HLS (.m3u8), MPEG-DASH ou une diffusion basée sur WebSocket. Confirmez que le contenu est audio uniquement.
3. Vérifier la présence d’une alternative textuelle : Recherchez une zone de texte visible, une superposition de sous-titres ou un flux de transcription clairement étiqueté sur la page ou immédiatement lié depuis la page. L’alternative doit être mise en avant de manière visible — et non enfouie dans un menu de paramètres ou disponible uniquement sur demande. Si aucune alternative textuelle n’est visible, le critère est immédiatement non satisfait.
4. Vérifier la synchronisation : Avec l’alternative textuelle en direct visible, écoutez le flux audio et lisez simultanément le flux de texte. Confirmez que les mises à jour textuelles interviennent avec un décalage raisonnable (généralement de quelques secondes au maximum pour les services CART ou de sous-titrage professionnel). Un flux de texte qui se met à jour toutes les plusieurs minutes ou uniquement après la fin de la diffusion ne satisfait pas le critère.
5. Vérifier l’équivalence : Confirmez que l’alternative textuelle couvre tout le contenu audio significatif : paroles prononcées, identification des intervenants lorsqu’il y a plusieurs voix, sons non verbaux pertinents (par exemple, « [applaudissements] », « [son d’alarme] », « [musique] ») et toute annonce ou interruption à l’antenne.
6. Test avec lecteur d’écran — NVDA + Firefox : Ouvrez la page avec NVDA activé. Naviguez jusqu’à la région de texte en direct. Si la région utilise aria-live, NVDA doit annoncer automatiquement les nouvelles insertions de texte. S’il s’agit d’une zone de texte défilante, vérifiez que l’on peut y placer le focus et que le contenu est lisible. Vérifiez également que les commandes du lecteur audio sont utilisables au clavier.
7. Test avec lecteur d’écran — VoiceOver + Safari (macOS/iOS) : Activez VoiceOver et naviguez jusqu’à la région de texte en direct. Confirmez que VoiceOver lit le nouveau texte au fur et à mesure de son apparition. Sur iOS, vérifiez également l’expérience sur mobile — les événements en direct sont fréquemment consultés via des navigateurs mobiles.
8. Test avec lecteur d’écran — JAWS + Chrome : Avec JAWS activé, accédez à la page et confirmez que les annonces de la région en direct fonctionnent. JAWS gère différemment aria-live='polite' et aria-live='assertive' ; confirmez que le niveau de verbosité est approprié pour le type de contenu (un flux de sous-titres très dynamique peut être mieux adapté à assertive pour éviter les retards de mise en file d’attente).
9. Test mobile et en faible bande passante : Si le site s’adresse à un public mobile, testez l’alternative textuelle en direct sur un appareil Android de milieu de gamme avec une connexion bridée. Confirmez que le flux de texte reste synchronisé et accessible même dans des conditions contraintes.

Comment corriger

Scénario 1 : Lecteur audio en direct sans alternative textuelle — Incorrect

<!-- Live radio stream embedded with no accompanying text alternative -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'>
    Your browser does not support the audio element.
  </audio>
</section>

Scénario 1 : Lecteur audio en direct avec transcription dans une région ARIA live — Correct

<!-- Live radio stream with a synchronous ARIA live region for real-time captions -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'
         aria-describedby='live-caption-feed'>
    Your browser does not support the audio element.
  </audio>
  <!-- aria-live='assertive' ensures screen readers announce new text immediately -->
  <!-- aria-atomic='false' allows incremental updates rather than re-reading the whole block -->
  <div id='live-caption-feed'
       role='region'
       aria-label='Live captions'
       aria-live='assertive'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text is injected here by the captioning service JavaScript -->
  </div>
</section>

Scénario 2 : Transcription publiée uniquement après la fin de l’événement — Incorrect

<!-- Transcript link appears but only resolves after the broadcast -->
<div>
  <audio controls src='https://stream.example.com/press-conference'></audio>
  <p>A full transcript will be available after the press conference concludes.</p>
</div>

Scénario 2 : Flux CART en temps réel lié à côté du lecteur — Correct

<!-- Real-time CART captions are displayed inline during the live event -->
<div>
  <audio controls src='https://stream.example.com/press-conference'
         aria-describedby='cart-feed'></audio>
  <!-- The CART feed is an iframe served by a professional captioning provider -->
  <!-- The iframe must itself be accessible with an appropriate title -->
  <iframe
    id='cart-feed'
    src='https://cart-provider.example.com/feed/press-conference-2025'
    title='Real-time captions for live press conference'
    width='100%'
    height='200'>
  </iframe>
  <p>A full transcript will also be published after the event concludes.</p>
</div>

Scénario 3 : Sous-titres générés automatiquement, cachés derrière un bouton de paramètres — Incorrect

<!-- Captions exist but are hidden by default and require multiple steps to enable -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'></audio>
  <button onclick='toggleSettings()'>Settings</button>
  <div id='settings-panel' hidden>
    <button onclick='enableCaptions()'>Enable Captions</button>
  </div>
</div>

Scénario 3 : Sous-titres activés par défaut avec un bouton clair — Correct

<!-- Captions are ON by default; a prominent toggle lets users turn them off if preferred -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'
         aria-describedby='webinar-captions'></audio>
  <!-- Default state is captions-on; aria-pressed reflects current state -->
  <button id='caption-toggle'
          aria-pressed='true'
          onclick='toggleCaptions(this)'>
    Live Captions: On
  </button>
  <div id='webinar-captions'
       role='region'
       aria-label='Live webinar captions'
       aria-live='polite'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text injected here in real time -->
  </div>
</div>

Erreurs courantes

• Publier une transcription après l’événement et prétendre qu’elle satisfait le critère 1.2.9 : Une transcription publiée des heures ou des jours après une diffusion en direct n’est pas une alternative textuelle en temps réel. Le critère WCAG 1.2.9 exige spécifiquement que l’alternative soit disponible en même temps que l’audio en direct, et non rétroactivement.
• Utiliser aria-live='polite' pour un flux de sous-titres très dynamique : Les régions en direct « polite » attendent que l’utilisateur ait terminé son interaction avant d’annoncer le nouveau contenu. Pour des sous-titres qui se mettent à jour rapidement, cela entraîne la perte d’annonces pour les utilisateurs de lecteurs d’écran. Utilisez aria-live='assertive' pour les flux de sous-titres en direct où chaque mise à jour est critique en termes de temps.
• Injecter l’historique complet des sous-titres à chaque mise à jour plutôt que seulement le nouveau contenu : Lorsque aria-atomic='true' est défini et que l’ensemble du bloc de texte est remplacé à chaque mise à jour, les lecteurs d’écran tentent de relire toute la région, ce qui crée une expérience perturbante. Utilisez aria-atomic='false' et ajoutez de nouveaux nœuds de texte afin que seule la nouvelle portion soit annoncée.
• Intégrer le flux de sous-titres dans un élément <canvas> ou comme un graphique superposé à la vidéo : Le texte des sous-titres rendu sous forme de pixels dans un canvas ou incrusté dans une image vidéo est invisible pour les technologies d’assistance. Les alternatives textuelles doivent être fournies sous forme de nœuds de texte réels dans le DOM.
• Placer la région de sous-titres en direct hors écran avec position:absolute; left:-9999px : Bien que masquer visuellement le contenu de cette manière le maintienne dans l’arbre d’accessibilité, cela empêche les utilisateurs voyants malentendants de lire les sous-titres. L’alternative textuelle doit être visuellement disponible pour tous les utilisateurs, et pas seulement pour les utilisateurs de lecteurs d’écran.
• Ne pas identifier les intervenants lors de diffusions avec plusieurs locuteurs : Un flux de sous-titres qui transcrit la parole sans l’attribuer à des intervenants spécifiques (par exemple, « [Modérateur] : », « [PDG] : », « [Membre du public] : ») n’est pas pleinement équivalent. L’identification des intervenants est essentielle pour permettre aux utilisateurs de suivre la structure conversationnelle d’un événement en direct.
• Omettre les informations audio non verbales dans l’alternative textuelle : Les sons pertinents tels que les applaudissements, les interruptions techniques, la musique de fond, les alarmes ou les rires ont une valeur informationnelle et doivent être décrits dans le flux de texte (par exemple, « [applaudissements] », « [problèmes techniques — audio interrompu] »).
• Fournir l’alternative textuelle uniquement via une URL tierce distincte sans l’intégrer sur la même page : Obliger les utilisateurs à ouvrir un onglet ou une fenêtre de navigateur séparé pour accéder aux sous-titres pendant que l’audio est diffusé sur la page d’origine crée un obstacle d’utilisabilité important, en particulier pour les utilisateurs de lecteurs d’écran et les utilisateurs au clavier qui doivent changer de contexte.
• Supposer que les sous-titres générés automatiquement satisfont toujours au seuil d’équivalence : Les sous-titres générés par l’IA peuvent présenter des taux d’erreur élevés avec les accents, le vocabulaire technique, les noms propres et la parole rapide. Déployer des sous-titres générés automatiquement sans correction pour un événement en direct à fort enjeu (par exemple, un briefing médical ou une communication financière) peut ne pas satisfaire la norme d’équivalence, même si un flux de sous-titres est techniquement présent.
• Ne pas tester la région de texte en direct avec de vrais lecteurs d’écran pendant une diffusion en direct : De nombreuses équipes testent le lecteur et le conteneur de sous-titres isolément à l’aide de texte statique fictif, mais ne testent jamais le comportement dynamique pendant un flux en direct réel. Les bogues dans le JavaScript qui injecte les mises à jour de sous-titres — tels que des observateurs de mutation du DOM qui échouent silencieusement — n’apparaîtront que lors de tests en conditions réelles.

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 obligations contraignantes en matière d’accessibilité web pour un large éventail d’organisations opérant en Turquie. La circulaire impose la conformité aux WCAG 2.2 au niveau AA comme norme de base. Les types d’entités couvertes incluent les institutions et agences publiques, les plateformes de commerce électronique, les banques et institutions financières, les hôpitaux et prestataires de soins de santé privés, les entreprises de télécommunications comptant 200 000 abonnés ou plus, les agences de voyage agréées, les entreprises de transport privées et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE).

Le critère WCAG 1.2.9 est un critère de niveau AAA, ce qui signifie qu’il ne fait pas partie des exigences de conformité imposées par la circulaire au niveau AA de base. Les organisations couvertes par la circulaire présidentielle 2025/10 ne sont pas légalement tenues de mettre en œuvre des alternatives textuelles pour l’audio uniquement en direct, sauf si elles se sont engagées séparément à une conformité complète aux WCAG 2.2 au niveau AAA.

Cependant, plusieurs considérations pratiques rendent le critère 1.2.9 très pertinent pour les organisations turques, même au-delà du minimum légal strict. Les fournisseurs de télécommunications, les institutions financières et les diffuseurs publics proposent fréquemment du contenu audio en direct — appels d’investisseurs, annonces publiques, émissions de service client en direct — dont les personnes sourdes ou malentendantes en Turquie dépendent. Démontrer une conformité de niveau AAA témoigne d’un engagement exemplaire en matière d’accessibilité et réduit significativement le risque de plaintes pour discrimination au regard du cadre plus large des droits des personnes handicapées en Turquie, y compris la loi sur les personnes handicapées n° 5378 et ses règlements d’application.

Pour les organisations qui poursuivent volontairement la conformité aux WCAG 2.2 au niveau AAA — que ce soit pour différencier leur positionnement en matière d’accessibilité, pour servir des marchés internationaux aux exigences plus strictes, ou pour s’aligner sur des critères d’achat exigeant le niveau AAA — la mise en œuvre correcte du critère 1.2.9 est essentielle. Accsible recommande que les organisations turques des secteurs réglementés évaluent de manière proactive leur contenu audio en direct et examinent la faisabilité d’intégrer des services CART ou un sous-titrage en temps réel à haute précision, en particulier pour les événements en direct destinés au public, où l’équité d’accès à l’information est une attente concrète des parties prenantes.