Conformidade de Áudio WCAG 2.2 no WordPress: Guia 2026

O áudio no WordPress deve satisfazer ao menos quatro critérios de sucesso WCAG 2.2: 1.4.2 Controle de Áudio, 2.1.1 Teclado, 2.5.8 Tamanho do Alvo (novo na versão 2.2) e 4.1.2 Nome, Função, Valor. O Ato Europeu de Acessibilidade, em vigor desde 28 de junho de 2025, torna isso uma exigência legal para qualquer site que atenda clientes da UE. O player de áudio padrão do WordPress e a maioria dos plugins de áudio de terceiros não cumprem vários desses requisitos sem modificações.

Este guia é o checklist prático que usamos na Mementor ao auditar sites WordPress para conformidade com WCAG 2.2. Abordamos os dois lados da questão: áudio como conteúdo com suas próprias regras de acessibilidade, e áudio como recurso de acessibilidade para conteúdo em texto.

Por que a conformidade de áudio é importante em 2026

Três fatores se somaram em 2025 para tornar esse tema urgente. O AEA entrou em vigor em 28 de junho de 2025. O relatório WebAIM Million 2025 identificou falhas WCAG detectáveis em 96,3% das páginas iniciais analisadas. Os processos relacionados à ADA nos Estados Unidos continuaram crescendo, com sites WordPress aparecendo com destaque nos mais de 4.000 casos de acessibilidade web registrados ao longo do ano.

O padrão que observamos em nossas auditorias se repete. Os donos de sites presumem que o tema cuida da acessibilidade. O tema herda o que o plugin de áudio entrega. O plugin de áudio entrega botões pequenos demais, sliders que prendem usuários de teclado e relações de contraste que reprovam na primeira verificação manual.

O checklist completo de áudio WCAG 2.2

Oito critérios de sucesso afetam diretamente o áudio em um site WordPress. A tabela abaixo mostra o que cada um significa na prática, o que o player padrão do WordPress acerta ou erra, e como o player TTSWP lida com cada situação. Os critérios marcados com NOVO chegaram com o WCAG 2.2 em outubro de 2023.

A página Media Accessibility User Requirements do W3C é a fonte oficial desses critérios. O foco aqui está nesses oito porque se aplicam diretamente aos players de áudio. Legendas (1.2.2) e audiodescrição (1.2.3) também são relevantes, mas se aplicam a vídeo, não à narração de áudio puro.

A exceção de alternativa de mídia para texto

Aqui está a regra que 95% dos artigos sobre conformidade ignoram. O WCAG define alternativa de mídia para texto como mídia que não apresenta mais informação do que a já disponível em texto. Quando a narração por síntese de voz lê um artigo existente, o áudio é uma alternativa de mídia para o texto da página. O próprio texto da página é a transcrição.

Isso significa que uma versão em áudio de um artigo gerada por text to speech não precisa de um arquivo de transcrição separado. O WebAIM explica isso com clareza. A condição é que o áudio seja claramente identificado como alternativa de mídia, para que o usuário entenda que não está perdendo informação ao pulá-lo. Um título como "Ouça este artigo" ou um player rotulado como "Versão em áudio deste post" atende a esse requisito.

A exceção não se aplica se o áudio acrescenta comentários, trilhas sonoras com significado ou trechos ausentes no texto. Narração pura do conteúdo da página se enquadra na exceção. Usamos isso com frequência ao orientar clientes editores preocupados com novas obrigações de transcrição ao adicionar áudio.

O que mudou para áudio no WCAG 2.2

Três novos critérios de Nível AA afetam diretamente os players de áudio.

2.5.8 Tamanho do Alvo (Mínimo)

Todo controle interativo precisa de um alvo de pelo menos 24 por 24 pixels CSS. Esse é o critério que mais reprova plugins de áudio para WordPress. Nas auditorias que realizamos em sites com plugins de áudio de terceiros, os botões de avançar e retroceder consistentemente ficam abaixo do limite. Os designers priorizaram a compactação visual antes de o WCAG 2.2 estabelecer a regra dos 24 pixels, e poucos mantenedores de plugins se atualizaram. Os estilos padrão do tema às vezes reduzem ainda mais os alvos.

A correção normalmente envolve padding, não o tamanho do ícone. Um ícone SVG de 16 pixels dentro de um botão com 4 pixels de padding em cada lado atinge o limite de 24 pixels sem alterar a aparência visual.

2.4.11 Foco Não Obstruído

Barras de áudio fixas na parte inferior da página cobrem o elemento que está em foco para o usuário de teclado. Se um link em foco ficar atrás da barra, o critério é reprovado. A correção é tornar a barra dispensável, deixar espaço acima do elemento em foco ou usar scroll-padding-bottom no documento para manter os elementos focados visíveis.

2.5.7 Movimentos de Arrastar

Barras de progresso e sliders de volume que só funcionam com arrasto reprovam nesse critério. Toda interação por arrasto precisa de uma alternativa com um único ponteiro. Clicar para posicionar na barra de progresso resolve. O controle por teclas de seta em um elemento com role="slider" corretamente implementado também satisfaz o critério.

