Como Tornar Seu Site Acessível: Um Guia Inicial de WCAG 2.2

Para tornar um site acessível, construa-o para que as pessoas possam usá-lo com teclado, leitor de tela, zoom ou dispositivo de comutação, além do mouse: use elementos HTML reais para botões, links, títulos e rótulos de formulário, dê às imagens textos alternativos significativos, mantenha o contraste do texto alto e deixe o foco visível. O padrão a buscar é o WCAG 2.2 Nível AA. Verificadores automáticos detectam parte do problema; um teste de dez minutos com teclado e leitor de tela detecta boa parte do resto.

O que "acessível" significa na prática

Acessibilidade é sobre pessoas: alguém cego que usa leitor de tela, alguém com tremor que navega pelo teclado, alguém com baixa visão que amplia para 200%, alguém lendo com sol forte, alguém com o punho quebrado temporariamente. Boa acessibilidade tende a melhorar o site para todos — estrutura mais clara, texto legível, formulários que explicam seus erros.

O padrão de referência são as Diretrizes de Acessibilidade para Conteúdo Web (WCAG), do W3C. Em setembro de 2026, a versão atual é o WCAG 2.2 (publicado em outubro de 2023, atualizado em dezembro de 2024); o WCAG 3 é um rascunho inicial. O WCAG é organizado em torno de quatro princípios — o conteúdo deve ser perceptível, operável, compreensível e robusto — e tem três níveis de conformidade:

Nível	O que significa	Quem busca
A	O mínimo; sem ele, algumas pessoas não conseguem usar o site de jeito nenhum	Todos
AA	A meta comum; cobre contraste, foco, redimensionamento e tratamento de erros	A maioria das organizações e muitas leis
AAA	O mais rigoroso; não é alcançável para todo tipo de conteúdo	Serviços e públicos específicos

As leis em vários lugares citam o WCAG — por exemplo, o Ato Europeu de Acessibilidade, que se aplica a muitos serviços digitais de consumo na UE desde junho de 2025. Quais regras valem para você depende de onde você atua e do que vende; na dúvida, consulte um profissional. Este guia cobre o trabalho prático.

Opções: como chegar lá

Abordagem	Indicada para	Compensação
Construir já com acessibilidade	Sites e apps novos	Menor esforço no total; precisa ser definido desde o início
Auditar e corrigir	Sites existentes	Encontra problemas reais; exige uma revisão focada por página
Auditoria profissional	Setores regulados, sites grandes, órgãos públicos	Completa e documentada; custa dinheiro
Widget de sobreposição	Não recomendado	Não consegue corrigir o código por baixo

Para a maioria dos sites pequenos, as duas primeiras bastam: peça à IA que construa de forma acessível desde o início e depois audite antes do lançamento.

As correções que mais importam

Use os elementos HTML certos

Grande parte da acessibilidade vem de graça com HTML correto. Um <button> é focável, funciona com Enter e Espaço e é anunciado como botão. Uma <div> com um manipulador de clique não faz nada disso. Código gerado por IA às vezes usa divs estilizadas para tudo; peça elementos semânticos:

<button> para ações, <a href> para navegação
Um <h1> por página, depois <h2>, <h3> em ordem — usuários de leitor de tela pulam entre os títulos
Marcos: <header>, <nav>, <main>, <footer>
<label> conectado a cada campo de formulário
O idioma da página em <html lang="pt-BR">

Use atributos ARIA apenas quando nenhum elemento nativo servir — por exemplo, para um conjunto de abas ou um combobox personalizado. ARIA errado é pior do que nenhum.

Acesso pelo teclado e foco visível

Tudo o que você faz com o mouse precisa funcionar só com o teclado (WCAG 2.1.1). Pressione Tab pela página: cada link, botão e campo deve ser alcançável em uma ordem lógica, e você deve sempre ver onde está o foco (2.4.7 Foco Visível). O WCAG 2.2 acrescentou que o elemento focado não pode ficar totalmente oculto atrás de cabeçalhos fixos ou banners de cookies (2.4.11, Nível AA).

Falhas comuns: menus que abrem só com o cursor sobre eles, modais que não prendem o foco ou não podem ser fechados com Esc, e outline: none no CSS sem nada para substituir.

Alternativas textuais

Toda imagem significativa precisa de texto alternativo que diga o que ela mostra no contexto (“Chef montando o menu degustação”, não “imagem1.jpg”). Imagens decorativas recebem alt="" vazio para que os leitores de tela as ignorem. Botões só com ícone precisam de um nome acessível (“Fechar”, “Buscar”). Vídeos precisam de legendas; áudios precisam de transcrição.

Cor e contraste

O WCAG 2.2 AA exige uma razão de contraste de no mínimo 4,5:1 para texto normal e 3:1 para texto grande (1.4.3), e 3:1 para partes da interface, como bordas de campos e ícones significativos (1.4.11). Texto cinza claro de placeholder e botões pálidos são as falhas mais comuns. Além disso, nunca use apenas a cor para transmitir significado — uma borda vermelha em um campo inválido também precisa de uma mensagem de erro.

Redimensionamento e reflow

O texto precisa continuar utilizável com zoom de 200% (1.4.4), e o conteúdo precisa funcionar em uma largura de 320 pixels CSS sem rolagem lateral (1.4.10). Um layout responsivo bem feito resolve a maior parte disso.

Alvos, formulários e erros

