Imagem retirada da página Jornalista Inclusivo

ABNT NBR 17225:2025 – A nova norma de acessibilidade digital no Brasil

Escrito por
Wagner Beethoven

A acessibilidade digital tem avançado globalmente, e o Brasil dá mais um passo significativo com a ABNT NBR 17225:2025, a norma que estabelece requisitos de acessibilidade para conteúdos e aplicações web. Baseada nas Diretrizes de Acessibilidade para Conteúdo Web — WCAG 2.2 (em inglês) do W3C, a norma busca garantir que sites e sistemas sejam acessíveis para todas as pessoas, incluindo aquelas com deficiência, necessidades temporárias ou limitações situacionais.

Mas como isso impacta o dia a dia de desenvolvedores, designers e gestores? Vamos explorar os principais pontos da norma e entender como isso transforma a construção de produtos digitais.

O que é a ABNT e qual seu papel?

A ABNT (Associação Brasileira de Normas Técnicas) é o órgão responsável pela criação e padronização de normas técnicas no Brasil. Fundada em 1940, a ABNT atua em diversas áreas, incluindo engenharia, tecnologia, segurança, meio ambiente e acessibilidade.

Seu objetivo principal é garantir padronização e qualidade em produtos e serviços, facilitando a regulamentação e a adoção de boas práticas no mercado.

A ABNT não tem poder fiscalizador, mas suas normas podem ser adotadas como referência em leis e regulamentos governamentais, tornando-se obrigatórias em certos contextos.

O Que é a ABNT NBR 17225:2025?

A ABNT NBR 17225:2025 foi um trabalho de dois anos elaborado em um processo de colaboração de diversos especialistas, representando um avança ao cumprimento do artigo 63º da LBI. A norma define um conjunto de aproximadamente 150 requisitos e recomendações que visam eliminar barreiras no acesso a sites e aplicações web, tem como base os critérios da WCAG 2.2 e estabelece dois tipos de conformidade:

1. Conformidade Regular: atendimento aos requisitos obrigatórios, garantindo alinhamento com os níveis A e AA da WCAG 2.2.
2. Conformidade Plena: além dos requisitos, incorpora todas as recomendações da norma, proporcionando uma experiência mais inclusiva e de alta qualidade.

Dessa forma, a norma reforça a importância da acessibilidade digital em diversas frentes:

1. Navegação totalmente acessível pelo teclado.
2. Uso correto de cabeçalhos, links e elementos semânticos.
3. Textos alternativos para imagens.
4. Legendas e audiodescrição para vídeos.
5. Contraste adequado entre texto e fundo.
6. Tamanho de fonte e espaçamento adequado para boa leitura.
7. Evitar animações excessivas e flashes que possam causar desconforto.
8. Botões de tamanho adequado para facilitar a interação.
9. Formulários acessíveis, com rótulos claros e mensagens de erro compreensíveis.

Seguir a norma não apenas contribui para um ambiente digital mais acessível, como também ajuda a evitar processos legais e tornar os produtos compatíveis com diretrizes internacionais.

Principais requisitos da norma

A seguir, apresento um panorama de cada área abordada pela norma.

Estrutura e semântica

O código HTML deve ser bem estruturado para permitir que tecnologias assistivas interpretem corretamente a página. Isso inclui:

• Cabeçalhos estruturados (<h1> a <h6>):
  • O <h1> deve ser único por página, representando o título principal.
  • Os demais cabeçalhos devem manter uma hierarquia lógica (<h2> → <h3> → <h4>).
  • Nunca use cabeçalhos apenas para estilização.
• Regiões semânticas (<header>, <nav>, <main>, <aside>, <footer>) devem estar corretamente implementadas para facilitar a navegação por leitores de tela (WCAG 1.3.1 – A).
• Listas (<ul>, <ol>, <dl>) devem ser corretamente declaradas.
  • Itens de lista (<li>) nunca devem ficar soltos fora de uma <ul> ou <ol>.
  • Definições (<dt>, <dd>) devem estar dentro de uma <dl>.
• Tabelas devem ser utilizadas apenas para dados estruturados e precisam incluir:
  • Cabeçalhos de tabela (<th>) identificando colunas e linhas (WCAG 1.3.1 – A).
  • Atributos scope="col" ou scope="row" para indicar a função das células <th>.
  • Evitar tabelas de leiaute; se forem usadas, não devem ter atributos semânticos.

