Se você trabalha com web, UX ou compliance digital, já deve ter ouvido falar em WCAG. As Diretrizes de Acessibilidade para Conteúdo Web (WCAG) são o padrão internacional que define como tornar sites e aplicativos acessíveis a pessoas com deficiência.
Em outubro de 2023, o W3C lançou a versão WCAG 2.2, que trouxe nove novos critérios de sucesso em relação à versão 2.1. Em 2026, essa versão já é a referência adotada por legislações, licitações e grandes empresas ao redor do mundo.
Neste artigo, você vai entender o que mudou na WCAG 2.2, como essas mudanças impactam a experiência móvel e a cognição, e o que sua empresa precisa fazer para se adequar.
O que é a WCAG e por que ela importa
A WCAG (Web Content Accessibility Guidelines) é desenvolvida pelo W3C (World Wide Web Consortium), a principal organização de padrões da web. Ela estabelece requisitos técnicos para que conteúdos digitais sejam acessíveis a pessoas com deficiências visuais, auditivas, motoras, cognitivas e de aprendizagem.
As diretrizes são organizadas em quatro princípios, conhecidos como POUR:
- Perceptível: a informação deve poder ser percebida pelos sentidos (visão, audição, tato).
- Operável: a interface deve poder ser usada por todos, independentemente do dispositivo ou forma de interação.
- Compreensível: o conteúdo e a operação devem ser claros e previsíveis.
- Robusto: o conteúdo deve funcionar com diferentes tecnologias, incluindo tecnologias assistivas.
Cada princípio é detalhado em critérios de sucesso, classificados em três níveis de conformidade: A (mínimo), AA (intermediário) e AAA (avançado). A maioria das legislações, incluindo a LBI no Brasil, exige pelo menos o nível AA.
WCAG 2.0, 2.1 e 2.2: entenda a evolução
A WCAG segue uma lógica de versões cumulativas:
- WCAG 2.0 (2008): primeira versão amplamente adotada, com 61 critérios de sucesso.
- WCAG 2.1 (2018): adicionou 17 novos critérios, com foco em acessibilidade móvel, baixa visão e deficiências cognitivas.
- WCAG 2.2 (2023): adicionou 9 novos critérios e removeu 1 critério obsoleto (4.1.1 Parsing), mantendo todos os demais da 2.1.
Isso significa que, se seu site está em conformidade com a WCAG 2.2 AA, automaticamente está em conformidade com a 2.1 AA e 2.0 AA. A compatibilidade retroativa é uma característica intencional das diretrizes.
O que mudou na WCAG 2.2: os 9 novos critérios
A WCAG 2.2 introduziu nove critérios de sucesso, com foco em três grupos principais:
- Usuários com deficiências cognitivas ou de aprendizagem.
- Usuários com baixa visão.
- Usuários de dispositivos móveis e telas touch.
Veja cada um deles:
1. Foco não obscurecido (mínimo) — 2.4.11 (Nível AA)
O que exige: Quando um elemento recebe foco (por navegação via teclado ou outro meio), pelo menos parte dele deve permanecer visível, sem ser coberto por outros elementos (como menus fixos, banners ou modais).
Impacto: Beneficia pessoas com baixa visão e quem navega apenas por teclado, garantindo que saibam onde estão na página.
Exemplo prático: Um botão de “Comprar” com foco não pode ficar totalmente escondido atrás de uma barra de navegação fixa no topo ou rodapé.
2. Aparência do foco — 2.4.13 (Nível AAA)
O que exige: O indicador de foco deve ter contraste suficiente e área visível adequada para ser percebido por pessoas com baixa visão.
Impacto: Melhora a experiência de navegação por teclado, especialmente em telas pequenas ou com muito conteúdo visual.
Exemplo prático: Em vez de uma linha fina e clara ao redor do elemento focado, usar bordas mais espessas e com contraste elevado.
3. Movimentos de arrasto — 2.5.7 (Nível AA)
O que exige: Funcionalidades que dependem de gestos de arrastar (drag and drop) devem oferecer uma alternativa que não exija esse movimento.
Impacto: Beneficia pessoas com limitações motoras, tremores ou dificuldade de precisão no toque.
Exemplo prático: Um carrinho de compras que permite arrastar produtos também deve oferecer botões “Adicionar” e “Remover” clicáveis.
4. Tamanho do alvo (mínimo) — 2.5.8 (Nível AA)
O que exige: Áreas clicáveis (botões, links, ícones) devem ter tamanho mínimo de 24x24 pixels CSS, a menos que haja espaço suficiente ao redor ou que o alvo seja parte de uma frase.
Impacto: Facilita o uso em dispositivos móveis e por pessoas com dificuldades motoras ou de precisão.
Exemplo prático: Ícones de redes sociais no rodapé devem ter área de toque adequada, mesmo que visualmente pareçam menores.
5. Ajuda consistente — 3.2.6 (Nível A)
O que exige: Mecanismos de ajuda (chat, telefone, e-mail, FAQ) devem aparecer na mesma ordem relativa em todas as páginas onde são oferecidos.
Impacto: Reduz a carga cognitiva para pessoas com dificuldades de aprendizagem, memória ou atenção.
Exemplo prático: Se o ícone de chat aparece no canto inferior direito na home, deve manter a mesma posição nas demais páginas.
6. Entrada redundante — 3.3.7 (Nível A)
O que exige: O usuário não deve ser obrigado a digitar a mesma informação mais de uma vez na mesma sessão, a menos que haja justificativa clara (segurança, confirmação).
Impacto: Beneficia pessoas com dificuldades cognitivas, de memória ou dislexia, reduzindo esforço e risco de erro.
Exemplo prático: Em um checkout, não pedir novamente o e-mail se ele já foi informado no login ou cadastro.
7. Autenticação acessível (mínimo) — 3.3.8 (Nível AA)
O que exige: Processos de login não podem depender exclusivamente de testes de função cognitiva (como lembrar senha) sem oferecer alternativas acessíveis, como gerenciador de senhas, autenticação em duas etapas ou link de recuperação.
Impacto: Facilita o acesso para pessoas com dificuldades de memória, dislexia ou outras limitações cognitivas.
Exemplo prático: Oferecer opção de “Esqueci minha senha” ou login por código enviado por e-mail/SMS, além da senha tradicional.
8. Autenticação acessível (avançada) — 3.3.9 (Nível AAA)
O que exige: Elimina completamente a dependência de testes de função cognitiva em processos de autenticação, exigindo alternativas como biometria, tokens ou autenticação sem senha.
Impacto: Oferece experiência ainda mais inclusiva para pessoas com limitações cognitivas severas.
Exemplo prático: Login por reconhecimento facial, digital ou código mágico, sem necessidade de digitar senha.
9. Navegação por quebra de página — 2.4.13 (Nível A)
(Nota: em algumas fontes este critério aparece com numeração diferente; o essencial é entender o conceito.)
O que exige: Quando o conteúdo é dividido em páginas ou seções, deve haver um mecanismo claro para navegar entre essas quebras (ex.: índice, links “próxima/anterior”, breadcrumbs).
Impacto: Ajuda pessoas com dificuldades cognitivas e de orientação a entenderem onde estão e como se mover no conteúdo.
Exemplo prático: Em um formulário longo dividido em etapas, mostrar “Etapa 2 de 5” com links para voltar ou avançar.
Remoção do critério 4.1.1 Parsing
Uma mudança importante na WCAG 2.2 foi a remoção do critério 4.1.1 (Parsing), que exigia que o código HTML fosse bem formado e sem erros de sintaxe. Esse critério foi considerado obsoleto porque:
- Navegadores modernos lidam bem com pequenos erros de sintaxe.
- Outros critérios já cobrem questões de robustez e compatibilidade com tecnologias assistivas.
Isso não significa que código mal formado seja aceitável, mas que esse requisito específico não é mais um critério independente de conformidade.
Impacto na experiência móvel
A WCAG 2.2 reforça o compromisso com a acessibilidade em dispositivos móveis, reconhecendo que a maioria dos usuários acessa a web por smartphones e tablets. As principais implicações são:
- Alvos de toque maiores: botões e links devem ser fáceis de tocar sem erro, mesmo em telas pequenas.
- Gestos alternativos: funcionalidades que exigem arrastar devem ter opções clicáveis.
- Foco visível em telas touch: mesmo em dispositivos sem teclado físico, o foco deve ser claro quando houver navegação assistida.
- Conteúdo não obscurecido: menus fixos, banners e pop-ups não podem esconder completamente o elemento em foco.
Para empresas com apps ou sites responsivos, isso significa revisar componentes de interface, especialmente formulários, carrinhos de compra, menus e navegação.
Impacto na cognição e aprendizagem
A WCAG 2.2 dá atenção inédita a usuários com deficiências cognitivas, de aprendizagem e limitações relacionadas à memória e atenção. As mudanças incluem:
- Redução de carga cognitiva: evitar entrada redundante de dados e manter ajuda consistente em todas as páginas.
- Autenticação mais simples: não obrigar o usuário a lembrar senhas complexas sem alternativas.
- Navegação previsível: estrutura clara e indicadores de posição no conteúdo (etapas, breadcrumbs, índices).
Essas mudanças beneficiam não apenas pessoas com deficiência diagnosticada, mas também usuários idosos, pessoas sob estresse, com baixa escolaridade ou usando o site em contextos distrativos.
Como se adequar à WCAG 2.2 na prática
Se sua empresa já segue a WCAG 2.1 AA, o caminho para a 2.2 AA é mais curto do que parece. Siga estes passos:
1. Faça um diagnóstico específico para WCAG 2.2
Use ferramentas de auditoria e testes manuais para identificar violações dos nove novos critérios. Foque em:
- Tamanho de botões e áreas clicáveis.
- Funcionalidades de arrasto.
- Processos de login e autenticação.
- Posição e consistência de mecanismos de ajuda.
- Formulários com entrada repetida de dados.
- Elementos de foco obscurecidos por outros componentes.
2. Priorize correções de alto impacto
Comece pelas violações que afetam navegação crítica (checkout, login, formulários de contato) e que têm correção relativamente simples (aumentar área de toque, ajustar posição de elementos, oferecer alternativas a gestos de arrasto).
3. Revise fluxos de autenticação
Avalie se seus processos de login dependem exclusivamente de senha memorizada. Se sim, implemente alternativas como:
- Recuperação de senha simplificada.
- Autenticação em duas etapas.
- Login por código mágico (e-mail/SMS).
- Biometria (em apps nativos).
4. Padronize mecanismos de ajuda
Defina uma posição fixa para chat, telefone, e-mail e FAQ em todas as páginas. Documente esse padrão em seu guia de estilo e garanta que novas páginas sigam a mesma lógica.
5. Elimine entrada redundante
Revise formulários longos e fluxos de cadastro/checkout para evitar pedir a mesma informação múltiplas vezes. Quando necessário (ex.: confirmação de e-mail), explique claramente o motivo.
6. Teste com usuários reais
Inclua pessoas com deficiência cognitiva, baixa visão e limitações motoras em testes de usabilidade. Observe dificuldades em:
- Tocar alvos pequenos.
- Usar funcionalidades de arrasto.
- Preencher formulários repetitivos.
- Entender processos de login.
7. Documente e comunique
Publique uma declaração de acessibilidade informando que seu site segue a WCAG 2.2 AA, descreva medidas adotadas e ofereça canal para feedback. Isso demonstra transparência e compromisso contínuo.
WCAG 2.2 e o cenário brasileiro
No Brasil, a ABNT NBR 17225 e a Lei Brasileira de Inclusão (LBI) já utilizam a WCAG como referência técnica. Em 2026, novas diretrizes de fiscalização adotaram explicitamente a WCAG 2.2 como padrão para avaliação de conformidade.
Isso significa que empresas que desejam estar em conformidade com a legislação brasileira devem considerar a WCAG 2.2 AA como meta mínima, especialmente em setores regulados como e-commerce, serviços financeiros, saúde e educação.
Benefícios de adotar a WCAG 2.2
Além de cumprir exigências legais, a WCAG 2.2 traz vantagens competitivas:
- Melhor experiência móvel: interfaces mais fáceis de usar em smartphones aumentam conversão e reduzem abandono.
- Menor carga cognitiva: processos mais simples beneficiam todos os usuários, não apenas pessoas com deficiência.
- Redução de riscos jurídicos: conformidade com padrões internacionais protege contra notificações e processos.
- Reputação fortalecida: posicionamento como empresa inclusiva e socialmente responsável.
- Acesso a novos mercados: licitações e contratos que exigem conformidade com WCAG 2.2.
Erros comuns ao implementar a WCAG 2.2
Evite estas armadilhas:
- Focar apenas em correções visuais: acessibilidade não é só estética, é funcionalidade.
- Ignorar autenticação: processos de login são críticos e frequentemente negligenciados.
- Não testar em dispositivos reais: emuladores não substituem testes em smartphones e tablets reais.
- Esquecer a consistência: mudar a posição de ajuda ou navegação entre páginas gera confusão.
- Considerar apenas o nível A: a maioria das legislações exige pelo menos o nível AA.
Próximos passos para sua empresa
Se você quer garantir conformidade com a WCAG 2.2:
- Solicite uma auditoria específica para os nove novos critérios.
- Priorize correções em fluxos críticos (login, checkout, formulários).
- Revise padrões de design e desenvolvimento para incorporar as novas exigências.
- Treine equipes de UX, desenvolvimento e conteúdo sobre as mudanças.
- Publique uma declaração de acessibilidade atualizada.
Quanto antes sua empresa se adequar, menor será o esforço de correção e maior a proteção contra riscos jurídicos e perda de oportunidades de negócio.
O que é a WCAG 2.2?
A WCAG 2.2 é a versão mais recente das Diretrizes de Acessibilidade para Conteúdo Web, lançada em 2023, com 9 novos critérios de sucesso focados em mobile, baixa visão e cognição.
Quantos critérios novos a WCAG 2.2 trouxe?
A WCAG 2.2 adicionou 9 novos critérios de sucesso em relação à WCAG 2.1 e removeu 1 critério obsoleto (4.1.1 Parsing).
Qual o impacto da WCAG 2.2 em dispositivos móveis?
A WCAG 2.2 exige alvos de toque maiores (24x24 pixels), alternativas a gestos de arrasto e foco não obscurecido, melhorando a experiência em smartphones e tablets.
Como a WCAG 2.2 beneficia pessoas com deficiência cognitiva?
A norma reduz carga cognitiva ao exigir ajuda consistente, evitar entrada redundante de dados e oferecer alternativas em processos de autenticação que não dependam apenas de memória.
Minha empresa precisa migrar da WCAG 2.1 para a 2.2?
Sim, especialmente se você opera no Brasil (LBI, ABNT NBR 17225) ou em mercados que já adotam a WCAG 2.2 como padrão mínimo de conformidade.
A WCAG 2.2 é compatível com versões anteriores?
Sim. Se seu site está em conformidade com a WCAG 2.2, automaticamente está em conformidade com a 2.1 e 2.0.