WCAG 2.2: o que mudou em relação à WCAG 2.1, os nove critérios novos e como testar cada um

A resposta curta

A WCAG 2.2 acrescenta nove critérios de sucesso à WCAG 2.1 e retira um, o 4.1.1 Análise. Seis dos novos estão nos níveis A e AA, os que leis, normas e contratos exigem: o foco não pode ficar escondido atrás de elementos fixos, tudo o que se faz arrastando precisa ter alternativa, os alvos de toque e clique precisam de 24 por 24 pixels CSS, a ajuda precisa ficar no mesmo lugar, o usuário não pode ter de digitar de novo o que já informou, e o login não pode exigir memória nem quebra-cabeças. Os outros três são de nível AAA.

É uma ampliação, não uma versão nova do zero. O W3C afirma, na WCAG 2.2, que o conteúdo em conformidade com a 2.2 também está em conformidade com a 2.1 e a 2.0. Um site que já cumpre a 2.1 AA precisa ser testado só nos seis critérios novos de nível A e AA para chegar à 2.2 AA. No Brasil, essa é também a base da ABNT NBR 17225.

Os nomes dos critérios abaixo são os da tradução autorizada da WCAG 2.2 para o português do Brasil, coordenada pelo Ceweb.br e publicada em 27 de março de 2025. Conferimos este guia nos textos do W3C e nas normas citadas em 17 de outubro de 2026. Onde fala de leis, é material de planejamento, não parecer jurídico.

WCAG 2.1 e 2.2 em números

A WCAG 2.2 virou Recomendação do W3C em 5 de outubro de 2023, e a edição atual é de 12 de dezembro de 2024. Em outubro de 2025 foi aprovada como a norma ISO/IEC 40500:2025, que, segundo a visão geral da WCAG do W3C, é exatamente igual à versão de outubro de 2023.

Contamos os critérios de sucesso da WCAG 2.0, da WCAG 2.1 e da 2.2:

Estar em conformidade com o nível AA significa cumprir todos os critérios dos níveis A e AA: 50 na WCAG 2.1 e 55 na WCAG 2.2. A diferença são os seis critérios novos de nível A e AA menos o 4.1.1, que era de nível A.

Os nove critérios novos

Os critérios e níveis vêm da página What's new in WCAG 2.2 do W3C; a coluna do meio resume o texto normativo, e a última traz o teste mais rápido que conhecemos para cada um.

O critério que saiu: 4.1.1 Análise

O 4.1.1 pedia marcação bem formada: tags completas, elementos bem aninhados, sem atributos duplicados e com IDs únicos. A WCAG 2.2 o marca como "obsoleto e removido", porque as tecnologias assistivas não analisam mais o HTML diretamente. O FAQ da WCAG 2 do W3C diz que os problemas que falhariam no 4.1.1 vão falhar em outros critérios, como o 1.3.1 Informações e Relações e o 4.1.2 Nome, Função, Valor.

A mudança chegou às versões anteriores. O mesmo FAQ informa que a WCAG 2.1 foi atualizada em 21 de setembro de 2023, e a 2.0 ganhou uma errata, com uma nota dizendo que o 4.1.1 deve ser considerado sempre atendido em conteúdo HTML ou XML.

Na prática: se um contrato, um edital ou um checklist ainda listar o 4.1.1, informe o resultado. Passar os templates principais no validador do W3C é uma evidência barata.

Qual versão da WCAG cada norma pede

Poucas regras citam a 2.2. Esta tabela reúne as que mais importam para uma empresa brasileira, inclusive as dos mercados para onde ela vende:

Qual versão adotar?

A WCAG 2.2 nível AA. Ela atende a todas as regras da tabela que citam a 2.0 ou a 2.1, é a base das normas mais novas do Brasil e da Europa, e o W3C recomenda usar a versão mais recente. No Brasil, a NBR 17225 organiza os requisitos por componente e tem itens próprios além da WCAG; em acessibilidade digital e a Lei Brasileira de Inclusão analisamos a norma e mostramos a correspondência entre os critérios novos da 2.2 e os itens dela. Se você vende para a Europa, veja também o nosso guia da Lei Europeia de Acessibilidade.