Dica de implementação: Use landmarks para navegação eficiente.

Exemplo: <nav> para menus, <main> para conteúdo principal, <aside> para conteúdos secundários.

Codificação e marcação semântica

A estrutura do código deve ser compatível com tecnologias assistivas e seguir as boas práticas de desenvolvimento acessível.

• Título da página (<title>) deve ser descritivo e refletir o conteúdo da página (WCAG 2.4.2 – A).
• O idioma da página deve ser especificado (lang="pt-br", no caso de páginas com conteúdo escrito em português do Brasil) para que leitores de tela utilizem a pronúncia correta (WCAG 3.1.1 – A).
• Zoom do navegador não pode ser bloqueado e deve permitir ampliação de até 200% sem perda de conteúdo (WCAG 1.4.4 – AA).
• Mensagens de status devem ser anunciadas para leitores de tela sem exigir foco no elemento (WCAG 4.1.3 – AA).
• Elementos interativos devem ter um "nome acessível", garantindo compatibilidade com leitores de tela (WCAG 4.1.2 – A).

Dica de implementação: Para garantir que mensagens dinâmicas sejam lidas por leitores de tela, use ARIA live regions:

  <div role="status" aria-live="polite">
    Mensagem de erro: Preencha todos os campos obrigatórios.
  </div>

Tamanho de fonte e espaçamento entre linhas

A norma segue as diretrizes da WCAG 2.2 e define requisitos mínimos para facilitar a leitura e garantir que o conteúdo seja ajustável conforme a necessidade do usuário.

Tamanho de fonte

• Texto padrão deve ser ajustável sem perda de funcionalidade: O usuário deve poder aumentar a fonte em até 200% sem prejudicar a experiência ou cortar conteúdo (WCAG 1.4.4 – AA).
• Texto em tamanho grande: O critério para definir um texto grande é:
  • Pelo menos 18pt (24px) em fonte normal.
  • Pelo menos 14pt (19px) em negrito.

Dica de implementação:

• Use unidades relativas (rem, em, %) em vez de px para garantir escalabilidade do texto.
• Evite definir tamanhos fixos de fonte em px no CSS.

Exemplo correto:

  body {
    font-size: 1rem; /* 16px padrão do navegador */
  }
  h1 {
    font-size: 2rem; /* Escalável conforme a configuração do usuário */
  }

Espaçamento entre linhas e parágrafos

• O espaçamento entre linhas (line-height) deve ser no mínimo de 1.5x o tamanho da fonte.
• O espaçamento entre parágrafos deve ser pelo menos 2x o tamanho da fonte (WCAG 1.4.12 – AA).
• O espaçamento entre palavras e letras também deve ser ajustável:
• Espaçamento entre palavras ≥ 0.16x o tamanho da fonte.
• Espaçamento entre letras ≥ 0.12x o tamanho da fonte.

Dica de implementação: CSS para definir espaçamentos adequados:

  p {
    line-height: 1.5; /* Espaçamento entre linhas */
    margin-bottom: 1em; /* Espaçamento entre parágrafos */
    letter-spacing: 0.12em; /* Espaçamento entre letras */
    word-spacing: 0.16em; /* Espaçamento entre palavras */
  }

Isso melhora a legibilidade, especialmente para pessoas com dislexia e baixa visão.

Contraste e cores

Para garantir legibilidade, a norma exige um contraste mínimo entre o texto e o fundo:

• 4.5:1 para textos normais (WCAG 1.4.3 – AA).
• 3:1 para elementos gráficos importantes (WCAG 1.4.11 – AA).
• Não usar cores como único indicativo de erro ou estado (WCAG 1.4.1 – A).

Dica de implementação: Utilize ferramentas como Color Contrast Checker para testar a relação de contraste entre cores.

Interação por teclado

Usuários que não podem usar o mouse precisam ser capazes de navegar e operar todas as funcionalidades do site apenas com o teclado. Isso significa que:

• O indicador de foco deve ser visível: todos os elementos interativos devem exibir um contorno ou destaque ao serem selecionados via teclado (WCAG 2.4.13 – AA).
• Ordem de navegação previsível: fluxo de navegação pelo teclado deve ser lógico, seguindo a hierarquia da página sem pular elementos importantes (WCAG 2.4.3 – A).
• Evitar armadilhas de foco: nenhum elemento deve prender o usuário no foco, impedindo que ele continue navegando sem precisar usar o mouse (WCAG 2.1.2 – A).
• Atalhos de teclado:
  • Não podem usar apenas uma tecla sem uma tecla modificadora (exemplo: apenas “S” para buscar pode conflitar com leitores de tela).
  • Deve haver uma opção para desativar atalhos de teclado sem modificador (WCAG 2.1.4 – A).

