WCAG 1.2.9: Solo audio (en vivo)

Qué significa esta regla

El Criterio de Éxito 1.2.9 de las WCAG, Solo audio (en vivo), se encuentra bajo la Pauta 1.2 (Medios dependientes del tiempo) en el nivel AAA. Establece: «Se proporciona una alternativa para medios dependientes del tiempo que presenta información equivalente para contenido de solo audio en vivo.» En términos prácticos, esto significa que siempre que tu sitio web o aplicación transmita o entregue contenido de audio en vivo —y ese contenido no tenga componente de video— se debe proporcionar a las personas usuarias un equivalente textual en tiempo real que transmita fielmente la misma información.

Una presentación de solo audio en vivo es cualquier transmisión de audio que se emite en tiempo real sin una pista de video sincronizada. Ejemplos comunes incluyen programas de radio en vivo incrustados en una página web, comentarios de audio en vivo durante un evento deportivo, conferencias de prensa en vivo transmitidas en formato de audio, llamadas de resultados o sesiones informativas para inversores en vivo, y pódcasts o programas de debate de audio en vivo donde no hay una señal de video que acompañe al audio.

La alternativa textual requerida por este criterio debe ser equivalente, es decir, debe captar no solo las palabras habladas, sino también la información de audio no verbal relevante, como ruido de la multitud, alarmas, efectos de sonido o música que tengan valor informativo. Una transcripción parcial o retrasada no satisface este criterio; la alternativa debe actualizarse de forma síncrona (o casi síncrona) con la transmisión en vivo para que las personas sordas o con discapacidad auditiva puedan seguir el contenido en tiempo real.

Las técnicas aceptables para cumplir este criterio incluyen proporcionar una persona taquígrafa en vivo que produzca texto en tiempo real (CART — Communication Access Realtime Translation), incrustar subtítulos en vivo sincronizados generados por un servicio de subtitulado cualificado o mostrar un flujo de texto en vivo que se ejecute de forma concurrente con la transmisión de audio. Los subtítulos generados automáticamente mediante software de reconocimiento de voz también pueden satisfacer el criterio siempre que la precisión sea suficientemente alta y la salida se presente casi en tiempo real.

Qué se considera cumplimiento: La página proporciona una alternativa textual visible y síncrona —claramente vinculada o mostrada junto al reproductor de audio— que presenta información equivalente a la transmisión de audio en vivo a medida que se desarrolla. La alternativa debe ser perceptible para las personas usuarias que no pueden oír el audio.

Qué se considera incumplimiento: No se ofrece ninguna alternativa textual; se proporciona una alternativa textual pero con un retraso significativo (por ejemplo, una transcripción publicada después del evento); la alternativa textual cubre solo una parte del audio (por ejemplo, solo el discurso de la persona presentadora pero no las preguntas del público); o existe una alternativa textual pero no es accesible para las personas usuarias de tecnologías de apoyo (por ejemplo, se representa como un elemento canvas que no puede recibir foco o está bloqueada dentro de un widget Flash).

Excepciones oficiales: Las WCAG no establecen excepciones específicas para 1.2.9 más allá del principio general de que el requisito se aplica únicamente al contenido de solo audio en vivo. El contenido de solo audio pregrabado está cubierto por el criterio independiente 1.2.1. No hay excepción para clips de audio cortos o anuncios breves: si el contenido es en vivo y solo de audio, el criterio se aplica.

Por qué es importante

Aproximadamente 466 millones de personas en todo el mundo tienen pérdida de audición discapacitante, según la Organización Mundial de la Salud, y se proyecta que esta cifra aumente a más de 900 millones para 2050. Para estas personas usuarias, el contenido de solo audio en vivo es totalmente inaccesible sin un equivalente textual. A diferencia del contenido pregrabado —en el que se puede preparar una transcripción con antelación y adjuntarla posteriormente— el audio en vivo presenta un desafío único porque la información es sensible al tiempo y efímera. Una persona sorda no puede simplemente reproducir una transmisión en vivo más tarde y esperar la misma experiencia; por definición, el contenido en vivo pierde su inmediatez una vez que el momento ha pasado.

Considera un escenario real concreto: una empresa que cotiza en bolsa organiza una llamada de resultados en vivo transmitida solo en audio en su página de relaciones con inversores. Analistas, periodistas e inversores minoristas sordos o con discapacidad auditiva no pueden participar —ni siquiera seguir pasivamente— la llamada sin un flujo de texto en tiempo real. Divulgaciones financieras importantes, actualizaciones de previsiones y respuestas a preguntas de analistas se comunican en tiempo real, y cualquier retraso en recibir esa información coloca a estas personas usuarias en una desventaja informativa significativa. En sectores regulados, esto incluso puede plantear dudas sobre la igualdad de acceso a la información pública.

