A norma brasileira de acessibilidade web é a ABNT NBR 17225:2025, de 11/03/2025. Ela traduz o WCAG 2.2 e tem 146 itens: 96 requisitos e 50 recomendações. Atender a todos os requisitos é a conformidade regular (Nível AA). Norma não é lei: a obrigação vem da LBI, art. 63.
O responsável pelo site descobre que precisa "ser acessível" e cai em uma de duas armadilhas. Na primeira, contrata um widget — aquele botão flutuante de contraste, fonte e Libras — e considera o assunto encerrado. Na segunda, vai atrás da regra e encontra só discussão jurídica: a lei manda seguir "as melhores práticas adotadas internacionalmente", e ninguém diz quais são, item por item.
Desde 11 de março de 2025 a lista existe. A ABNT publicou a NBR 17225:2025 — "Acessibilidade em conteúdo e aplicações web — Requisitos" (primeira edição, 69 páginas, © ABNT 2025), que traduz os critérios de sucesso do WCAG 2.2 para o português e separa, um a um, o que é requisito do que é recomendação. Quem opera site com áudio e vídeo — emissora, portal, web rádio, web TV, EAD — tem ali quatro ou cinco requisitos que o site médio brasileiro descumpre no primeiro segundo de carregamento.
Como este artigo foi apurado. Todas as citações, classificações e critérios abaixo foram lidos no texto integral da norma, na edição de lançamento publicada em PDF pelo Portal da Câmara dos Deputados (consultado em 27/09/2026). A norma também é listada e referenciada na página Acessibilidade Digital, do Governo Digital, ao lado do eMAG e da NBR 17060. O documento é protegido por direito autoral — aqui há citações curtas identificadas pelo número do item, nunca a norma reproduzida.
"Nova lei" não é lei — e a diferença muda o seu argumento
Quem pesquisa o assunto encontra, no topo dos resultados, manchetes de março de 2025 dizendo que uma "nova lei" tornou a acessibilidade obrigatória nos sites. Não houve lei nova. O que houve foi a publicação de uma norma técnica — e norma técnica da ABNT não é lei, não cria obrigação por conta própria e não "regulamenta" a legislação.
A obrigação já existia, e vem da Lei Brasileira de Inclusão (Lei 13.146/2015). O art. 63 determina que os sites mantidos por empresas com sede ou representação comercial no país sejam acessíveis, "observadas as melhores práticas e diretrizes de acessibilidade adotadas internacionalmente". É uma remissão aberta: a lei aponta para um padrão que ela não escreve.
É exatamente esse vazio que a norma preenche. O escopo da NBR 17225 diz, com todas as letras:
"Esta Norma estabelece os requisitos de acessibilidade para websites baseados nas Diretrizes Internacionais de Acessibilidade Web. A conformidade com esta norma visa atender à legislação vigente."
E a nota seguinte, no mesmo trecho, nomeia quais são essas diretrizes: as "Diretrizes de Acessibilidade para Conteúdo Web 2.2 (WCAG 2.2), mantidas pelo consórcio internacional World Wide Web (W3C)".
Junte as duas pontas e você tem o argumento que serve numa reunião, num edital ou numa notificação: a obrigação é da lei; a norma é a régua técnica reconhecida — inclusive pela Secretaria de Governo Digital — para demonstrar que a obrigação foi cumprida. Dizer "a NBR 17225 é obrigatória" está errado. Dizer "eu preciso provar que segui as melhores práticas internacionais, e a NBR 17225 é a tradução brasileira delas" está certo, e é mais difícil de contestar.
Como a norma é organizada: requisito, recomendação e a regra do "ou"
A Seção 4 da norma define dois tipos de conformidade, e vale ler as duas definições na íntegra porque elas decidem o que você precisa entregar:
"Conformidade regular: é atingida com o atendimento de todos os itens estabelecidos como requisitos. A conformidade regular está alinhada com o Nível de conformidade AA do WCAG 2.2, de forma que um site em conformidade regular com esta Norma está também em conformidade com os Níveis A e AA do WCAG 2.2, nível mínimo exigido (semelhantemente ao adotado internacionalmente)."
"Conformidade plena: abrange todos os requisitos e também as recomendações. Caso uma ou mais recomendações não sejam atendidas, é necessária uma justificativa razoável."
Duas consequências práticas passam batido em quase toda leitura apressada.
A primeira: a própria norma avisa que ela não esgota o assunto — "atender aos requisitos e às recomendações desta Norma não isenta o desenvolvedor de implementar outras boas práticas não abrangidas por esta Norma, como princípios de usabilidade, entre outras".
A segunda é a regra do "ou", e é ela que evita que você gaste dinheiro à toa. Vários itens admitem mais de uma forma de cumprimento, separadas pelo conectivo "ou" — e a ordem importa:
"A ordem em que as proposições são posicionadas implica uma preferência, de forma que as primeiras são mais indicadas do que as seguintes, que devem ser interpretadas como alternativas para exceções (fallbacks)."
Traduzindo para a sua página: quando um item oferece duas saídas, a primeira é a recomendada e a segunda é o plano B legítimo. Você pode ficar com o plano B — desde que saiba que é plano B.
Os 16 grupos da Seção 5
Contamos os itens da Seção 5 um a um: são 146 itens — 96 requisitos e 50 recomendações —, distribuídos em 16 grupos:
| Grupo | Tema | Grupo | Tema |
|---|---|---|---|
| 5.1 | Interação por teclado | 5.9 | Formulários e entrada de dados |
| 5.2 | Imagens | 5.10 | Apresentação |
| 5.3 | Cabeçalhos | 5.11 | Uso de cores |
| 5.4 | Regiões | 5.12 | Conteúdo textual |
| 5.5 | Listas | 5.13 | Codificação e marcação semântica |
| 5.6 | Tabelas | 5.14 | Áudio e vídeo |
| 5.7 | Links e navegação | 5.15 | Animação |
| 5.8 | Botões e controles | 5.16 | Tempo |
A contagem 146/96/50 é apuração desta página, feita sobre o texto da norma em 27/09/2026 — e ela não é exclusiva: o resumo gerado pelo Google para esse tema já publica a mesma quebra. O que segue abaixo, esse sim, não encontramos pronto em lugar nenhum.
Seção 5.14 — Áudio e vídeo, item por item
Este é o grupo que decide a vida de quem transmite. São dez itens; a coluna da direita é o critério de sucesso do WCAG 2.2 que a norma referencia, com o nível de conformidade.
| Item | O que diz (resumo da norma) | Classificação | C.S. / Nível |
|---|---|---|---|
| 5.14.1 Alternativa em texto para áudio | todo áudio pré-gravado tem alternativa em texto que transcreve todo o conteúdo; ou o áudio é alternativa a um vídeo sem áudio ou texto equivalente e está claramente identificado | Requisito | 1.2.1 (A) |
| 5.14.2 Legendas descritivas para vídeo | "Todo vídeo com áudio pré-gravado tem legendas descritivas disponíveis e equivalentes ao conteúdo do áudio"; ou o vídeo é alternativa a um texto equivalente e está claramente identificado | Requisito | 1.2.2 (A) |
| 5.14.3 Transcrição para vídeo | "Todo conteúdo em vídeo pré-gravado tem uma alternativa em texto que transcreve todo o seu conteúdo, visual e sonoro." | Recomendação | 1.2.1 (A) · 1.2.3 (A) · 1.2.8 (AAA) |
| 5.14.4 Audiodescrição para vídeo | "Todos os vídeos pré-gravados têm audiodescrição para todo o conteúdo visual; ou o áudio original é suficiente para a compreensão do conteúdo do vídeo sem o uso da visão." | Requisito | 1.2.1 (A) · 1.2.3 (A) · 1.2.5 (AA) |
| 5.14.5 Audiodescrição estendida | vídeo cujas pausas não sejam suficientes para a audiodescrição tem uma versão com audiodescrição estendida | Recomendação | 1.2.3 (A) · 1.2.5 (AA) · 1.2.7 (AAA) |
| 5.14.6 Janela de Libras para conteúdo em áudio | "Janela de Libras está disponível em todo o conteúdo de áudio pré-gravado em mídia sincronizada." | Recomendação | 1.2.6 (AAA) |
| 5.14.7 Controle de áudio | "Não há áudio que toque automaticamente e dure mais que 3 s; ou existe um mecanismo para pausar, parar, silenciar ou ajustar o seu volume sem afetar o volume geral do sistema." | Requisito | 1.4.2 (A) |
| 5.14.8 Áudio sem ruído | não há sons de fundo no conteúdo em áudio — ou há mecanismo para desligá-los, ou eles não interferem no som principal | Recomendação | 1.4.7 (AAA) |
| 5.14.9 Legendas para áudio e vídeo ao vivo | "Todo conteúdo em áudio ou áudio e vídeo ao vivo tem legendas disponíveis." | Requisito | 1.2.4 (AA) |
| 5.14.10 Transcrição para áudio ao vivo | "Existe uma transcrição para todo o conteúdo em áudio ao vivo." | Recomendação | 1.2.9 (AAA) |
Quatro leituras saem dessa tabela, e elas valem mais do que a tabela em si.
1. Legenda ao vivo saiu do "bom senso" e entrou na coluna de requisito. O item 5.14.9 é requisito, ancorado em critério de Nível AA — portanto dentro da conformidade regular, o patamar de entrada. Isso não transforma legenda ao vivo em obrigação legal para qualquer live na internet: os dispositivos que tratam de legendagem obrigatória (art. 67 da LBI e art. 19 da Lei 10.098) falam de radiodifusão. O que muda é o argumento técnico — quem precisa demonstrar conformidade com a norma brasileira não fecha a conta com a live sem legenda.
2. Transcrição não substitui legenda. Legenda é requisito (5.14.2 e 5.14.9); transcrição é recomendação (5.14.3 e 5.14.10). Escrevemos isso mesmo vendendo transcrição ao vivo: para efeito de conformidade regular, transcrição é o andar de cima, não o atalho.
3. Audiodescrição é requisito — com uma válvula literal. O 5.14.4 admite "ou o áudio original é suficiente para a compreensão do conteúdo do vídeo sem o uso da visão". Para quem publica podcast filmado, sessão de plenário ou entrevista de estúdio, essa segunda proposição costuma ser o caminho honesto. Lembre da regra do "ou": ela é o fallback, não a preferência — e cabe a você conseguir sustentar que o áudio original basta.
4. Janela de Libras é recomendação de Nível AAA (5.14.6), e só para áudio pré-gravado em mídia sincronizada. Ou seja: o avatar de Libras no canto da tela não é o item que falta para o seu site ser conforme.
O atalho "recomendação = AAA" quebra — e nós contamos onde
Existe uma simplificação circulando — inclusive nos resumos gerados por IA sobre esta norma — que diz assim: 96 requisitos equivalentes aos níveis A e AA, 50 recomendações equivalentes ao nível AAA. A primeira metade da frase tem origem no próprio texto da norma. A Seção 4 abre com:
"Esta Norma está dividida em requisitos e recomendações, sendo que os requisitos são considerados para os Níveis de conformidade A e AA. O Nível de conformidade AAA, que abrange boas práticas, requisitos mais rígidos e itens que não podem ser exigidos em todos os contextos, está sinalizado como recomendação."
É uma regra de bolso da própria ABNT, e serve para explicar por que um item vira recomendação. O problema é usá-la ao contrário, como se cada recomendação carregasse só critérios AAA — porque aí você descarta itens de nível A achando que são supérfluos. Fomos item por item e medimos:
- 32 das 50 recomendações citam pelo menos um critério de sucesso de nível A ou AA.
- 9 recomendações não citam nenhum critério AAA. Exemplos verificáveis: 5.7.11 ("Links para contornar blocos de conteúdo", nível A), 5.9.14 ("Botão de submissão", nível A), 5.13.11 ("Elementos nativos", nível A) e 5.1.7 ("Conteúdo adicional", nível AA).
- Na direção oposta, 11 requisitos citam algum critério de nível AAA — entre eles 5.3.5 (estrutura de cabeçalhos) e 5.12.1 (espaçamento entre linhas).
Na Seção 5.14 a quebra fica visível a olho nu: 5.14.3 é recomendação e traz os C.S. 1.2.1 e 1.2.3, ambos de nível A; 5.14.5 é recomendação e traz o C.S. 1.2.5, de nível AA. O motivo é explicado pela própria norma, que avisa: "algumas recomendações, quando cumpridas, também atendem à conformidade com determinados requisitos", com nota apontando a referência.
O que fazer com isso na prática. Não trate "recomendação" como sinônimo de "opcional de luxo". Leia o item, olhe os critérios listados e decida: recomendação apoiada em critério de nível A costuma ser barata e resolver um problema real de navegação — o "pular para o conteúdo" do item 5.7.11 é um bom exemplo. E lembre que, para conformidade plena, toda recomendação não atendida precisa de "justificativa razoável" escrita.
Os quatro requisitos que o site de emissora viola no primeiro segundo
Aqui a norma vira diagnóstico. Cada item traz o número, o texto e o conserto.
1. O player que dá play sozinho — 5.14.7 (requisito, C.S. 1.4.2, Nível A)
A norma admite duas saídas: nada de áudio automático acima de 3 segundos, ou um mecanismo de pausar, parar, silenciar ou ajustar volume sem afetar o volume geral do sistema. O site de rádio que abre tocando, com o controle escondido no rodapé ou só alcançável pelo mouse, não atende nenhuma das duas. O conserto é barato: play manual — que, de resto, é o que os navegadores já impõem na maioria dos casos — ou controle visível e alcançável pelo teclado, logo no topo. Onde os controles do player são decididos é assunto do nosso artigo sobre player para streaming de vídeo.
2. O banner rotativo — 5.15.1 Controle de animação (requisito, C.S. 2.2.2, Nível A)
O carrossel da home que troca sozinho é conteúdo em movimento sem controle do usuário. O texto do item dá as três saídas: não haver animação que inicie automaticamente, dure mais que 5 s e seja apresentada em paralelo com outro conteúdo; ou existir mecanismo para pausar, parar ou ocultar; ou a animação ser essencial para a atividade. Um botão de pausa no carrossel resolve.
3. O widget "tocando agora" que recarrega a página — 5.16.3 Controle de atualização (requisito, C.S. 2.2.2, Nível A)
Atualização automática sem controle do usuário reposiciona o foco e atropela leitor de tela no meio da leitura. A norma pede a mesma estrutura: não haver atualização automática apresentada em paralelo com outro conteúdo; ou haver mecanismo para pausar, parar, ocultar ou controlar a frequência; ou a atualização ser essencial. Atualizar só o bloco do "tocando agora", por requisição, em vez de recarregar a página inteira, já muda o item de lado.
4. A live sem legenda — 5.14.9 (requisito, C.S. 1.2.4, Nível AA)
É o item mais caro da lista e o mais difícil de contornar, porque não há proposição alternativa: "todo conteúdo em áudio ou áudio e vídeo ao vivo tem legendas disponíveis". Ponto.
Não afirmamos aqui qual percentual dos sites de emissora viola esses quatro itens — isso não foi medido, e número inventado não ajuda ninguém. O que dá para dizer é que são os quatro que aparecem com mais frequência quando se abre um site de rádio com o volume alto e o teclado na mão.
Legenda, transcrição, audiodescrição e Libras: o que é requisito
Essa é a crença que mais atrapalha quem vai contratar. Resumindo a tabela da Seção 5.14 em uma frase por recurso:
- Legenda — requisito, para vídeo gravado (5.14.2) e para conteúdo ao vivo (5.14.9). É o item que entra na conformidade regular.
- Audiodescrição — requisito (5.14.4), com a válvula do "áudio original é suficiente". Em versão estendida (5.14.5), vira recomendação.
- Transcrição — recomendação (5.14.3 para vídeo, 5.14.10 para áudio ao vivo). Não substitui legenda para fins de conformidade; resolve outras coisas, como deixar o conteúdo buscável.
- Janela de Libras — recomendação de nível AAA (5.14.6), restrita a áudio pré-gravado em mídia sincronizada.
Para quem transmite aula, a mesma discussão do lado legal — art. 63 e art. 28, §1º da LBI — está detalhada no artigo legenda automática ao vivo e acessibilidade em cursos online, do JMV Stream. E, quando o site é a plataforma do curso, a leitura de inclusão em plataformas de EAD cobre o lado pedagógico.
Site, aplicativo e prédio são três normas diferentes
Metade da confusão do tema é número de norma trocado. A divisão é simples:
- Site e aplicação web → ABNT NBR 17225:2025. É esta.
- Aplicativo de dispositivo móvel → ABNT NBR 17060. Ela é citada como referência normativa pela própria 17225.
- Edificação e espaço físico → ABNT NBR 9050. Aparece muito nas buscas relacionadas e não tem relação com site.
Há um número que circula fora de contexto e vale desarmar: o "54 requisitos" que às vezes aparece colado ao assunto. Ele não é da 17225 — atribuem-no à norma de aplicativos móveis (17060), que não lemos nesta apuração. Fica aqui como dado a confirmar, e o que importa é o recorte: os 96 requisitos são os desta norma, a de site.
Para não inventar norma, estas são as que a própria NBR 17225 referencia formalmente: ABNT NBR 17060 (aplicativos móveis), ABNT NBR ISO 24495-1 (linguagem simples), ABNT NBR 16452 (audiodescrição), ABNT NBR 15610-3 (TV digital terrestre — Libras), W3C-WCAG 2.2, W3C-WAI-ARIA 1.2 e o ARIA Authoring Practices Guide.
Como testar sem contratar ninguém
Antes de pedir orçamento de laudo, faça quatro testes que não custam nada e cobrem justamente os itens mais violados:
- Volume alto. Abra a home com o som no máximo. Tocou sozinho? Passou de 3 segundos? Existe um botão de pausar visível sem rolar a página? (5.14.7)
- Só teclado. Guarde o mouse e navegue com Tab. Dá para chegar ao play, ao menu e ao formulário? Dá para ver onde o foco está? Em algum ponto o foco fica preso? (grupo 5.1)
- Zoom de 200%. O texto reflui ou some atrás de outro elemento? (grupo 5.10)
- Leitor de tela nativo. NVDA no Windows, VoiceOver no Mac e no iPhone, TalkBack no Android. Ouça a home por um minuto — e repare se o widget de "tocando agora" interrompe a leitura sozinho (5.16.3).
Nenhum desses quatro testes produz laudo de conformidade, e não é isso que eles fazem. Eles dizem se vale a pena começar pelo conteúdo ou pelo código.
O que um botão de acessibilidade resolve — e o que não resolve
O widget flutuante — contraste, aumentar fonte, às vezes um avatar de Libras — é a compra mais comum do mercado, e ele não é inútil: resolve preferências de leitura para parte do público e sinaliza a intenção da casa.
O que ele não faz é atender os requisitos da Seção 5.14. Nenhum widget bota legenda na sua live (5.14.9), nenhum widget audiodescreve o seu vídeo (5.14.4) e nenhum widget impede o seu player de dar play sozinho (5.14.7). Esses três moram no seu HTML, no seu player e na sua operação de transmissão. O widget fica por cima da página; os requisitos estão dentro dela.
Vale a mesma cautela do lado do avatar de Libras: além de ser recomendação (e não requisito), o material oficial das ferramentas públicas desse tipo costuma avisar, com todas as letras, que o avatar não substitui o intérprete humano. Guarde essa frase para a próxima reunião em que alguém propuser trocar um pelo outro.
Quando o site é de órgão público
Câmara municipal, prefeitura, autarquia: a régua técnica continua sendo a NBR 17225, mas a cobrança chega por uma cadeia legal mais dura — Lei de Acesso à Informação, LBI e Lei 10.098. Essa cadeia está montada artigo por artigo, com o checklist da transmissão, em câmara municipal é obrigada a legendar a transmissão ao vivo?. Leia os dois juntos: lá está a obrigação; aqui está a régua que se usa para demonstrar que ela foi cumprida.
Assista ao episódio completo
Este texto nasceu do episódio "JMV Automate: agentes individuais de IA — Acessibilidade, EP. 4", do podcast Café & Tech, publicado pelo canal da JMV Technology em 12 de setembro de 2024 (59min58s), com Mário Sérgio, consultor de soluções da JMV, e Josimar Machado, CEO da JMV Technology. O episódio trata de acessibilidade por um ângulo mais largo — automação residencial, assistentes de voz, IA aplicada à inclusão — e este artigo desenvolve só uma parte dele: a pergunta sobre o site e o player da emissora. Vale assistir inteiro.
Nota de cronologia. O episódio é de setembro de 2024, seis meses antes da publicação da NBR 17225 (11/03/2025). A pergunta que ele faz — "o seu site tem as tags corretas? o seu player é inclusivo?" — não tinha, à época, uma norma brasileira para responder item por item. Hoje tem, e é ela que este artigo destrincha.
Trechos citados do episódio (transcrição revisada)
43:54 — "Você que tem um site de notícia, rádio, web rádio, web TV: o seu site está pronto para os leitores? Ele é inclusivo? […] Você precisa ter alguém que desenvolve o seu site com as tags adequadas e corretas para ser inclusivo. E o player, é inclusivo? Ele tem as tags corretas para que uma IA, para que uma Alexa reconheça o conteúdo daquele player?" — a pergunta que origina este artigo.
30:22 — "A gente foi fazer a live do debate para prefeito e teve que contratar uma pessoa para fazer Libras. […] Era caro, a hora da pessoa era cara para fazer ao vivo. E a gente não tem a quantidade de profissionais que seria preciso — foi uma dificuldade encontrar agenda; a gente até condicionou o horário e o dia do debate à disponibilidade da pessoa." — o custo e a escassez do intérprete humano, contados em primeira pessoa.
34:03 — "Acabei de ver aqui uma iniciativa do governo federal que eu não conhecia […] é open source, um conjunto de ferramentas gratuitas que traduz os conteúdos digitais — texto, áudio e vídeo — em português para Libras. […] Aí vem: 'lembre-se, o VLibras não substitui intérprete humano'." — a leitura, ao vivo, da página oficial da ferramenta.
35:17 — "Se você tem um portal de notícia, verificar se ele é inclusivo; se você tem um EAD, verificar se as suas aulas são inclusivas; se você faz um evento, um webinário, uma live, verificar se ela é inclusiva." — a lista de verificação informal que a NBR 17225 formalizou seis meses depois.
Transcrição automática do YouTube, revisada para corrigir erros de reconhecimento de fala (o áudio grafa "JMV" como "DMV/GMV" e "Josimar" como "Josmar") e pontuada para leitura. Falas de 12/09/2024. Uma afirmação do episódio sobre obrigatoriedade legal de intérprete de Libras naquele contexto eleitoral não foi verificada e por isso não é reproduzida aqui como afirmação jurídica.
Ver também
- Câmara municipal é obrigada a legendar a transmissão ao vivo? — a cadeia legal (LAI + LBI + Lei 10.098) quando o site é de órgão público.
- Player para streaming de vídeo — onde os controles que o item 5.14.7 cobra são decididos.
- O site da sua rádio não aparece no Google — o mesmo site, outro teste de 30 segundos: ali o banner rotativo e o player pesado são problema de SEO; aqui viram requisito de norma.
- Legenda automática ao vivo e acessibilidade em cursos online — a base legal para a empresa privada que transmite aula.
Quer ajustar o site da emissora para atender os requisitos da norma sem depender de quem vendeu o pacote? Fale com a gente pelo WhatsApp (11) 4063-8923.