Tamanho do alvo: o WCAG 2.2 AA pede alvos de ponteiro de no mínimo 24 por 24 pixels CSS, ou espaçamento suficiente em volta dos menores (2.5.8). Maior é mais gentil em celulares.
Formulários: rótulos visíveis (não apenas placeholder), instruções claras e mensagens de erro que digam o que está errado e como corrigir, ao lado do campo.
Login: não obrigue as pessoas a resolver um quebra-cabeça ou digitar um código sem uma alternativa; permita gerenciadores de senha e colagem (3.3.8 Autenticação Acessível).

Prompts que funcionam

Construa este site para atender ao WCAG 2.2 Nível AA: marcos semânticos de HTML, um h1 por página com títulos em ordem, elementos reais de botão e link, rótulos em todo campo de formulário, estilos de foco visíveis, contraste de texto de no mínimo 4,5:1, texto alternativo em imagens significativas e alt="" nas decorativas, e html lang definido.

Audite as páginas /signup e /checkout quanto à acessibilidade. Verifique o uso só com teclado, a ordem de foco, o foco visível, os rótulos, as mensagens de erro, o contraste e os nomes para leitor de tela dos botões de ícone. Liste cada problema com o critério do WCAG e depois corrija-os sem alterar o design visual além do necessário.

O menu móvel não pode ser usado com teclado. Transforme-o em um botão com aria-expanded, mova o foco para dentro do menu quando ele abrir, feche-o com Esc e devolva o foco ao botão.

Passo a passo

Rode uma verificação automática. A seção de Acessibilidade do Lighthouse nas Ferramentas do Desenvolvedor do Chrome, ou a extensão axe para o navegador, em cada página principal. Corrija tudo o que ela apontar.
Tire o mouse da jogada. Pressione Tab em cada página e complete cada tarefa principal — cadastro, busca, finalização de compra. Anote tudo o que você não consegue alcançar, não consegue ver o foco ou não consegue sair.
Amplie para 200% e reduza a janela para a largura de celular. Nada pode ser cortado ou exigir rolagem lateral.
Teste com um leitor de tela por dez minutos: VoiceOver no Mac e no iPhone, TalkBack no Android ou NVDA no Windows (gratuito). Ouça títulos, links e campos de formulário. “Botão” sem nome, ou “link, clique aqui”, significa trabalho a fazer.
Verifique o contraste do texto, dos botões e dos campos com um verificador de contraste.
Corrija e teste de novo as mesmas tarefas.
Publique uma declaração de acessibilidade dizendo qual padrão você busca e como relatar problemas — e responda a esses relatos.

Erros comuns

Depender de um widget de sobreposição em vez de corrigir o código.
Remover contornos de foco porque parecem feios, sem nenhuma substituição.
Usar placeholder como único rótulo. Ele desaparece quando a pessoa começa a digitar e muitas vezes tem contraste baixo.
Links “clique aqui” e “leia mais”. Fora de contexto, usuários de leitor de tela ouvem uma lista de links idênticos.
Texto alternativo cheio de palavras-chave. Texto alternativo é para pessoas; descreva a imagem.
Testar uma única vez. Cada novo recurso pode quebrar o acesso pelo teclado. Inclua uma passagem pelo teclado no seu teste antes do lançamento.

Checklist de acessibilidade

Verificação automática (Lighthouse ou axe) sem erros nas páginas principais
Toda tarefa pode ser concluída só com o teclado
Foco sempre visível e nunca oculto atrás de elementos fixos
Títulos, marcos, botões e links semânticos; lang definido
Texto alternativo significativo; imagens decorativas com alt=""; legendas em vídeos
Contraste de texto ≥ 4,5:1 (texto grande ≥ 3:1); partes da interface ≥ 3:1
Funciona com zoom de 200% e largura de 320 px
Todo campo de formulário tem rótulo visível e mensagens de erro claras
Declaração de acessibilidade com um canal para relatar problemas

Para os conceitos por trás disso, leia o que é acessibilidade web. Design acessível e bom design se sobrepõem bastante; como criar um app bonito com IA cobre o lado visual.

Acessibilidade no Mythex

O Mythex constrói com o padrão que você pedir, então coloque “WCAG 2.2 AA” no seu primeiro prompt e nas mensagens seguintes. Você pode usar o quadro de tamanho de celular da Prévia para verificar telas pequenas (Prévia e Código), mas os testes de teclado, zoom e leitor de tela funcionam melhor na URL publicada ou em uma prévia aberta em sua própria aba. Peça ao agente que audite uma página, corrija o que encontrar e teste você mesmo as correções — uma verificação automática é um começo, não uma aprovação final.

Perguntas

Qual é o padrão de acessibilidade atual para sites?

Em setembro de 2026, o padrão atual do W3C é o WCAG 2.2, publicado pela primeira vez em outubro de 2023. A maioria das organizações e muitas leis visam o Nível AA. O WCAG 3 ainda é um rascunho inicial.

Um widget de sobreposição de acessibilidade torna meu site conforme?

Não conte com isso. Sobreposições acrescentam uma barra de ferramentas por cima da página, mas não conseguem corrigir rótulos ausentes, acesso pelo teclado quebrado ou má estrutura do código por baixo. Corrigir o próprio site é o que o torna utilizável.

Verificadores automáticos encontram todos os problemas?

Não. Ferramentas como Lighthouse e axe detectam coisas como texto alternativo ausente, contraste baixo e campos sem rótulo, mas muitos problemas — ordem de foco confusa, textos de link sem sentido, texto alternativo presente porém errado — precisam de uma pessoa para testar com o teclado e um leitor de tela.

Qual razão de contraste o WCAG exige?

O WCAG 2.2 Nível AA exige no mínimo 4,5:1 para texto normal e 3:1 para texto grande, além de 3:1 para componentes da interface, como bordas de campos e ícones que transmitem significado.