Más allá de la sordera, este criterio beneficia a una población más amplia. Las personas con trastornos del procesamiento auditivo pueden oír el audio pero tener dificultades para descifrar el habla con la rapidez suficiente para seguir una transmisión en vivo; un flujo de texto sincronizado les permite leer a su propio ritmo de comprensión mientras el audio se reproduce. Las personas en entornos sensibles al ruido —como oficinas abiertas, bibliotecas o transporte público— que no pueden reproducir audio en voz alta se benefician de una alternativa textual. Las personas para quienes el idioma de la transmisión es una segunda lengua también encuentran más fácil seguir alternativas textuales que un discurso en vivo a ritmo rápido.

Desde la perspectiva del SEO y la capacidad de descubrimiento de contenido, una transcripción de texto en vivo o un flujo de subtítulos crea texto indexable que los motores de búsqueda pueden rastrear. Los eventos en vivo que generan texto en tiempo real tienen más probabilidades de aparecer en los resultados de búsqueda y en agregadores de noticias, ampliando el alcance de la audiencia mucho más allá de la ventana de transmisión original.

Para las organizaciones que operan en sectores regulados —servicios financieros, salud, gobierno— proporcionar acceso equitativo a la información de audio en vivo es cada vez más una expectativa y no una cortesía. No cumplir este criterio puede exponer a las organizaciones a quejas, riesgos reputacionales y, en algunas jurisdicciones, responsabilidad legal.

Reglas relacionadas de Axe-core

WCAG 1.2.9 requiere pruebas manuales; ninguna regla automatizada de axe-core puede detectar de forma fiable si una transmisión de solo audio en vivo tiene una alternativa textual síncrona. Las razones de esta limitación son fundamentales para la naturaleza del criterio:

• Por qué la automatización no puede detectar esta infracción: Las herramientas automatizadas como axe-core operan sobre instantáneas estáticas del DOM o estados de la página en un momento dado. Pueden detectar la presencia de un elemento <audio> o de un reproductor multimedia, pero no pueden determinar si el contenido asociado es en vivo o pregrabado, si un área de texto visible en la página se está actualizando realmente en sincronía con una transmisión de audio, si el contenido textual es semánticamente equivalente al audio (cubriendo toda la información de audio hablada y no hablada), o si algún servicio de subtitulado externo vinculado está realmente activo y es preciso. Todos estos juicios requieren la revisión humana de la propia transmisión en vivo.
• Qué debe comprobar una persona auditora manual: La persona auditora debe acceder a la página mientras la transmisión de audio en vivo está activa, identificar cómo (o si) se presenta una alternativa textual, confirmar que la alternativa textual se actualiza en tiempo real a medida que avanza el audio, verificar que el texto cubre todo el contenido de audio significativo, incluida la identificación de las personas que hablan, los sonidos no verbales y las transiciones, y confirmar que la alternativa textual es accesible para las tecnologías de apoyo; por ejemplo, que una región en vivo que usa aria-live='polite' o aria-live='assertive' anuncia las actualizaciones a las personas usuarias de lectores de pantalla de forma adecuada.
• Señales de automatización parcial: Aunque axe-core no puede marcar directamente la ausencia de una alternativa textual en vivo, las personas auditoras deben tener en cuenta que axe-core sí marcará problemas relacionados que agravan el problema; por ejemplo, si existe un área de transcripción de texto pero está oculta con display:none, o si un reproductor multimedia carece de controles accesibles. Estas alertas sirven como puntos de partida útiles durante una revisión manual.

Cómo hacer las pruebas