Dica de implementação: use tabindex="0" para incluir elementos na navegação por tabulação e evite tabindex positivo, pois pode desordenar a sequência natural.

Links e navegação

A navegação e a interação com links devem ser previsíveis e fáceis de entender.

• Todos os links devem indicar claramente seu propósito com um texto descritivo (WCAG 2.4.4 – A).
• Evite usar “Clique aqui” como texto do link. O texto deve indicar o destino (exemplo: "Baixar Relatório em PDF").
• Links que abrem em nova aba/janela devem avisar o usuário (WCAG 3.2.5 – AAA).
• Links externos devem ser sinalizados para que o usuário saiba que será redirecionado para outro site.
• Menus de navegação devem ser consistentes em todas as páginas (WCAG 3.2.3 – AA).

Dica de implementação: Para avisar que um link abrirá em uma nova aba, utilize:

  <a href="https://focoacessivel.com.br.com"
    target="_blank"
    rel="noopener"
    aria-label="Abrir página em nova aba">
      Abrir O Foco Acessível em uma nova aba 🔗
  </a>

Formulários e entrada de dados

Os formulários precisam ser compreensíveis e operáveis por todos os usuários. Isso inclui:

• Todos os campos de formulário devem ter rótulos (<label> explicitamente associados ao <input>) (WCAG 1.3.1 – A).
• Campos obrigatórios devem ser identificados antes do envio, evitando que o usuário descubra o erro apenas ao submeter o formulário.
• Mensagens de erro devem ser descritivas e sugerir correções (WCAG 3.3.3 – AA).
• Evite depender apenas de cor para indicar campos com erro. Deve-se usar também ícones, mensagens de texto e aria-describedby.
• Autenticação acessível:
  • Se houver CAPTCHA, ele deve ter uma alternativa acessível, como um desafio auditivo ou matemático (WCAG 3.3.7 – A).
  • Campos de senha devem permitir autenticação por métodos alternativos, como login social ou chaves de acesso.

Dica de implementação: Sempre associe um id ao campo <input> e um

<label for="email">E-mail</label>
<input type="email" id="email" name="email">

Imagens e multimídia

Conteúdos visuais devem ser acessíveis para usuários cegos ou com baixa visão.

• Imagens precisam de texto alternativo (alt="") adequado:
  • Se for informativa, o texto alternativo deve descrever seu significado.
  • Se for decorativa, o alt deve ser vazio (alt="").
  • Imagens complexas, como gráficos, precisam de uma descrição detalhada próxima à imagem.
• Vídeos devem ter legendas descritivas para usuários surdos (WCAG 1.2.2 – A).
• Audiodescrição obrigatória para vídeos com conteúdo visual importante (WCAG 1.2.5 – AA).
• Áudio não pode ser reproduzido automaticamente por mais de 3 segundos, a menos que haja um controle para pausá-lo (WCAG 1.4.2 – A).

Dica de implementação: Utilize a API track do HTML5 para legendas em vídeos:

  <video controls>
    <source src="video.mp4" type="video/mp4">
    <track src="legendas.vtt" kind="subtitles" srclang="pt-br" label="Português">
  </video>

Uso de mídia sincronizada (áudio e vídeo ao vivo)

Conteúdos multimídia ao vivo também devem ser acessíveis.

• Legendas obrigatórias para transmissões ao vivo (WCAG 1.2.4 – AA).
• Transcrição obrigatória para áudios e vídeos gravados (WCAG 1.2.1 – A).
• Audiodescrição recomendada para vídeos com informações visuais importantes (WCAG 1.2.5 – AA).

Dica de implementação: Se você faz lives, pode usar serviços como YouTube Live Closed Captions para legendas automáticas.

Tempo e animações

• Usuários devem poder ajustar ou desativar limites de tempo (WCAG 2.2.1 – A).
• Flashes intermitentes não podem ultrapassar 3 piscadas por segundo para evitar gatilhos de epilepsia (WCAG 2.3.1 – A).
• Usuários devem poder pausar, interromper ou ocultar animações automáticas. (WCAG 2.2.2 – A)