Falhas comuns em áudio no WordPress encontradas em auditorias reais

Os problemas se repetem entre os sites dos clientes. Quatro falhas aparecem com mais frequência.

O bloco <audio> nativo do WordPress renderiza o player do navegador. Os controles de áudio nativos têm um histórico longo de comportamento inconsistente com leitores de tela, e o controle por teclas de seta para mover a posição de reprodução varia entre Chrome, Firefox e Safari. Usuários de NVDA ou JAWS frequentemente ouvem os timestamps, mas não conseguem mover a posição de forma confiável pelo teclado. A correção é encapsular o áudio em um player personalizado que expõe role="slider" com os atributos de valor ARIA corretos.

Players de plugins entregam botões abaixo do limite de 24 pixels. O designer priorizou a compactação antes de o WCAG 2.2 estabelecer a regra. Os temas sobrescrevem os estilos do plugin, o que às vezes piora e às vezes melhora a situação.

Barras de áudio fixas ocultam o conteúdo em foco. Observamos essa falha em todos os sites que usam um player fixo no rodapé sem testar a navegação por teclado.

O contraste em formas de onda fica consistentemente abaixo de 4,5:1. Designers adoram a onda cinza suave sobre fundo branco. Leitores de tela não se importam, mas usuários com baixa visão sim, e o critério 1.4.3 é reprovado.

Construindo um player de áudio acessível: o checklist técnico

1. Envolva o player em role="region" com um aria-label descritivo.
2. Use um elemento <button> real para play, pause, skip e mute. Nunca use <div> com um handler de clique.
3. Defina aria-pressed no botão de play para expor o estado de alternância.
4. Dê a cada controle um alvo mínimo de 24 por 24 pixels CSS usando padding.
5. Implemente o scrubber e o volume como role="slider" com aria-valuemin, aria-valuemax e aria-valuenow, respondendo às teclas de seta.
6. Ofereça clique para posicionar no scrubber como alternativa ao arrasto.
7. Verifique o contraste em todos os elementos de texto e ícones significativos, com mínimo de 4,5:1.
8. Certifique-se de que os anéis de foco estão visíveis e nunca cortados por regras de overflow.
9. Se o player for fixo, deixe espaço de foco acima dele ou torne-o dispensável.
10. Identifique os players de narração por síntese de voz como "Versão em áudio deste artigo" para que a exceção de alternativa de mídia se aplique corretamente.

Um botão de play acessível mínimo tem esta estrutura.

<div role="region" aria-label="Article audio player">
  <button type="button"
          aria-pressed="false"
          aria-label="Play article narration"
          style="min-width:24px;min-height:24px;padding:8px">
    <svg aria-hidden="true" width="16" height="16">...</svg>
  </button>
  <input type="range"
         aria-label="Playback position"
         min="0" max="100" value="0">
</div>

Essa é a estrutura base. Estilize o botão, oculte os visuais nativos do range se quiser uma trilha personalizada, mas mantenha a semântica subjacente.

Como a narração por síntese de voz melhora a conformidade WCAG geral

O áudio não é apenas conteúdo que precisa ser acessível. Ele é um recurso de acessibilidade. A Organização Mundial da Saúde estima que 1,3 bilhão de pessoas, cerca de 16% da população mundial, vivem com alguma deficiência significativa. Muitas se beneficiam do acesso multimodal ao conteúdo em texto: pessoas com dislexia, TDAH, baixa visão e diversas deficiências cognitivas leem com mais conforto quando têm áudio junto ao texto.

Adicionar narração por síntese de voz é um dos poucos investimentos em acessibilidade que beneficia os usuários antes de satisfazer uma auditoria. Adicionar text to speech ao WordPress leva menos de 15 minutos com o plugin Text to Speech – TTSWP. O player já vem com padrões em conformidade com WCAG 2.1 AA, alvos de 24 pixels ou mais, suporte por teclado e funções ARIA corretas.

O payload mínimo em runtime é de aproximadamente 35 a 40 KB comprimido com gzip (151 KB sem minificação), cobrindo tanto a lógica JavaScript do player quanto o CSS compartilhado. Rodamos o GTmetrix em um artigo publicado com o player ativo e obtivemos Nota A com 93% de Performance, 99% de Structure, Largest Contentful Paint em 1,3 segundos, Total Blocking Time em 46 milissegundos e Cumulative Layout Shift zero. O bundle carrega de forma lazy apenas nas páginas que contêm o player, então páginas estáticas sem áudio não têm nenhum peso adicional.

A documentação de acessibilidade está em nossa página de confiança e acessibilidade. A narração usa o motor generativo da ElevenLabs, que melhora a prosódia o suficiente para que os leitores concluam os artigos em vez de abandonar uma leitura robótica.

O Ato Europeu de Acessibilidade na prática

O AEA entrou em vigor em 28 de junho de 2025. Novos serviços digitais colocados no mercado da UE após essa data já devem estar em conformidade. Os serviços existentes têm até 28 de junho de 2030 para se adequar completamente. A diretiva se aplica a qualquer empresa que atenda clientes da UE, independentemente de onde esteja sediada.

