WCAG 2.2 na prática: como deixar seu site institucional acessível

Site acessível é aquele que qualquer pessoa consegue usar, inclusive quem enxerga pouco, não usa mouse ou depende de leitor de tela (o programa que lê a página em voz alta). O padrão técnico que define isso é o WCAG, as diretrizes de acessibilidade do W3C, hoje na versão 2.2.

Este texto mostra o que o WCAG pede na prática, o que a lei brasileira já cobra do seu site e como aplicar as correções mais importantes num site institucional feito em Next.js.

Em poucas palavras

• O WCAG 2.2 é o padrão técnico vigente; a versão 3.0 ainda é rascunho e não serve como referência.
• A Lei Brasileira de Inclusão já torna a acessibilidade obrigatória para sites de empresa, mas sem regra técnica definida até agora.
• Texto alternativo em imagem, contraste de cor e navegação por teclado resolvem a maior parte dos problemas comuns.
• O Next.js ajuda com um aviso de rota e regras de lint prontas, mas não substitui revisão manual.

O que o WCAG 2.2 pede na prática

O WCAG organiza a acessibilidade em quatro princípios: perceptível (dá para perceber o conteúdo mesmo sem enxergar ou ouvir), operável (dá para navegar pelo teclado, não só pelo mouse), compreensível (texto e botão fazem sentido) e robusto (funciona com leitor de tela e outra tecnologia assistiva). A versão atual, as diretrizes WCAG 2.2 do W3C, foi publicada em outubro de 2023 e é a referência que qualquer auditoria usa hoje. A 3.0 ainda está em rascunho, sem data para virar norma oficial.

Na prática, o nível mais cobrado é o AA, o do meio entre A e AAA. Num site institucional pequeno, os problemas mais comuns são simples de corrigir:

• Imagem sem texto alternativo: toda imagem que carrega informação precisa de um texto que descreva o que ela mostra; imagem só decorativa pode ficar com o texto vazio.
• Contraste de cor baixo: o texto precisa de pelo menos 4,5 para 1 de contraste contra o fundo; cinza claro sobre branco costuma falhar nesse teste.
• Foco invisível ao navegar pelo teclado: quem usa Tab para passar de link em link precisa ver qual elemento está selecionado no momento.
• Botão ou link com rótulo vago: "clique aqui" ou "saiba mais" repetido em vários pontos da página não diz nada para quem ouve a página em vez de ler.

O que a lei brasileira já exige

O artigo 63 da Lei Brasileira de Inclusão, a Lei 13.146/2015, já torna obrigatória a acessibilidade nos sites mantidos por empresa com sede ou representação no Brasil, além dos órgãos de governo. O Decreto 5.296/2004 reforça essa obrigação para o setor público.

O problema é que, dez anos depois, o artigo nunca ganhou um regulamento com critério técnico claro nem punição definida para quem não cumpre. Em junho de 2026, o Ministério Público Federal moveu uma ação pedindo que a União regulamente o artigo em 60 dias e apresente um plano de transição em 120 dias. A ABNT já publicou uma norma técnica de referência, a NBR 17225:2025, mas ela ainda não é obrigatória por lei. Isso não é motivo para esperar: a lei já existe, falta só o detalhe técnico, e o WCAG preenche essa lacuna até lá.

Como o Next.js ajuda na acessibilidade

Um projeto em Next.js já sai de fábrica com duas ajudas. A primeira é o aviso de rota: quando o visitante navega entre páginas pelo next/link, sem recarregar a página inteira, o Next.js anuncia a nova página para quem usa leitor de tela, lendo o título da página ou o h1. A segunda é o eslint-plugin-jsx-a11y, ativado por padrão, que avisa no código sobre atributos ARIA incorretos, os atributos que descrevem papel e estado de um elemento para leitor de tela.

O que o Next.js não faz sozinho é garantir texto alternativo no componente next/image: a regra padrão do lint cobre a tag img comum, não o componente próprio do Next.js. Para fechar essa brecha, configure a regra manualmente:

{
  "rules": {
    "jsx-a11y/alt-text": ["error", { "elements": ["img", "Image"] }]
  }
}

Com essa linha no .eslintrc, o projeto para de compilar se alguém esquecer o atributo alt num componente Image. Isso resolve o mesmo risco que aparece na otimização de imagem com WebP e srcset: a imagem pode carregar rápido e, mesmo assim, ficar invisível para quem usa leitor de tela, se faltar o texto alternativo. O mesmo cuidado vale para marcação: como mostra o texto sobre dados estruturados no Next.js, marcação correta ajuda tanto o Google quanto quem navega por tecnologia assistiva a entender do que a página trata.

Checklist rápido para testar seu site hoje

1. Desconecte o mouse e navegue só com Tab e Enter: se não der para chegar no botão de WhatsApp ou no formulário, o foco está quebrado.
2. Aumente o zoom do navegador para 200%: o texto não pode cortar nem sobrepor outro elemento.
3. Rode um verificador de contraste de cor, existem versões gratuitas online, em cada combinação de texto e fundo da página.
4. Ligue o leitor de tela do celular, VoiceOver no iPhone ou TalkBack no Android, por dois minutos e tente entender a página só ouvindo.

Perguntas frequentes

WCAG é lei no Brasil?

Não diretamente. A lei brasileira, o artigo 63 da Lei Brasileira de Inclusão, exige acessibilidade, mas não cita o WCAG pelo nome nem define a régua técnica. Na prática, é o padrão que qualquer auditoria usa para medir se um site cumpre a lei.

Meu site precisa do nível AA ou AAA?

AA é o alvo realista para a maioria dos sites institucionais: cobre contraste, teclado e texto alternativo. AAA tem exigências mais rígidas, como contraste de 7 para 1, que a maioria dos sites, inclusive de grandes empresas, não atinge.

Deixar o site acessível deixa ele mais lento?

Não. As correções mais comuns, texto alternativo, contraste e rótulo em botão, são só HTML e CSS; não adicionam peso nem script. Acessibilidade e velocidade de carregamento andam juntas, não competem.

Dá para testar sem contratar um especialista?

Para o básico, sim: o checklist acima (teclado, zoom, contraste, leitor de tela) já aponta a maioria dos problemas comuns. Uma auditoria completa, com pessoas com deficiência testando de verdade, ainda é o padrão mais confiável, mas fica para quando o site já tiver volume de visita que justifique o investimento.

Todo site que a Visuapp entrega já sai com tag semântica, imagem otimizada e botão de WhatsApp com rótulo correto, porque isso também é parte de como o Google e o leitor de tela leem a página. Se o seu site institucional precisa dessa revisão ou de um projeto novo já pensado assim desde o início, fale com a gente.