Como ler as WCAG 2.2 para o seu site, as correções que cobrem a maioria das falhas reais, um teste manual de 30 minutos que qualquer pessoa pode executar e como acessibilidade e usabilidade se sobrepõem.
Perguntas frequentes
O que significa um site ser compatível com WCAG?
Significa que o site atende aos critérios de sucesso das Web Content Accessibility Guidelines no nível escolhido, geralmente WCAG 2.1 ou 2.2 nível AA. O nível AA inclui todos os critérios dos níveis A e AA. A maioria das leis e políticas de contratação que fazem referência às WCAG exige o nível AA.
Como devo interpretar as diretrizes WCAG para o meu site?
Comece pela referência rápida 'How to Meet WCAG' do W3C, filtre para os níveis A e AA e, para cada critério, leia a página 'Understanding', que explica a intenção em linguagem simples. Depois teste seus principais templates (página inicial, uma página de conteúdo, um formulário, checkout) em vez de cada página individualmente.
Um overlay ou plugin de acessibilidade pode tornar meu site compatível?
Nenhuma ferramenta sozinha pode tornar um site compatível. Overlays que adicionam uma barra de ferramentas não corrigem o código subjacente, e muitos usuários com deficiência e especialistas em acessibilidade relatam que eles atrapalham. Corrija o HTML, o contraste, os rótulos e o suporte a teclado diretamente.
Qual é a diferença entre usabilidade e acessibilidade?
Acessibilidade significa que pessoas com deficiência podem perceber, entender, navegar e interagir com o site. Usabilidade significa que o site é fácil e eficiente para todos. Elas se sobrepõem muito: rótulos claros, bom contraste e navegação previsível ajudam todos os visitantes, não apenas os com deficiência.
Verificadores automáticos encontram todos os problemas de acessibilidade?
Não. Ferramentas como WAVE, axe e Lighthouse capturam problemas como texto alternativo ausente, baixo contraste e rótulos ausentes, mas muitos critérios — como saber se o texto alternativo é significativo ou se a ordem do foco faz sentido — precisam de verificação humana.
Um site compatível com WCAG atende às Web Content Accessibility Guidelines no nível escolhido e, para quase todas as empresas, isso significa WCAG 2.2 nível AA. Na prática, a maioria dos sites falha nos mesmos poucos problemas: baixo contraste de cor, texto alternativo ausente em imagens, campos de formulário sem rótulo, links e botões vazios e elementos que não são acessíveis pelo teclado. Corrija esses problemas e teste com teclado e leitor de tela, e você terá coberto grande parte do que os usuários reais encontram.
Este guia explica como ler as WCAG sem se perder, as correções mais importantes e um teste de 30 minutos que você pode fazer por conta própria.
Como as WCAG são estruturadas
As WCAG são publicadas pelo W3C. São organizadas em camadas:
Quatro princípios, conhecidos como POUR: o conteúdo deve ser Perceptível, Operável, Compreensível e Robustro.
Diretrizes sob cada princípio (por exemplo, "Alternativas de Texto" ou "Acessível pelo Teclado").
Critérios de sucesso sob cada diretriz. Essas são as regras testáveis, cada uma numerada (como 1.4.3 Contraste) e com um nível: A, AA ou AAA.
O nível A é o mínimo. O nível AA é o alvo comum para requisitos legais e de contratação. O nível AAA é mais restrito e geralmente não é exigido para sites inteiros.
As WCAG 2.2 tornaram-se uma Recomendação do W3C em outubro de 2023. Adicionaram critérios como tamanho mínimo de alvo, foco não obscurecido e autenticação acessível, e removeram o 4.1.1 Parsing por estar obsoleto.
Como interpretar as WCAG para o seu site
A especificação lê como um padrão, porque é um. Uma forma prática de atravessá-la:
Abra a "How to Meet WCAG (Quick Reference)" do W3C.
Filtre para nível A e AA apenas.
Para cada critério, leia a página "Understanding" vinculada. Ela explica a intenção em linguagem simples, com exemplos de aprovação e reprovação.
Em vez de testar cada página, teste seus templates: página inicial, uma página de conteúdo padrão, um post de blog, um formulário, uma página de produto ou checkout. Corrigir um template corrige cada página criada a partir dele.
Registre cada problema com o número do critério, a página e como seria uma correção.
As correções que cobrem a maioria das falhas reais
1. Contraste de cor (1.4.3 e 1.4.11)
Texto normal: pelo menos 4,5:1 em relação ao fundo.
Texto grande (cerca de 24px normal, ou 18,66px negrito e maior): pelo menos 3:1.
Componentes de interface e elementos gráficos significativos (bordas de botão, contornos de input, ícones que transmitem informação): pelo menos 3:1.
Texto cinza claro de placeholder e texto branco em cores de marca claras são os culpados comuns. Verifique com o verificador de contraste do WebAIM ou as ferramentas de desenvolvedor do navegador.
2. Alternativas de texto para imagens (1.1.1)
Imagens informativas recebem texto alternativo descrevendo o que importa: alt="Técnico trocando filtro de aquecedor".
Imagens decorativas recebem alt vazio: alt="", para que leitores de tela as ignorem.
Imagens de texto (foto de panfleto, cardápio como JPG) precisam que o mesmo texto esteja disponível como texto real.
Imagens vinculadas, como um logotipo que leva para a página inicial, descrevem o destino: alt="Página inicial da Acme Encanamento".
3. Rótulos e erros de formulário (1.3.1, 3.3.1, 3.3.2)
Cada input precisa de um <label> visível vinculado a ele. Texto de placeholder não é um rótulo: desaparece quando você digita.
Mensagens de erro dizem o que deu errado e como corrigir ("Digite um número de telefone com DDD"), em texto, não apenas uma borda vermelha.
Campos obrigatórios são marcados em texto ou com indicador acessível, não apenas por cor.
4. Acesso pelo teclado (2.1.1, 2.4.3, 2.4.7)
Todo link, botão, menu e controle de formulário deve funcionar com Tab, Shift+Tab, Enter e Espaço.
A ordem do foco segue a ordem visual.
Um indicador de foco visível mostra onde você está. Remover o contorno do navegador com outline: none sem substituição é uma falha comum.
Menus suspensos e modais devem abrir, funcionar e fechar pelo teclado, e modais devem manter o foco interno até serem fechados.
5. Links e botões com nomes (2.4.4, 4.1.2)
Botões apenas com ícone (menu hambúrguer, lupa de busca, ícones de redes sociais) precisam de nome acessível, via texto visível, aria-label ou texto oculto.
Evite uma página cheia de links "Clique aqui" e "Saiba mais". Faça o texto do link descrever o destino, ou dê a cada um um nome acessível distinto.
6. Estrutura e cabeçalhos (1.3.1, 2.4.6)
Um <h1> por página descrevendo a página.
Cabeçalhos em ordem lógica (h2 para seções, h3 dentro delas), não escolhidos pelo tamanho da fonte.
Use listas reais, tabelas com células de cabeçalho e marcos (<header>, <nav>, <main>, <footer>).
Defina o idioma da página: <html lang="pt-BR">.
7. Novidades nas WCAG 2.2, vale conhecer
2.5.8 Tamanho do Alvo (Mínimo), AA: alvos clicáveis de pelo menos 24 por 24 pixels CSS, ou espaçamento suficiente ao redor de alvos menores.
2.4.11 Foco Não Obscurecido (Mínimo), AA: cabeçalhos fixos, banners de cookies e widgets de chat não devem ocultar completamente o elemento em foco.
3.3.8 Autenticação Acessível (Mínimo), AA: não exigir resolução de puzzles ou memorização de informações para fazer login sem alternativa; permitir gerenciadores de senhas e colar.
3.3.7 Entrada Redundante, A: não fazer as pessoas redigitarem informações que já forneceram no mesmo processo.
8. Mídia e movimento
Vídeos precisam de legendas (1.2.2); vídeo pré-gravado precisa de audiodescrição ou alternativa de texto para conteúdo visual importante.
Qualquer elemento que se mova automaticamente por mais de cinco segundos precisa de uma forma de pausá-lo (2.2.2).
Respeite a configuração prefers-reduced-motion para animações grandes.
Um teste manual de 30 minutos
Ferramentas automatizadas capturam apenas parte do problema. Adicione esta rotina para cada template principal.
Minutos 0 a 5: verificação automática. Execute WAVE (extensão de navegador) ou axe DevTools, ou a seção de acessibilidade do Lighthouse. Corrija erros claros como alt ausente, rótulos ausentes e falhas de contraste.
Minutos 5 a 15: apenas teclado. Coloque o mouse de lado. Percorra a página com Tab desde o topo.
Você consegue ver onde está o foco em todos os momentos?
Você consegue abrir e fechar o menu, usar todos os campos do formulário e enviar?
Há um link "Ir para o conteúdo", e ele funciona?
O foco some atrás de um cabeçalho fixo ou banner?
Minutos 15 a 25: leitor de tela. Use o VoiceOver (integrado ao macOS e iOS) ou NVDA (gratuito no Windows).
Ouça a lista de cabeçalhos. Ela descreve a página?
Vá para imagens e botões com Tab. Eles fazem sentido fora de contexto?
Preencha o formulário. Cada campo é anunciado com seu rótulo? Os erros são anunciados?
Minutos 25 a 30: zoom e refluxo. Amplie o navegador para 200% e depois 400%. A 400%, o conteúdo deve reformatar em uma coluna sem rolagem horizontal (1.4.10 Reflow), e nada deve ser cortado.
Sobreposição entre usabilidade e acessibilidade
Pessoas que buscam "usabilidade e acessibilidade web" estão certas em agrupá-las. Quase toda correção de acessibilidade é também uma correção de usabilidade:
Correção de acessibilidade
Quem mais se beneficia
Contraste forte
Qualquer pessoa com celular sob luz solar
Rótulos visíveis
Qualquer pessoa preenchendo formulário com pressa
Legendas
Pessoas assistindo sem som
Suporte a teclado
Usuários avançados, pessoas com trackpad quebrado
Alvos de toque maiores
Todos no celular
Mensagens de erro claras
Todos que cometem um erro de digitação
Overlays, declarações e a lei
Overlays: widgets que prometem conformidade com uma linha não alteram seu código subjacente. Corrija o site em si.
Declaração de acessibilidade: publique uma página curta indicando qual padrão você busca, problemas conhecidos e como entrar em contato para obter ajuda ou formatos alternativos.
Contexto legal: os requisitos variam por país. O European Accessibility Act se aplica a muitos produtos e serviços na UE a partir de junho de 2025; nos EUA, a ADA é frequentemente aplicada a sites; órgãos públicos costumam ter regras específicas. Consulte um advogado para a sua situação.
Checklist
[ ] Contraste: 4,5:1 para texto, 3:1 para texto grande e partes de interface
[ ] Texto alternativo em imagens informativas, alt vazio em imagens decorativas
[ ] Cada input tem um rótulo visível e vinculado
[ ] O site inteiro funciona pelo teclado com foco visível
[ ] Botões de ícone têm nomes acessíveis
[ ] Cabeçalhos e marcos lógicos, idioma da página definido
[ ] Alvos de toque de pelo menos 24 por 24 pixels CSS
[ ] Legendas em vídeo, controle de pausa em movimento
[ ] Reflui a 400% de zoom
[ ] Declaração de acessibilidade publicada
A acessibilidade também apoia a busca orgânica: cabeçalhos, texto alternativo e links descritivos são fundamentos básicos de SEO na página, abordados no nosso checklist de SEO na página.
A We.Inc gera sites como HTML, CSS e código React padrão que você pode editar diretamente, para que possa corrigir rótulos, texto alternativo e contraste por conta própria ou solicitar as alterações no chat. Sempre execute as verificações manuais acima em tudo que publicar.