1. Escaneo automatizado como línea base: Ejecuta axe DevTools o Lighthouse en la página que aloja la transmisión de audio en vivo. Toma nota de cualquier problema marcado con elementos multimedia, etiquetas faltantes o controles inaccesibles. Aunque ninguna de estas herramientas marcará directamente la ausencia de una alternativa textual en vivo, pueden sacar a la luz barreras relacionadas, como un reproductor de audio sin nombre accesible o un contenedor de transcripción que esté oculto del árbol de accesibilidad. Documenta estos hallazgos y trátalos como parte de la evaluación global de accesibilidad.
2. Identificar el contenido de audio en vivo: Mientras la transmisión en vivo está activa, confirma que la transmisión de audio es en vivo (no una grabación) y que no tiene pista de video. Revisa el código fuente de la página y las solicitudes de red en busca de pistas: las transmisiones en vivo suelen usar HLS (.m3u8), MPEG-DASH o entrega basada en WebSocket. Confirma que el contenido es solo de audio.
3. Comprobar la existencia de una alternativa textual: Busca un área de texto visible, una superposición de subtítulos o un flujo de transcripción claramente etiquetado en la página o vinculado inmediatamente desde la página. La alternativa debe estar claramente expuesta, no enterrada en un menú de configuración ni disponible solo a petición. Si no hay ninguna alternativa textual visible, el criterio falla de inmediato.
4. Verificar la sincronía: Con la alternativa textual en vivo visible, escucha la transmisión de audio y lee el flujo de texto simultáneamente. Confirma que el texto se actualiza con un retraso razonable (normalmente de unos pocos segundos como máximo para servicios CART o de subtitulado profesional). Un flujo de texto que se actualiza cada varios minutos o solo después de que finaliza la transmisión no satisface el criterio.
5. Verificar la equivalencia: Confirma que la alternativa textual captura todo el contenido de audio significativo: palabras habladas, identificación de las personas que hablan cuando hay varias voces, audio no verbal relevante (por ejemplo, «[aplausos]», «[suena una alarma]», «[suena música]») y cualquier anuncio o interrupción al aire.
6. Prueba con lector de pantalla — NVDA + Firefox: Abre la página con NVDA activo. Navega hasta la región de texto en vivo. Si la región usa aria-live, NVDA debería anunciar automáticamente las nuevas inserciones de texto. Si es un área de texto desplazable, verifica que se pueda colocar el foco en ella y que el contenido sea legible. Comprueba que los controles del reproductor de audio también se puedan operar con el teclado.
7. Prueba con lector de pantalla — VoiceOver + Safari (macOS/iOS): Activa VoiceOver y navega hasta la región de texto en vivo. Confirma que VoiceOver lea el nuevo texto a medida que aparece. En iOS, verifica también la experiencia en dispositivos móviles, ya que los eventos en vivo se acceden con frecuencia a través de navegadores móviles.
8. Prueba con lector de pantalla — JAWS + Chrome: Con JAWS activo, navega a la página y confirma que los anuncios de la región en vivo funcionen. JAWS maneja aria-live='polite' y aria-live='assertive' de forma diferente; confirma que el nivel de verbosidad sea apropiado para el tipo de contenido (un flujo de subtítulos de ritmo rápido puede adaptarse mejor a assertive para evitar retrasos en la cola).
9. Prueba en móvil y con poco ancho de banda: Si el sitio sirve a una audiencia móvil, prueba la alternativa textual en vivo en un dispositivo Android de gama media con una conexión limitada. Confirma que el flujo de texto se mantenga sincronizado y accesible incluso en condiciones restringidas.

Cómo corregirlo

Escenario 1: Reproductor de audio en vivo sin alternativa textual — Incorrecto

<!-- 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>

Escenario 1: Reproductor de audio en vivo con transcripción en región ARIA en vivo — Correcto

<!-- 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>

Escenario 2: Transcripción publicada solo después de que termina el evento — Incorrecto

<!-- 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>

Escenario 2: Flujo CART en tiempo real vinculado junto al reproductor — Correcto

<!-- 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>

Escenario 3: Subtítulos generados automáticamente ocultos tras un ajuste de configuración — Incorrecto

<!-- 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>

Escenario 3: Subtítulos activados por defecto con un control claro — Correcto

<!-- 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>

Errores comunes

