WCAG 1.2.9: Som apenas (ao vivo)

O que Esta Regra Significa

O Critério de Sucesso 1.2.9 das WCAG, Somente áudio (ao vivo), está sob a Diretriz 1.2 (Mídia baseada em tempo) no Nível AAA. Ele afirma: "É fornecida uma alternativa para mídia baseada em tempo que apresente informações equivalentes para conteúdo somente de áudio ao vivo." Em termos práticos, isso significa que sempre que seu site ou aplicativo transmitir ou disponibilizar conteúdo de áudio ao vivo — e esse conteúdo não tiver componente de vídeo — os usuários devem receber um equivalente em texto em tempo real que transmita fielmente as mesmas informações.

Uma apresentação somente de áudio ao vivo é qualquer transmissão de áudio que seja veiculada em tempo real sem uma faixa de vídeo sincronizada. Exemplos comuns incluem programas de rádio ao vivo incorporados em uma página da web, comentários de áudio ao vivo durante um evento esportivo, coletivas de imprensa ao vivo transmitidas em formato de áudio, teleconferências de resultados ou apresentações para investidores ao vivo, e podcasts ou programas de debate em áudio ao vivo em que não há transmissão de vídeo acompanhando o áudio.

A alternativa em texto exigida por este critério deve ser equivalente — ou seja, deve capturar não apenas as palavras faladas, mas também informações relevantes de áudio não verbal, como barulho de multidão, alarmes, efeitos sonoros ou música que tenham valor informativo. Uma transcrição parcial ou atrasada não satisfaz este critério; a alternativa deve ser atualizada de forma síncrona (ou quase síncrona) com a transmissão ao vivo, para que pessoas surdas e com deficiência auditiva possam acompanhar o conteúdo em tempo real.

Técnicas aceitáveis para atender a este critério incluem fornecer um estenógrafo humano ao vivo produzindo texto em tempo real (CART — Communication Access Realtime Translation), incorporar legendas ao vivo sincronizadas geradas por um serviço de legendagem qualificado ou exibir um feed de texto ao vivo que seja executado simultaneamente com a transmissão de áudio. Legendas geradas automaticamente por software de reconhecimento de fala também podem satisfazer o critério, desde que a precisão seja suficientemente alta e a saída seja apresentada em tempo quase real.

O que conta como aprovação: A página fornece uma alternativa em texto visível e síncrona — claramente vinculada ou exibida ao lado do reprodutor de áudio — que apresenta informações equivalentes à transmissão de áudio ao vivo à medida que ela acontece. A alternativa deve ser perceptível para usuários que não conseguem ouvir o áudio.

O que conta como reprovação: Nenhuma alternativa em texto é oferecida; uma alternativa em texto é fornecida, mas com atraso significativo (por exemplo, uma transcrição publicada após o evento); uma alternativa em texto cobre apenas parte do áudio (por exemplo, apenas a fala do apresentador, mas não as perguntas do público); ou existe uma alternativa em texto, mas ela não é acessível a usuários de tecnologias assistivas (por exemplo, é renderizada como um elemento canvas não focável ou bloqueada dentro de um widget em Flash).

Exceções oficiais: As WCAG não estabelecem exceções específicas para 1.2.9 além do princípio geral de que o requisito se aplica apenas a conteúdo de áudio ao vivo e somente de áudio. Conteúdo de áudio pré-gravado é coberto pelo critério separado 1.2.1. Não há exceção para clipes de áudio curtos ou anúncios breves — se o conteúdo é ao vivo e somente de áudio, o critério se aplica.

Por Que Isso Importa

Aproximadamente 466 milhões de pessoas no mundo têm perda auditiva incapacitante, de acordo com a Organização Mundial da Saúde, e projeta-se que esse número ultrapasse 900 milhões até 2050. Para esses usuários, conteúdo somente de áudio ao vivo é totalmente inacessível sem um equivalente em texto. Diferentemente de conteúdo pré-gravado — em que uma transcrição pode ser preparada com antecedência e anexada posteriormente — o áudio ao vivo apresenta um desafio único porque a informação é sensível ao tempo e efêmera. Uma pessoa surda não pode simplesmente reproduzir uma transmissão ao vivo mais tarde e esperar a mesma experiência; por definição, o conteúdo ao vivo perde sua imediaticidade assim que o momento passa.

Considere um cenário concreto do mundo real: uma empresa de capital aberto realiza uma teleconferência de resultados ao vivo transmitida somente em áudio em sua página de relações com investidores. Analistas, jornalistas e investidores de varejo que são surdos ou têm deficiência auditiva não podem participar — ou sequer acompanhar passivamente — a chamada sem um feed de texto em tempo real. Divulgações financeiras importantes, atualizações de projeções e respostas a perguntas de analistas são comunicadas em tempo real, e qualquer atraso no recebimento dessas informações coloca esses usuários em significativa desvantagem informacional. Em setores regulados, isso pode até levantar questões sobre acesso equitativo à informação pública.

