Acessibilidade web: como aplicar 3 padrões para usuários surdos

vi a notícia no Abril.com.br sobre o filme “90 Decibéis” — que estreia na TV Globo dia 28 de setembro com cerca de 70% do elenco formado por pessoas com deficiência — meu primeiro pensamento não foi cinematográfico. Foi técnico.

Trabalho com web há mais de uma década e, na minha experiência, a maioria dos devs ainda trata acessibilidade como afterthought. Algo que “a gente resolve depois”. Mas o capacitismo que Benedita Casé Zerbini e Pedro Neschling vão expor na tela é o mesmo que usuários surdos enfrentam todo dia em aplicações mal construídas. Sites sem legendas. Players de vídeo sem controle decente. Interfaces que dependem exclusivamente de feedback sonoro. A ficção vira espelho do código que entregamos.

O filme que vira espelho da indústria tech

Segundo o Abril.com.br, 90 Decibéis tem roteiro de Julia Spadaccini, direção de Fellipe Barbosa e estreia dia 28 de setembro na TV Globo. Benedita interpreta Ana, advogada que descobre que sua perda auditiva vai evoluir até surdez profunda. Pedro Neschling faz Leonardo, um colega que evidencia o capacitismo no ambiente de trabalho.

A história da personagem se mistura com a da própria atriz: Benedita é surda oralizada e estreou como atriz justamente neste papel. Pedro tem perda auditiva de moderada a severa e usa aparelhos auditivos. Não é elenco de conveniência — é vivência real em cena.

Para nós, devs, o ponto crítico é simples: a “exposição” do capacitismo que o filme propõe é literalmente o que entregamos (ou deixamos de entregar) em produtos digitais. A sala de reunião do longa poderia muito bem ser a reunião de planning do seu time.

Por que dev sênior deveria se importar com surdez na web

WCAG 2.2 lista “1.2 Time-based Media” como critério de sucesso nível A e AA. Ou seja: legendagem não é nice-to-have, é requisito mínimo. Sites que ignoram isso estão fora de conformidade legal em vários países — incluindo o Brasil, via Lei Brasileira de Inclusão (Lei 13.146/2015).

Mas vou além do legal. Quando uso acessibilidade de verdade em produção, percebo três efeitos colaterais que todo dev sênior deveria valorizar:

• Código semântico gera menos bug. Hierarquia clara de headings, roles explícitos e landmarks reduzem ambiguidade no DOM.
• Componentes acessíveis envelhecem melhor. O que funciona com teclado, leitor de tela e voz raramente quebra quando o framework muda.
• SEO e acessibilidade andam juntos. Google indexa legendas, descrições, textos alternativos e transcripts. Já vi tráfego orgânico dobrar só com transcrição de podcast.

A frase da própria Benedita no Abril.com.br resume tudo: “Não teria como a vida ter sido mais generosa comigo em me dar uma oportunidade tão incrível, que passa pelas minhas vivências”. Esse mesmo cuidado deveria existir na forma como construímos software.

Na Prática: três padrões que aplico em projetos reais

Vou mostrar o que cai em produção. Não é teoria — é o que está rodando em código que mantenho.

1. Legendas sincronizadas com track element

<video controls aria-describedby="desc-video-1">
 <source src="conteudo.mp4" type="video/mp4">
 <track
 kind="captions"
 src="legendas-pt.vtt"
 srclang="pt-BR"
 label="Português (Brasil)"
 default
 >
 <track
 kind="descriptions"
 src="descricao-audio.vtt"
 srclang="pt-BR"
 label="Descrição de áudio"
 >
</video>
<p id="desc-video-1">
 Tutorial de deploy em Kubernetes com legendas em português.
</p>

Esse é o básico que muita gente erra. Duas faixas: captions para legendagem tradicional e descriptions para audiodescrição. O aria-describedby dá contexto extra ao leitor de tela — fundamental para quem chega na página sem áudio.

2. Transcripts inline para podcasts e áudios

<article aria-labelledby="podcast-title">
 <h3 id="podcast-title">Episódio 42: microsserviços em produção</h3>
 <audio controls>
 <source src="ep42.mp3" type="audio/mpeg">
 </audio>
 <details>
 <summary>Transcrição completa</summary>
 <div class="transcript">
 <p>[00:00] Bem-vindo ao episódio 42...</p>
 <p>[00:15] Hoje vamos falar sobre...</p>
 </div>
 </details>
</article>

O <details> é subestimado. Usuário surdo abre a transcrição quando quiser, sem poluir a UI. Indexa no Google, funciona sem JavaScript e ainda usa o mínimo de markup. Quando testo isso em produção, vejo retenção maior do que em players “bonitos” sem transcrição.

3. Feedback visual + ARIA live dependência de áudio

// Substituindo alert() por toast acessível
function notify(message, type = 'info') {
 const toast = document.createElement('div');
 toast.setAttribute('role', 'status');
 toast.setAttribute('aria-live', 'polite');
 toast.className = `toast toast--${type}`;
 toast.textContent = message;
 document.body.appendChild(toast);

 setTimeout(() => {
 toast.setAttribute('aria-live', 'off');
 toast.remove();
 }, 5000);
}