Dica de implementação: Para evitar desconforto, reduza movimentos excessivos no design e sempre ofereça um botão de pausa para animações.

Tamanho e área de clique dos botões

A norma determina que os botões e elementos interativos sejam de tamanho adequado para facilitar o toque e o clique, especialmente em dispositivos móveis.

Tamanho mínimo de botões e elementos interativos

• O tamanho mínimo para elementos clicáveis é de 24px x 24px (WCAG 2.5.8 – AA).
• O recomendado para uma melhor experiência é 44px x 44px (WCAG 2.5.5 – AAA).
• Se o botão for menor que 44px, ele deve ter espaçamento externo suficiente para evitar toques acidentais.

Dica de implementação: Certifique-se de que botões tenham uma área de toque adequada, especialmente em dispositivos móveis:

  button {
    min-width: 44px;
    min-height: 44px;
    padding: 10px 16px;
  }

Se um botão menor precisar ser usado, garanta um espaçamento ao redor:

  button {
    width: 24px;
    height: 24px;
    margin: 10px;
    }

Isso evita que botões fiquem muito próximos, dificultando a interação para usuários com mobilidade reduzida.

Área de clique e espaçamento dos botões

• Botões devem ter uma área de clique grande o suficiente para evitar erros de toque.
• Não usar apenas ícones como botões, sem um rótulo acessível (aria-label ou title).
• O acionamento do botão não pode ocorrer apenas ao passar o mouse (hover), mas sim ao clicar ou pressionar Enter/Espaço no teclado.

Dica de implementação:

    <button aria-label="Enviar formulário">📩</button>

Isso garante que leitores de tela anunciem corretamente a função do botão.

Autenticação e Segurança

Usuários devem conseguir se autenticar sem barreiras desnecessárias.

• Evitar testes de função cognitiva, como desafios baseados em memorização ou cálculos (WCAG 3.3.7 – A).
• CAPTCHAs devem ter alternativas acessíveis, como desafios auditivos ou perguntas simples.
• Autenticação sem exigência de lembrar senha: Opções como login por e-mail ou biometria devem estar disponíveis.

Dica de implementação: Se for necessário usar CAPTCHA, forneça alternativas como um código enviado por e-mail.

Desempenho funcional e adaptação para diferentes usuários

A experiência deve ser acessível para usuários com diferentes necessidades, incluindo:

• Navegação sem visão: Leitores de tela devem ser capazes de descrever todo o conteúdo.
• Navegação com visão limitada: O contraste e tamanho do texto devem ser ajustáveis.
• Navegação sem audição: Vídeos e áudios devem ter legendas ou transcrição.
• Navegação sem mobilidade nas mãos: Todo o site deve ser operável sem mouse.
• Navegação com cognição limitada: O design deve ser simples e intuitivo.

Dica de implementação: Teste o site usando apenas o teclado e um leitor de tela como o NVDA ou VoiceOver.

Por que essa norma é um marco importante?

A publicação da ABNT NBR 17225:2025 representa um avanço fundamental na acessibilidade digital no Brasil. Ela reforça a necessidade de pensar na diversidade dos usuários, desde pessoas com deficiência até aquelas com limitações temporárias ou situacionais.

Além disso, sua adoção favorece a inovação e a responsabilidade social das empresas, garantindo que mais pessoas tenham autonomia no uso de produtos digitais.

Para desenvolvedores, designers e gestores, essa norma não deve ser vista apenas como uma obrigação, mas como um guia para a criação de experiências mais inclusivas e eficientes.

Se você trabalha com tecnologia, está na hora de revisar seus projetos e garantir que eles estejam alinhados com essa nova norma. Afinal, acessibilidade não é um diferencial – é um direito.

Confira a fala do Reinaldo Ferraz, nosso convidado do nosso 5º episódio do podcast, sobre a norma.

Ver essa foto no Instagram

Uma publicação compartilhada por Reinaldo Ferraz (@reinaldoferraz)

O que acontece se um produto digital não seguir as diretrizes?

A falta de acessibilidade pode ter impactos negativos tanto para os usuários quanto para as empresas. Aqui estão algumas das principais consequências para produtos digitais que não se adequam às normas:

Violações legais e processos judiciais