O padrão técnico referenciado pelo AEA é a EN 301 549. A versão harmonizada atual (V3.2.1, agosto de 2021) é baseada no WCAG 2.1 Nível AA. O rascunho V4.1.0 publicado em novembro de 2025 atualiza as cláusulas 9, 10 e 11 para alinhar com o WCAG 2.2, com harmonização final prevista para 2026. Até que essa atualização seja referenciada no Diário Oficial da UE, o WCAG 2.1 AA permanece como o mínimo legalmente vinculante, mas recomendamos já mirar no 2.2, pois a transição está a meses de distância, não a anos.

As penalidades variam por estado-membro. Alemanha e França têm a infraestrutura de fiscalização mais ativa, com autoridades nacionais de acessibilidade com poder para investigar reclamações e aplicar multas. Já vimos clientes alemães e de outros países receberem reclamações formais de usuários finais nos primeiros meses após a data de vigência, geralmente relacionadas a componentes de áudio e formulários. As reclamações chegam antes das multas, então uma janela de correção de trinta dias costuma ser viável para equipes preparadas.

Como testar a conformidade

Ferramentas automatizadas identificam cerca de 30 a 40% dos problemas. Os demais exigem testes manuais, especialmente interação por teclado e contraste significativo em estados dinâmicos.

• NVDA no Windows com Chrome e Firefox. Gratuito.
• JAWS no Windows para atender às expectativas de clientes corporativos.
• VoiceOver no macOS e iOS. Nativo.
• TalkBack no Android. Nativo.
• axe DevTools, extensão de navegador para varreduras automatizadas.
• Lighthouse no Chrome DevTools para verificações rápidas.
• Navegação apenas por teclado. Desconecte o mouse e opere todos os controles do player.

A navegação apenas por teclado é o teste com melhor custo-benefício. Se o player funcionar sem mouse, a maior parte do WCAG 2.2 já está atendida.

Perguntas frequentes

O WCAG 2.2 exige legendas para podcasts de áudio?

Não. Legendas (1.2.2) se aplicam a vídeos pré-gravados com áudio sincronizado. Para conteúdo somente em áudio, como podcasts, o critério relevante é o 1.2.1, que exige uma alternativa em texto, como transcrição ou resumo detalhado. Legendas e transcrições têm propósitos diferentes. Um podcast precisa de transcrição. Um tutorial em vídeo precisa de legendas e audiodescrição para informações presentes apenas visualmente.

Reprodução automática de áudio é proibida pelo AEA?

Não é proibida, mas é restringida. O critério WCAG 1.4.2 Controle de Áudio, referenciado pelo AEA via EN 301 549, exige que qualquer áudio reproduzido automaticamente por mais de três segundos ofereça controle de pausa, parada ou volume independente. Reprodução automática sem esse controle reprova no Nível A e gera uma constatação de não conformidade. A maioria dos órgãos de fiscalização trata isso como uma violação clara, não como caso limítrofe.

Preciso de transcrição se já tenho uma versão em áudio do meu artigo?

Em geral, não. Quando o áudio é uma narração direta do texto do artigo e não acrescenta nenhuma informação nova, o próprio texto do artigo é a transcrição, conforme a definição de "alternativa de mídia para texto" do WCAG. Identifique o player claramente como versão em áudio do artigo e a exceção se aplica. Se o áudio incluir comentários, música com significado ou trechos ausentes no texto, você precisa de uma transcrição separada.

Qual é o tamanho mínimo de botão para players de áudio no WCAG 2.2?

Os alvos interativos devem ter pelo menos 24 por 24 pixels CSS, conforme o critério de sucesso 2.5.8 Tamanho do Alvo (Mínimo) no Nível AA. O alvo inclui padding, então um ícone de 16 pixels com 4 pixels de padding em cada lado atende ao requisito. Existem exceções para links em linha no texto e controles determinados pelo agente de usuário, mas botões independentes de player não têm exceção e devem atingir o limite.

O WCAG 2.2 se aplica a sites hospedados no WordPress.com?

Sim. O WCAG se aplica a qualquer conteúdo web, independentemente da plataforma de hospedagem. Sites no WordPress.com têm a mesma exposição legal sob o AEA, a ADA e legislações nacionais equivalentes que sites WordPress auto-hospedados. O modelo de hospedagem não altera a obrigação. O que muda é o nível de controle que o dono do site tem sobre o markup do player. Os planos Business e Commerce do WordPress.com permitem plugins personalizados; os planos inferiores não.

Por onde começar

Escolha um post do seu site, faça uma navegação apenas por teclado no player de áudio e verifique cada botão contra a regra dos 24 pixels. Essa auditoria simples revela se sua configuração atual está próxima ou distante da conformidade com WCAG 2.2. A partir daí, a escolha é corrigir o player existente ou substituí-lo por um que já entrega conformidade por padrão. Nossa documentação de acessibilidade cobre a configuração que recomendamos para sites sob pressão do AEA.