Escreva "WCAG 2.2 AA" no briefing e no contrato de qualquer site novo; assim você não precisa testar de novo quando uma regra for atualizada.

Como testar e corrigir os seis critérios A e AA

São eles que mudam o resultado de um site que já cumpre a 2.1 AA. Para cada um: onde costuma falhar, como testar e a correção habitual.

2.4.11 Foco não Obscurecido (Mínimo)

Onde falha: cabeçalhos e rodapés fixos, o aviso de cookies, o botão flutuante de WhatsApp ou de chat e pop-ups não modais que cobrem o elemento em que o usuário de teclado acabou de chegar. O W3C lista o cabeçalho ou rodapé fixo que esconde por completo o elemento em foco como uma falha conhecida (F110). Ficar parcialmente coberto é aceito neste nível; o 2.4.12, de nível AAA, não aceita nem isso.

Como testar: avance e volte com Tab e Shift+Tab em cada template, primeiro com todos os avisos e botões visíveis, depois com eles fechados. Repita com zoom de 200% e na largura de um celular, onde os elementos fixos ocupam mais tela.

A correção: reserve a altura do cabeçalho fixo com scroll-padding-top no CSS (técnica C43), para o navegador rolar o elemento em foco para fora dele. Faça o aviso de cookies não cobrir o conteúdo, ou ser modal, e reveja se cada elemento fixo precisa mesmo ser fixo.

2.5.7 Movimentos de Arrastar

Onde falha: sliders de faixa de preço, listas reordenáveis, quadros kanban, mapas que se movem arrastando e áreas de "arraste o arquivo aqui".

Como testar: liste tudo o que se move arrastando e tente fazer o mesmo só com cliques ou toques. O documento Understanding 2.5.7 do W3C observa que uma alternativa por teclado não cumpre o critério automaticamente: ela precisa funcionar com um único ponteiro, clicando ou tocando.

A correção: deixe que um clique em qualquer ponto da trilha do slider defina o valor, ponha botões de subir e descer ou um menu "mover para" ao lado dos itens reordenáveis, botões de direção nos mapas e um botão "escolher arquivo" junto de toda área de soltar arquivos.

2.5.8 Tamanho do Alvo (Mínimo)

Onde falha: ícones de redes sociais, o X que fecha janelas, números de paginação, pontos de carrossel, dias de calendário e botões de ícone colados em barras de ferramentas.

Como testar: nas ferramentas do desenvolvedor, meça a área clicável, não o desenho do ícone. Um alvo de 24 por 24 pixels CSS ou maior passa. Um menor passa se um círculo de 24 pixels centrado nele não tocar outro alvo nem o círculo de outro alvo pequeno: nos exemplos do Understanding 2.5.8, botões de 20 por 20 pixels com 4 pixels de distância passam, e os mesmos botões colados falham. Links dentro de uma frase estão isentos, assim como controles que o navegador desenha e você não estilizou.

A correção: aumente a área clicável com padding sem mudar o ícone, afaste os alvos pequenos e corrija o tamanho nos componentes de botão e ícone do design system, para que todas as páginas herdem a correção. 24 pixels é o mínimo; o critério 2.5.5 Tamanho do Alvo (Melhorado), de nível AAA, pede 44 por 44, uma meta melhor para as ações principais no celular.

3.2.6 Ajuda Consistente

Onde falha: telefone no cabeçalho em algumas páginas e no rodapé em outras, o botão de WhatsApp que só aparece em alguns templates e em posições diferentes, ou o link de ajuda que muda de lugar no menu.

Como testar: abra cinco páginas de templates diferentes, com a mesma largura e o mesmo zoom, e anote a ordem dos mecanismos de ajuda (dados de contato, formulário ou chat de contato, páginas de autoajuda como perguntas frequentes, e chatbots) em relação ao resto do conteúdo. O que se compara é a ordem, não a posição em pixels. O critério não obriga a oferecer ajuda; vale quando você oferece.

A correção: coloque a ajuda em um componente compartilhado do cabeçalho ou do rodapé, não em blocos que cada editor posiciona à mão.

3.3.7 Entrada Redundante