Além da surdez, este critério beneficia uma população mais ampla. Usuários com transtornos de processamento auditivo podem ouvir o áudio, mas ter dificuldade em decodificar a fala rapidamente o suficiente para acompanhar uma transmissão ao vivo; um feed de texto sincronizado permite que leiam no seu próprio ritmo de compreensão enquanto o áudio é reproduzido. Usuários em ambientes sensíveis a ruído — como escritórios abertos, bibliotecas ou transporte público — que não podem reproduzir áudio em voz alta se beneficiam de uma alternativa em texto. Usuários para os quais o idioma da transmissão é uma segunda língua também acham alternativas em texto mais fáceis de acompanhar do que fala ao vivo em ritmo acelerado.

Do ponto de vista de SEO e descoberta de conteúdo, uma transcrição de texto ao vivo ou um feed de legendas cria texto indexável que os mecanismos de busca podem rastrear. Eventos ao vivo que geram texto em tempo real têm mais probabilidade de aparecer em resultados de busca e agregadores de notícias, ampliando o alcance do público muito além da janela original da transmissão.

Para organizações que atuam em setores regulados — serviços financeiros, saúde, governo — fornecer acesso equitativo a informações de áudio ao vivo é cada vez mais uma expectativa, e não uma cortesia. Deixar de atender a este critério pode expor organizações a reclamações, risco reputacional e, em algumas jurisdições, responsabilidade legal.

Regras Relacionadas do Axe-core

WCAG 1.2.9 exige testes manuais; nenhuma regra automatizada do axe-core pode detectar de forma confiável se uma transmissão somente de áudio ao vivo possui uma alternativa em texto síncrona. As razões para essa limitação são fundamentais à natureza do critério:

• Por que a automação não consegue detectar essa violação: Ferramentas automatizadas como o axe-core operam em instantâneos estáticos do DOM ou estados de página em um único ponto no tempo. Elas podem detectar a presença de um elemento <audio> ou de um reprodutor de mídia, mas não conseguem determinar se o conteúdo associado é ao vivo ou pré-gravado, se uma área de texto visível na página está realmente sendo atualizada em sincronia com uma transmissão de áudio, se o conteúdo em texto é semanticamente equivalente ao áudio (cobrindo todas as informações de fala e de áudio não verbal) ou se algum serviço de legendagem externo vinculado está realmente ativo e preciso. Todos esses julgamentos exigem revisão humana da própria transmissão ao vivo.
• O que um auditor manual deve verificar: O auditor deve acessar a página enquanto a transmissão de áudio ao vivo estiver ativa, identificar como (ou se) uma alternativa em texto é apresentada, confirmar que a alternativa em texto é atualizada em tempo real à medida que o áudio avança, verificar se o texto cobre todo o conteúdo de áudio significativo, incluindo identificação de falantes, sons não verbais e transições, e confirmar que a alternativa em texto é acessível a tecnologias assistivas — por exemplo, que uma região ao vivo usando aria-live='polite' ou aria-live='assertive' está anunciando atualizações adequadamente para usuários de leitores de tela.
• Sinais de automação parcial: Embora o axe-core não possa sinalizar diretamente a ausência de uma alternativa em texto ao vivo, auditores devem observar que o axe-core vai sinalizar problemas relacionados que agravam o problema — por exemplo, se existir uma área de transcrição em texto, mas ela estiver oculta com display:none, ou se um reprodutor de mídia não tiver controles acessíveis. Esses alertas servem como pontos de partida úteis durante uma revisão manual.

Como Testar

