O que mudou no WCAG 2.2 em relação ao WCAG 2.1

As Web Content Accessibility Guidelines (WCAG) são o padrão para o qual a maioria das leis de acessibilidade apontam. WCAG 2.2 virou Recomendação W3C em 5 de outubro de 2023, adicionou nove novos critérios de sucesso e removeu um. Agora também é ISO/IEC 40500:2025. Se você mantém um site, design system ou produto em 2026, a pergunta prática é: o que mudou, o que cada novo critério realmente exige e como priorizar as correções? Este post responde cada uma, com fontes citadas para você verificar.

Breve história da WCAG

O W3C publicou as primeiras Web Content Accessibility Guidelines em 5 de maio de 1999. WCAG 1.0 era prescritiva e específica para HTML; envelheceu rápido quando a web foi além de documentos planos para aplicações ricas.

WCAG 2.0 veio em 11 de dezembro de 2008. Abstraiu a orientação de qualquer tecnologia específica, organizou sob os quatro princípios «Perceptível, Operável, Compreensível, Robusto» (POUR), e introduziu o esquema de conformidade de três níveis A/AA/AAA ainda usado. É a versão que a maioria das regulações americanas e internacionais referenciava originalmente.

WCAG 2.1 seguiu em 5 de junho de 2018. Adicionou 17 novos critérios cobrindo mobile (orientação, alvos de toque, ativação por movimento), usuários de baixa visão (reflow, espaçamento de texto, contraste não-texto) e acessibilidade cognitiva (label-in-name, mensagens de status). É a versão embutida no padrão EN 301 549 v3.2.1 referenciado pela European Accessibility Act.

WCAG 2.2 foi publicada em 5 de outubro de 2023 e republicada com atualizações editoriais em 12 de dezembro de 2024. Adiciona nove critérios novos, remove um (4.1.1 Parsing) e agora também é ISO/IEC 40500:2025. WCAG 3, um framework substancialmente diferente com scoring novo, ainda está em rascunho, não esperado para adoção geral antes de 2027.

Os nove novos critérios de sucesso

Os novos critérios caem em três clusters temáticos: foco, modalidade de entrada, acessibilidade cognitiva.

Cluster foco

2.4.11 Foco Não Obscurecido (Mínimo), Nível AA. Quando um componente de UI recebe foco de teclado, o componente não pode estar inteiramente escondido por conteúdo do autor (cabeçalhos pegajosos, banners de cookies, widgets de chat). O componente pode estar parcialmente obscurecido; o critério só falha quando nada está visível.

2.4.12 Foco Não Obscurecido (Aprimorado), Nível AAA. Versão mais rígida de 2.4.11: nenhuma parte do componente com foco pode estar escondida. Versão AAA que a maioria dos design systems empresariais mira.

2.4.13 Aparência do Foco, Nível AAA. O indicador de foco precisa ter pelo menos 2 pixels CSS de espessura em torno do controle com foco, e seu contraste contra o estado não-focado adjacente precisa ser pelo menos 3:1. Um anel de foco 1px padrão num botão escuro falha; um anel 2px alto contraste passa.

Cluster modalidade de entrada

2.5.7 Movimentos de Arrastar, Nível AA. Tudo que pode ser feito com um gesto de arrastar precisa também poder ser feito sem. Exemplos: listas ordenáveis que só respondem a arrastar, sliders, panorama de mapa. O critério não proíbe o arrastar; exige uma alternativa como setas para cima/baixo para reordenar, ou campo de entrada para valor de slider.

2.5.8 Tamanho de Alvo (Mínimo), Nível AA. Alvos de ponteiro precisam ter pelo menos 24 por 24 pixels CSS, exceto se forem inline (links num parágrafo), expostos num padrão do user-agent (um <select>), essenciais para a função, ou tiverem controle equivalente em outro lugar da página atendendo 24x24. O critério WCAG 2.1 anterior 2.5.5 fixava o limiar em 44x44 mas no nível AAA; 2.5.8 torna um piso menor de 24x24 obrigatório no nível AA.

Cluster acessibilidade cognitiva

3.2.6 Ajuda Consistente, Nível A. Se mecanismos de ajuda («Fale conosco», widget de chat, link de ajuda, telefone de ajuda) aparecem em múltiplas páginas, precisam aparecer na mesma ordem relativa em cada uma. A intenção é reduzir carga cognitiva.

3.3.7 Entrada Redundante, Nível A. Usuários não devem ter que reinserir informação já fornecida no mesmo processo. Formulários multi-etapa precisam lembrar entradas anteriores. O critério não proíbe re-perguntar quando essencial (verificação de segurança) ou quando a informação mudou.

3.3.8 Autenticação Acessível (Mínimo), Nível AA. Autenticação não pode exigir testes de função cognitiva como lembrar de senha, resolver puzzle, ou transcrever CAPTCHA baseado em imagem, exceto se uma alternativa for fornecida. Alternativas aceitáveis: gerenciador de senhas, código one-time, biometria, token de hardware.