No Brasil, a acessibilidade digital é um direito garantido por lei. A Lei Brasileira de Inclusão (LBI) – Lei nº 13.146/2015 exige que sites e sistemas digitais de empresas e órgãos públicos sejam acessíveis.

Se um produto digital não atender aos critérios de acessibilidade, ele pode estar em desacordo com a legislação, o que pode resultar em:

• Multas e penalidades impostas pelo governo.
• Ações judiciais individuais e coletivas movidas por usuários prejudicados.
• Termos de ajustamento de conduta (TACs) exigindo correções urgentes.

Empresas já enfrentaram processos milionários por falta de acessibilidade digital — tanto no Brasil quanto no exterior.

Exemplo real: Nos EUA, grandes corporações como Netflix, Domino’s Pizza e Target foram processadas por não garantirem acessibilidade em seus sites e aplicativos.

Exclusão de usuários e perda de clientes

A acessibilidade digital não beneficia apenas pessoas com deficiência, mas toda a população, incluindo idosos, pessoas com dificuldades temporárias (exemplo: um braço imobilizado) e aqueles que enfrentam barreiras situacionais (como acessar um site sob forte luz do sol).

Se um site ou aplicativo não for acessível, milhões de pessoas simplesmente não conseguirão usá-lo. Isso significa:

• Perda de clientes e receita.
• Aumento da taxa de rejeição no site (os usuários abandonam rapidamente).
• Impacto negativo na reputação da marca (empresas que não investem em inclusão são mal vistas pelo público).

Dado importante: No Brasil, cerca de 18,6 milhões de pessoas têm algum tipo de deficiência (IBGE, 2019). Ignorar a acessibilidade é excluir um mercado consumidor gigantesco.

Dificuldade em contratos com o setor público

Empresas que prestam serviços para órgãos governamentais precisam obrigatoriamente seguir normas de acessibilidade digital.

Se um produto digital não for acessível, ele pode ser desclassificado em licitações e perder oportunidades de contrato com o setor público.

Exemplo: Sistemas de e-gov, plataformas de pagamento digital e portais de serviços precisam cumprir exigências legais de acessibilidade.

Impacto no SEO e visibilidade online

Os mecanismos de busca, como Google, dão prioridade para sites acessíveis. Isso significa que páginas que não seguem diretrizes de acessibilidade podem ter ranqueamento inferior, tornando-se menos visíveis nos resultados de pesquisa.

SEO e acessibilidade digital andam juntos. Seguir as boas práticas da ABNT NBR 17225:2025 pode:

• Melhorar a indexação nos motores de busca.
• Aumentar o tempo de permanência dos usuários no site.
• Diminuir a taxa de rejeição.

Dica importante: Sites com cabeçalhos estruturados corretamente (<h1>, <h2>) e textos alternativos (alt="") para imagens têm maior chance de ranquear melhor no Google.

Conclusão

A ABNT NBR 17225:2025 estabelece padrões claros para garantir que todos possam navegar e interagir com conteúdos digitais sem barreiras. Se você desenvolve produtos digitais, não ignore essa norma: sua implementação melhora a experiência do usuário, amplia seu público e evita problemas legais.

Se deseja aprofundar-se mais, recomendo ler a norma completa e começar a aplicá-la desde já. A acessibilidade digital é um caminho sem volta – e quanto mais cedo começarmos, melhor será para todos.

A acessibilidade digital não é apenas um diferencial competitivo — é um direito. Adotar a ABNT NBR 17225:2025 hoje significa não apenas cumprir normas, mas garantir que seu produto digital seja para todos.

Você já começou essa adaptação? Compartilhe sua experiência nos comentários!

---

Esse texto não substitui o documento original ( norma-ABNT-17225-acessibilidade.pdf – 650kb, PDF), nele há muito mais detalhes. Além dessas recomendações, o documento apresenta um check-list para ajudar a guiar a construção das interfaces seguindo as recomendações propostas.

Abaixo, o vídeo do lançamento da ABNT NBR 17225:2025:

• Texto publicado em: 17/03/2025

Obrigado por acompanhar até aqui! Inscreva-se em nossa newsletter (mandamos no máximos dois e-mails por mês 🥰), siga-nos nas redes sociais (LinkedInInstagramTikTokFacebookPinterestTwitterThreads) e nos principais serviços de streaming, até a próxima e lembre-se: acessibilidade é um assunto que cedo ou tarde vai impactar a sua vida!