1. Varredura automatizada como linha de base: Execute o axe DevTools ou o Lighthouse na página que hospeda a transmissão de áudio ao vivo. Observe quaisquer problemas sinalizados com elementos de mídia, rótulos ausentes ou controles inacessíveis. Embora nenhuma das ferramentas sinalize diretamente a ausência de uma alternativa em texto ao vivo, elas podem revelar barreiras relacionadas — como um reprodutor de áudio sem nome acessível ou um contêiner de transcrição oculto da árvore de acessibilidade. Documente essas constatações e trate-as como parte da avaliação geral de acessibilidade.
2. Identifique o conteúdo de áudio ao vivo: Enquanto a transmissão ao vivo estiver ativa, confirme que o fluxo de áudio é ao vivo (não uma gravação) e que não possui faixa de vídeo. Verifique o código-fonte da página e as requisições de rede em busca de pistas — transmissões ao vivo normalmente usam HLS (.m3u8), MPEG-DASH ou entrega baseada em WebSocket. Confirme que o conteúdo é somente de áudio.
3. Verifique se há uma alternativa em texto: Procure uma área de texto visível, sobreposição de legendas ou feed de transcrição claramente rotulado na página ou imediatamente vinculado a partir da página. A alternativa deve ser apresentada de forma proeminente — não escondida em um menu de configurações ou disponível apenas sob solicitação. Se nenhuma alternativa em texto estiver visível, o critério falha imediatamente.
4. Verifique a sincronia: Com a alternativa em texto visível, ouça a transmissão de áudio e leia o feed de texto simultaneamente. Confirme que as atualizações de texto ocorrem com atraso razoável (tipicamente não mais que alguns segundos para serviços CART ou de legendagem profissional). Um feed de texto que é atualizado a cada vários minutos ou apenas após o término da transmissão não satisfaz o critério.
5. Verifique a equivalência: Confirme que a alternativa em texto captura todo o conteúdo de áudio significativo: palavras faladas, identificação de falantes quando houver múltiplas vozes, áudio não verbal relevante (por exemplo, "[aplausos]", "[som de alarme]", "[música tocando]") e quaisquer anúncios ou interrupções no ar.
6. Teste com leitor de tela — NVDA + Firefox: Abra a página com o NVDA ativo. Navegue até a região de texto ao vivo. Se a região usar aria-live, o NVDA deve anunciar automaticamente novas inserções de texto. Se for uma área de texto rolável, verifique se é possível colocar o foco nela e se o conteúdo é legível. Verifique se os controles do reprodutor de áudio também são operáveis por teclado.
7. Teste com leitor de tela — VoiceOver + Safari (macOS/iOS): Ative o VoiceOver e navegue até a região de texto ao vivo. Confirme que o VoiceOver lê o novo texto à medida que aparece. No iOS, verifique também a experiência em dispositivos móveis — eventos ao vivo são frequentemente acessados por navegadores móveis.
8. Teste com leitor de tela — JAWS + Chrome: Com o JAWS ativo, navegue até a página e confirme que os anúncios da região ao vivo estão funcionando. O JAWS trata aria-live='polite' e aria-live='assertive' de forma diferente; confirme que a configuração de verbosidade é apropriada para o tipo de conteúdo (um feed de legendas de atualização rápida pode ser mais adequado a assertive para evitar atrasos na fila de anúncios).
9. Teste em dispositivos móveis e com baixa largura de banda: Se o site atende a um público móvel, teste a alternativa em texto ao vivo em um dispositivo Android intermediário com conexão limitada. Confirme que o feed de texto permanece sincronizado e acessível mesmo em condições restritas.

Como Corrigir

Cenário 1: Reprodutor de áudio ao vivo sem alternativa em texto — Incorreto

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

Cenário 1: Reprodutor de áudio ao vivo com transcrição em região ARIA ao vivo — Correto

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

Cenário 2: Transcrição publicada apenas após o fim do evento — Incorreto

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

Cenário 2: Feed CART em tempo real vinculado ao lado do reprodutor — Correto

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

Cenário 3: Legendas geradas automaticamente escondidas atrás de uma opção de configurações — Incorreto

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

Cenário 3: Legendas ativadas por padrão com um controle claro — Correto

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

Erros Comuns