• Publicar una transcripción posterior al evento y afirmar que satisface 1.2.9: Una transcripción publicada horas o días después de una transmisión en vivo no es una alternativa textual en tiempo real. WCAG 1.2.9 exige específicamente que la alternativa esté disponible de forma concurrente con el audio en vivo, no de forma retroactiva.
• Usar aria-live='polite' para un flujo de subtítulos de ritmo rápido: Las regiones en vivo «polite» esperan a que la persona usuaria termine de interactuar antes de anunciar contenido nuevo. Para subtítulos que se actualizan rápidamente, esto provoca que las personas usuarias de lectores de pantalla se pierdan anuncios. Usa aria-live='assertive' para flujos de subtítulos en vivo en los que cada actualización sea crítica en el tiempo.
• Inyectar todo el historial de subtítulos en cada actualización en lugar de solo el contenido nuevo: Cuando se establece aria-atomic='true' y se reemplaza todo el bloque de texto en cada actualización, los lectores de pantalla intentan volver a leer toda la región, lo que provoca una experiencia brusca. Usa aria-atomic='false' y añade nuevos nodos de texto para que solo se anuncie la parte nueva.
• Incrustar el flujo de subtítulos en un elemento <canvas> o como un gráfico superpuesto en el video: El texto de subtítulos representado como píxeles en un canvas o incrustado en un fotograma de video es invisible para las tecnologías de apoyo. Las alternativas textuales deben proporcionarse como nodos de texto reales en el DOM.
• Colocar la región de subtítulos en vivo fuera de la pantalla con position:absolute; left:-9999px: Aunque ocultar visualmente el contenido de esta forma lo mantiene en el árbol de accesibilidad, niega a las personas usuarias videntes con discapacidad auditiva la posibilidad de leer los subtítulos. La alternativa textual debe estar disponible visualmente para todas las personas usuarias, no solo para quienes usan lectores de pantalla.
• No identificar a las personas que hablan en transmisiones con múltiples interlocutores: Un flujo de subtítulos que transcribe el habla sin atribuirla a personas específicas (por ejemplo, «[Moderador]:», «[CEO]:», «[Miembro del público]:») no es totalmente equivalente. La identificación de las personas que hablan es esencial para que las personas usuarias sigan la estructura conversacional de un evento en vivo.
• Omitir información de audio no verbal en la alternativa textual: Sonidos relevantes como aplausos, interrupciones técnicas, música de fondo, alarmas o risas tienen contenido informativo y deben describirse en el flujo de texto (por ejemplo, «[aplausos]», «[problemas técnicos — audio interrumpido]»).
• Proporcionar la alternativa textual solo mediante una URL de un tercero sin incrustarla en la misma página: Exigir que las personas usuarias abran una pestaña o ventana de navegador separada para acceder a los subtítulos mientras el audio se reproduce en la página original crea una barrera de usabilidad significativa, especialmente para las personas usuarias de lectores de pantalla y quienes solo usan teclado, que deben cambiar de contexto.
• Suponer que los subtítulos generados automáticamente siempre cumplen el umbral de equivalencia: Los subtítulos generados por IA pueden tener tasas de error altas con habla con acento, vocabulario técnico, nombres propios y habla rápida. Implementar subtítulos generados automáticamente sin corrección para un evento en vivo de alto impacto (por ejemplo, una sesión informativa médica o una divulgación financiera) puede no cumplir el estándar de equivalencia, incluso si técnicamente existe un flujo de subtítulos.
• No probar la región de texto en vivo con lectores de pantalla reales durante una transmisión en vivo: Muchos equipos prueban el reproductor y el contenedor de subtítulos de forma aislada usando texto estático de ejemplo, pero nunca prueban el comportamiento dinámico durante una transmisión real. Errores en el JavaScript que inyecta las actualizaciones de subtítulos —como observadores de mutación del DOM que fallan silenciosamente— solo saldrán a la luz durante las pruebas en vivo.

Relación con la normativa de accesibilidad de Turquía

La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece obligaciones vinculantes de accesibilidad web para una amplia gama de organizaciones que operan en Turquía. La Circular exige la conformidad con WCAG 2.2 en el nivel AA como estándar de referencia. Los tipos de entidades cubiertas incluyen instituciones y organismos públicos, plataformas de comercio electrónico, bancos e instituciones financieras, hospitales y proveedores de salud privados, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes autorizadas, empresas de transporte privadas y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE).

WCAG 1.2.9 es un criterio de nivel AAA, lo que significa que no forma parte de los requisitos de conformidad exigidos por la Circular en el nivel AA. Las organizaciones cubiertas por la Circular Presidencial 2025/10 no están legalmente obligadas a implementar alternativas textuales para contenido de solo audio en vivo, a menos que se hayan comprometido por separado a la conformidad completa con WCAG 2.2 AAA.

Sin embargo, varias consideraciones prácticas hacen que 1.2.9 sea muy relevante para las organizaciones turcas incluso más allá del mínimo legal estricto. Los proveedores de telecomunicaciones, las instituciones financieras y los organismos de radiodifusión públicos ofrecen con frecuencia contenido de audio en vivo —llamadas con inversores, anuncios públicos, transmisiones de atención al cliente en vivo— del que dependen las personas sordas y con discapacidad auditiva en Turquía. Demostrar conformidad a nivel AAA señala un compromiso de accesibilidad de primer nivel y reduce significativamente el riesgo de quejas por discriminación en el marco más amplio de los derechos de las personas con discapacidad en Turquía, incluida la Ley sobre las Personas con Discapacidad n.º 5378 y su normativa de desarrollo.

Para las organizaciones que persiguen voluntariamente la conformidad con WCAG 2.2 AAA —ya sea para diferenciar su postura en materia de accesibilidad, para servir a mercados internacionales con requisitos más estrictos o para alinearse con criterios de contratación pública que exigen AAA— implementar correctamente 1.2.9 es esencial. Accsible recomienda que las organizaciones turcas en sectores regulados evalúen proactivamente su contenido de audio en vivo y valoren la viabilidad de integrar servicios CART o subtitulado en tiempo real de alta precisión, especialmente para eventos en vivo de cara al público en los que la equidad en el acceso a la información es una expectativa concreta de las partes interesadas.