3.3.9 Autenticação Acessível (Aprimorado), Nível AAA. Versão mais rígida: puzzles de reconhecimento de objeto e conteúdo pessoal também proibidos, exceto com alternativa.

O critério removido

4.1.1 Parsing foi retirado como obsoleto. Exigia que o conteúdo fosse parseável: tags de início/fim completas, sem IDs duplicados, elementos corretamente aninhados. Em 2008 isso importava porque tecnologias assistivas parseavam HTML elas mesmas e falhavam em markup malformado. Em 2024 toda tecnologia assistiva consome a árvore de acessibilidade do navegador, não HTML cru. WCAG 2.2 reconhece isso retirando o critério. Ainda aparece em conformidade WCAG 2.0 e 2.1, não em 2.2.

Níveis de conformidade, recap

Impacto prático, por onde começar

1. 2.5.8 Tamanho de Alvo (Mínimo), 24x24 pixels CSS. Auditar botões, links de ícone e toggles pequenos. Controles menores que 24x24 precisam de área de clique maior, mais espaço ao redor, ou um controle equivalente maior na página. Falha 2.2 mais comum em sites existentes.
2. 2.4.11 Foco Não Obscurecido (Mínimo). Procurar barras pegajosas no rodapé, footers pegajosos, widgets de chat, banners de cookies que sobrepõem o fundo da viewport. Quando um elemento focalizável rola atrás de um deles, o critério falha. Conserto: scroll-margin-bottom em elementos focalizáveis igual à altura da barra pegajosa.
3. 3.3.8 Autenticação Acessível (Mínimo). Remover CAPTCHA de imagem dos fluxos de login; substituir por CAPTCHA invisível ou abordagem por limite de taxa. Permitir gerenciadores de senha (não desabilitar autocomplete em campos de senha). Permitir colar códigos one-time.
4. 2.5.7 Movimentos de Arrastar. Fornecer alternativa não-arrastar para qualquer interação só-arrastar. Listas ordenáveis: setas cima/baixo. Sliders: input numérico. Mapas: botões de pan.
5. 3.2.6 Ajuda Consistente. Se seu link «Contato» ou «Ajuda» aparece em múltiplas páginas, posicione consistentemente.
6. 3.3.7 Entrada Redundante. Formulários multi-etapa precisam lembrar entradas anteriores.

Armadilhas comuns implementando os novos critérios

• Tratar 4.1.1 Parsing como ido em toda parte. 4.1.1 está removido da WCAG 2.2 mas ainda exigido por WCAG 2.0 e 2.1. Se seu contrato ou regulação especifica 2.1, a regra de parsing ainda se aplica.
• Ler errado 2.5.8 Tamanho de Alvo. O mínimo 24x24 é para o alvo, não o ícone visível. Um ícone 16x16 dentro de um botão 24x24 passa. Um ícone 16x16 num botão 16x16 falha.
• Esquecer exceções a 2.5.8. Links inline em parágrafo, controles user-agent padrão, alvos essenciais e controles equivalentes maiores em outro lugar da página são isentos.
• Implementar 3.3.8 removendo todo CAPTCHA. Você pode manter CAPTCHA; só precisa de um caminho alternativo acessível. Testes de Turing reversos, limites de taxa, magic links, passkeys ou tokens de hardware qualificam.
• 2.4.11 confundido com 2.4.13. Foco Não Obscurecido (2.4.11) é sobre se o elemento com foco é visível em geral. Aparência do Foco (2.4.13) é sobre o próprio indicador ser espesso e contrastado. São requisitos diferentes em níveis diferentes.
• Pular 2.4.13 porque é AAA. Vários governos (Noruega, partes do Canadá) adotaram regras nível AAA para sites do setor público.

Ferramentas para checar conformidade WCAG 2.2

Ferramentas automatizadas capturam cerca de 30 a 40 % das falhas WCAG mesmo no melhor caso. Os novos critérios 2.2 são particularmente difíceis de automatizar (2.5.7, 3.2.6, 3.3.7, 3.3.8) porque exigem entender fluxo de usuário, não só markup. Planeje teste manual de teclado a cada release.

Privacidade e as ferramentas

O verificador de contraste, o verificador de cabeçalhos WCAG e o gerador de paleta acessível no Absolutool rodam todos inteiramente no seu navegador. O HTML ou valores de cor que você cola são processados por JavaScript no seu dispositivo, os resultados renderizados na página, e nada é enviado a um servidor. Sem telemetria sobre a entrada, sem scripts de terceiros tocando o conteúdo, sem cache depois de navegar. Para auditorias internas de design system, cores de marca ainda não lançadas, ou qualquer dado de auditoria sob embargo, esse fluxo estritamente local é o padrão correto. As ferramentas podem rodar offline depois que a página carrega, o que você pode verificar desligando a rede e rechecando um par de contraste.