// Cuidado: nunca dependa só de som
// Errado: usuário surdo nunca sabe que salvou
function notifyAudioOnly() {
 new Audio('notification.mp3').play();
}

// Certo: som + visual + anúncio por leitor de tela
function notifyAccessible() {
 notify('Arquivo salvo com sucesso', 'success');
 new Audio('notification.mp3').play();
}

aria-live="polite" faz o leitor de tela anunciar a mensagem sem interromper o que o usuário está fazendo. É a diferença entre um app que avisa e um app que ignora metade dos usuários. Detalhe importante: a região live precisa existir no DOM antes da mudança — inserir dinamicamente pode falhar em alguns leitores.

Erros comuns que vejo em code review

Depois de revisar centenas de PRs, posso listar os deslizes mais frequentes que ignoram diretamente a experiência de usuários surdos:

• Autoplay sem controle. Vídeo começa sozinho, sem legendas, sem botão de pause visível. Usuário surdo fica preso sem contexto do que está sendo dito.
• Ícones sem label. <i class="fas fa-bell"></i> sem aria-label. Leitor de tela fala “bell” e pronto — sem ação associada.
• Player custom em canvas/SVG. Refazemos tudo do zero em frameworks visuais e esquecemos dos atalhos de teclado e da navegação por foco.
• Legendas como imagem queimada. Você sabe, aquele vídeo onde a legenda está hardcoded no MP4. Impossível traduzir, impossível desligar, impossível ler por leitor de tela.
• Confiança excessiva em cor. “Erro em vermelho” — e o usuário daltônico? E o usuário surdo que não ouve o bip de erro do sistema? O alerta precisa ser multimodal.

Ferramentas que não saem do meu setup

Essas são as que rodam em todo projeto que assumo:

axe-core rodando no CI é não-negociável. Bloqueia merge quando há violação grave. Mais barato que lawsuit e melhor que retrabalho. Testei isso em três empresas diferentes e o padrão se repete: o número de issues abertas cai drasticamente depois que o CI começa a barrar PR.

O capacitismo que o filme expõe — e que o código reproduz

A história da Ana no filme é o tipo de narrativa que faltava na TV aberta. Não é “superando a deficiência” no sentido capacitista. É mostrar o capacitismo ao redor — o colega arrogante, o ambiente que ignora, as barreiras que surgem justamente quando ela precisa reconstruir identidade.

Quando um site obriga o usuário a ligar o som para autenticar com CAPTCHA sonoro, está reproduzindo a mesma exclusão que o Leonardo do filme pratica no escritório. A solução técnica existe: CAPTCHA visual, biometria, tokens, magic links. O que falta é prioridade. O filme estreia dia 28 de setembro e eu recomendo assistir — não só pela história, mas pelo exercício de ver o próprio produto pelos olhos de quem foi sistematicamente ignorado pela indústria.

FAQ — perguntas que devs realmente fazem

Legendagem automática (auto-generated captions) é suficiente?

Não. Softwares como YouTube Auto-Caption erram nomes próprios, termos técnicos, sotaques e homônimos. Para produto sério, transcreva manualmente ou revise com profissional. Legenda errada é pior que ausência de legenda — quebra confiança e ainda expõe o usuário a informação distorcida.

WCAG AA ou AAA?

AA é o padrão legal em quase todo lugar e resolve 95% dos casos. AAA é aspiracional — inclui critérios como legendagem por língua de sinais, que vai além do texto. Mire em AA por padrão e em AAA onde houver verba e contexto específico (governo, educação, saúde).

Por que me preocupar se só uma fatia pequena dos usuários é surda?

Porque não são só surdos. Legendagem ajuda quem está em ambiente barulhento, em reunião sem fone, em país com idioma diferente, com áudio quebrado no celular. Audição em ambiente silencioso é privilégio — código bom atende a todos os cenários. Além disso, transcripts e captions melhoram SEO e tempo de permanência.

aria-live não funciona no meu projeto. O que faço?

Verifique se o elemento está no DOM quando a região live é anunciada. Regiões live precisam existir antes da mudança de conteúdo. Se você insere dinamicamente via JS e tenta anunciar de imediato, alguns leitores ignoram. Solução: ter a região oculta no HTML inicial e popular via JavaScript.

Vale a pena usar biblioteca tipo React Aria ou Headless UI?

Sim, mas não como muleta. React Aria, Headless UI e Radix resolvem uns 80% dos padrões com qualidade. Os outros 20% exigem entender WCAG de verdade e testar com usuário real. Biblioteca sem teste manual é teatro de acessibilidade — parece bom no Lighthouse, falha na vida real.

Se quiser se aprofundar no tema, publiquei uma série sobre acessibilidade avançada no yurideveloper.com.br — tem exemplos em React, Vue e vanilla JS.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.