Onde falha: checkouts que pedem de novo o endereço de entrega como endereço de cobrança, cadastros de várias etapas que pedem o CPF ou o e-mail duas vezes, e formulários que apagam todos os campos depois de um erro de validação.

Como testar: percorra cada processo de várias etapas do início ao fim, inclusive voltando uma etapa, e liste cada dado pedido mais de uma vez. Pedir de novo é permitido quando é essencial, quando é necessário por segurança (como confirmar uma senha nova) ou quando o dado anterior deixou de valer.

A correção: carregue os dados entre etapas, preencha o que você já sabe, ofereça opções como "usar o mesmo endereço" e mostre um resumo com links para editar no final.

3.3.8 Autenticação Acessível (Mínimo)

Onde falha: telas de login que bloqueiam colar ou o preenchimento do gerenciador de senhas, teclados virtuais em que a senha só pode ser digitada clicando, códigos de verificação divididos em seis caixas que só aceitam um dígito colado, e captchas de texto distorcido ou de contas.

Como testar: entre usando um gerenciador de senhas e cole o código recebido por SMS ou e-mail. Verifique todas as etapas, inclusive a autenticação em dois fatores e a recuperação de senha. Segundo o Understanding 3.3.8, uma senha passa se o gerenciador puder preenchê-la ou o usuário puder colá-la; exigir que o usuário transcreva um código à mão falha; e, no nível AA, um captcha que pede para reconhecer objetos, como escolher as fotos com carros, é permitido, enquanto os de texto distorcido e de contas não são. Pela mesma lógica, um teclado virtual que impede colar e usar o gerenciador falha, a menos que exista outro jeito de entrar.

A correção: marque os campos com os valores certos de autocomplete (username, current-password, one-time-code), permita colar em todos os campos e ofereça um método que não exija memória, como chaves de acesso (passkeys), um link de acesso por e-mail ou o login com outro provedor. Troque captchas de quebra-cabeça por verificações que não pedem nada ao usuário, como limitar as tentativas.

Os três critérios de nível AAA

Poucas regras exigem o nível AAA, mas dois destes saem barato depois do trabalho de nível AA:

• 2.4.12 Foco não Obscurecido (Melhorado): nenhuma parte do elemento em foco fica escondida. Se você corrigiu o 2.4.11 com scroll-padding, já fez quase tudo.
• 2.4.13 Aparência do Foco: indicador de foco com pelo menos a área de um contorno de 2 pixels CSS e contraste de 3:1 em relação ao estado sem foco. Um contorno sólido de pelo menos 2 pixels, definido uma vez como token do design system, costuma cobrir a área; confira o contraste.
• 3.3.9 Autenticação Acessível (Melhorado): como o 3.3.8, mas reconhecer objetos ou conteúdo pessoal deixa de ser exceção. Chaves de acesso e links por e-mail evitam testes cognitivos por completo.

Como levar um site da WCAG 2.1 AA para a 2.2 AA

1. Teste só o que mudou. Aplique os seis critérios novos de nível A e AA aos seus templates e processos completos: cadastro, login, checkout ou agendamento, contato.
2. Corrija nos componentes. Estilos de foco, tamanho dos alvos, elementos fixos e campos de formulário vivem em poucos componentes compartilhados; corrigi-los uma vez corrige todas as páginas.
3. Teste de novo o login com cada método que você oferece, inclusive login social, dois fatores e recuperação de senha.
4. Atualize a documentação. Troque a versão citada na sua declaração de acessibilidade e a meta do contrato com fornecedores.
5. Guarde evidência do 4.1.1 se um contrato ou edital ainda o exigir.
6. Escreva WCAG 2.2 AA nos novos briefings e contratos, para o próximo redesign já começar na versão atual.

Próximos passos

A nossa checklist WCAG 2.2 gratuita tem um filtro "Novos na 2.2" que mostra exatamente estes critérios, cada um como uma pergunta simples, com como testar, a correção habitual e o item correspondente da NBR 17225, e monta um plano priorizado com as suas respostas. Para planejar o orçamento de uma auditoria, veja quanto custa uma auditoria de acessibilidade. Se preferir que a Dardo teste e corrija, a nossa auditoria de acessibilidade web cobre a WCAG 2.2 AA com testes manuais e parte de USD 690, como mostra a nossa página de preços.