• Publicar uma transcrição após o evento e alegar que isso satisfaz 1.2.9: Uma transcrição publicada horas ou dias após uma transmissão ao vivo não é uma alternativa em texto em tempo real. A WCAG 1.2.9 exige especificamente que a alternativa esteja disponível simultaneamente ao áudio ao vivo, não retroativamente.
• Usar aria-live='polite' para um feed de legendas de atualização rápida: Regiões ao vivo com nível "polite" aguardam o usuário terminar de interagir antes de anunciar novo conteúdo. Para legendas que se atualizam rapidamente, isso faz com que usuários de leitores de tela percam anúncios. Use aria-live='assertive' para fluxos de legendas ao vivo em que cada atualização é crítica em termos de tempo.
• Injetar todo o histórico de legendas a cada atualização em vez de apenas o conteúdo novo: Quando aria-atomic='true' está definido e todo o bloco de texto é substituído a cada atualização, leitores de tela tentam reler toda a região, causando uma experiência desconfortável. Use aria-atomic='false' e acrescente novos nós de texto para que apenas a parte nova seja anunciada.
• Incorporar o feed de legendas em um elemento <canvas> ou como um gráfico sobreposto ao vídeo: Texto de legendas renderizado como pixels em um canvas ou embutido em um quadro de vídeo é invisível para tecnologias assistivas. Alternativas em texto devem ser fornecidas como nós de texto reais no DOM.
• Colocar a região de legendas ao vivo fora da tela com position:absolute; left:-9999px: Embora ocultar visualmente o conteúdo dessa forma o mantenha na árvore de acessibilidade, isso impede que usuários videntes com deficiência auditiva leiam as legendas. A alternativa em texto deve estar visualmente disponível para todos os usuários, não apenas para usuários de leitores de tela.
• Deixar de identificar falantes em transmissões com múltiplos participantes: Um feed de legendas que transcreve a fala sem atribuí-la a falantes específicos (por exemplo, "[Moderador]:", "[CEO]:", "[Membro da plateia]:") não é totalmente equivalente. A identificação de falantes é essencial para que usuários acompanhem a estrutura conversacional de um evento ao vivo.
• Omitir informações de áudio não verbal da alternativa em texto: Sons relevantes como aplausos, interrupções técnicas, música de fundo, alarmes ou risadas têm conteúdo informativo e devem ser descritos no feed de texto (por exemplo, "[aplausos]", "[problemas técnicos — áudio interrompido]").
• Fornecer a alternativa em texto apenas por meio de uma URL de terceiro separada, sem incorporá-la na mesma página: Exigir que usuários abram uma aba ou janela de navegador separada para acessar legendas enquanto o áudio é reproduzido na página original cria uma barreira significativa de usabilidade, especialmente para usuários de leitores de tela e usuários que dependem apenas do teclado, que precisam alternar de contexto.
• Presumir que legendas geradas automaticamente sempre atendem ao limiar de equivalência: Legendas geradas por IA podem ter altas taxas de erro com fala com sotaque, vocabulário técnico, nomes próprios e fala rápida. Implementar legendas automáticas não revisadas em um evento ao vivo de alta relevância (por exemplo, um informe médico ou divulgação financeira) pode não atender ao padrão de equivalência, mesmo que tecnicamente exista um feed de legendas.
• Não testar a região de texto ao vivo com leitores de tela reais durante uma transmissão ao vivo: Muitas equipes testam o reprodutor e o contêiner de legendas isoladamente usando texto estático de exemplo, mas nunca testam o comportamento dinâmico durante uma transmissão real. Erros no JavaScript que injeta atualizações de legendas — como observadores de mutação do DOM que falham silenciosamente — só aparecerão durante testes ao vivo.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece obrigações vinculantes de acessibilidade na web para uma ampla gama de organizações que atuam na Turquia. A Circular determina a conformidade com as WCAG 2.2 no nível AA como padrão básico. Os tipos de entidades abrangidas incluem instituições e órgãos públicos, plataformas de comércio eletrônico, bancos e instituições financeiras, hospitais e prestadores privados de serviços de saúde, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagens licenciadas, empresas de transporte privadas e escolas particulares autorizadas pelo Ministério da Educação Nacional (MoNE).

WCAG 1.2.9 é um critério de Nível AAA, o que significa que não está entre os requisitos de conformidade exigidos pela Circular no padrão AA. Organizações abrangidas pela Circular Presidencial 2025/10 não são legalmente obrigadas a implementar alternativas em texto para áudio ao vivo e somente de áudio, a menos que tenham se comprometido separadamente com a conformidade total com as WCAG 2.2 no nível AAA.

No entanto, várias considerações práticas tornam 1.2.9 altamente relevante para organizações turcas, mesmo além do mínimo legal estrito. Provedores de telecomunicações, instituições financeiras e emissoras públicas frequentemente veiculam conteúdo de áudio ao vivo — teleconferências com investidores, anúncios públicos, transmissões de atendimento ao cliente ao vivo — dos quais pessoas surdas e com deficiência auditiva na Turquia dependem. Demonstrar conformidade em nível AAA sinaliza um compromisso de acessibilidade de excelência e reduz significativamente o risco de reclamações por discriminação no âmbito do mais amplo arcabouço de direitos das pessoas com deficiência na Turquia, incluindo a Lei sobre Pessoas com Deficiência nº 5378 e seus regulamentos de implementação.

Para organizações que buscam voluntariamente a conformidade com as WCAG 2.2 no nível AAA — seja para diferenciar sua postura em acessibilidade, para atender a mercados internacionais com requisitos mais rigorosos ou para se alinhar a critérios de contratação pública que exijam AAA — implementar corretamente o 1.2.9 é essencial. A Accsible recomenda que organizações turcas em setores regulados avaliem proativamente seu conteúdo de áudio ao vivo e analisem a viabilidade de integrar serviços CART ou legendagem em tempo real de alta precisão, especialmente para eventos ao vivo voltados ao público em que a equidade de acesso à informação é uma expectativa concreta das partes interessadas.