WCAG 2.2 nível AA: o que mudou e como verificar

A WCAG 2.2 acrescentou nove critérios de sucesso à WCAG 2.1 e retirou um, o 4.1.1 (Parsing). Dos nove, seis entram na conta de quem precisa do nível AA: quatro são de nível AA (2.4.11, 2.5.7, 2.5.8 e 3.3.8) e dois são de nível A (3.2.6 e 3.3.7), que o AA também exige. Os outros três são de nível AAA. Todo o resto da 2.1 continua igual, então um site que já cumpria a 2.1 AA precisa testar esses seis pontos e pode deixar de testar o 4.1.1.

O texto trata da WCAG 2.2 na edição de 12 de dezembro de 2024, a vigente em outubro de 2026, e da relação dela com a ABNT NBR 17225:2025 no Brasil.

O que é a WCAG 2.2

As Diretrizes de Acessibilidade para Conteúdo Web (WCAG, na sigla em inglês) são a recomendação do W3C, o consórcio que mantém os padrões da web, sobre como tornar páginas usáveis por pessoas com deficiência. Cada exigência testável se chama critério de sucesso e tem número (por exemplo, 1.4.3), nome e nível: A, AA ou AAA.

A versão 2.2 virou Recomendação do W3C em 5 de outubro de 2023, segundo a página What's New in WCAG 2.2. A edição atual é de 12 de dezembro de 2024. O W3C afirma que conteúdo que cumpre a 2.2 também cumpre a 2.0 e a 2.1; as versões anteriores seguem válidas, mas a recomendação é adotar a 2.2 (WCAG 2.2, seção de introdução). A WCAG 3.0 ainda é rascunho de trabalho e não substitui a 2.2.

Níveis de conformidade: A, AA e AAA

Os níveis são cumulativos. Para declarar um nível, a página precisa atender a todos os critérios dele e dos níveis abaixo (WCAG 2.2, 5.2.1).

Além do nível, a WCAG tem outros quatro requisitos de conformidade (WCAG 2.2, 5.2):

• A conformidade vale para a página inteira. Não dá para excluir um pedaço, e cada variação responsiva da página (celular, tablet, desktop) também precisa cumprir.

• Num processo de várias etapas, como um checkout, todas as etapas precisam cumprir o nível. Se uma falha, nenhuma página do processo pode declarar conformidade.

• Só contam as formas de usar a tecnologia que funcionam com recursos de acessibilidade (o W3C chama de "accessibility supported").

• O que não cumpre não pode impedir o uso do resto da página. É o requisito de não interferência.

Os nove critérios novos da WCAG 2.2

Os nomes em português abaixo são traduções deste texto; a NBR 17225 usa nomes próprios, listados mais adiante. Fonte: WCAG 2.2, New Features e o texto de cada critério.

Para não mudar a numeração antiga, os critérios novos foram colocados no fim de cada diretriz. Por isso a posição de um critério dentro da diretriz não indica o nível dele; o nível aparece em cada critério.

O que saiu: 4.1.1 Parsing

O 4.1.1 pedia HTML bem formado: tags completas, aninhamento correto, nenhum atributo duplicado e IDs únicos. Ele existia porque tecnologias assistivas, como leitores de tela, liam o HTML diretamente. Segundo o W3C, isso deixou de acontecer, e os problemas que ele cobria não existem mais ou já são cobertos por outros critérios (WCAG 2.2, 4.1.1). Na própria WCAG 2.1, uma nota acrescentada depois manda considerar o critério sempre atendido em conteúdo HTML ou XML (WCAG 2.1, 4.1.1).

Duas ressalvas. Quem está obrigado por contrato ou política a cumprir a WCAG 2.0 ou 2.1 pode ainda precisar testar e relatar o 4.1.1, como o W3C avisa. E o documento Understanding Parsing diz que muitos problemas que falhariam no 4.1.1 agora falham em 1.3.1 (Informações e relações) ou 4.1.2 (Nome, função, valor). Um ID repetido que faz um label apontar para o campo errado é o tipo de erro que continua contando.

Como verificar cada critério novo dos níveis A e AA

Ferramentas automáticas ajudam, mas o W3C é direto: elas não determinam se um site é acessível, só ajudam nessa avaliação, e parte das verificações exige julgamento humano (Selecting Web Accessibility Evaluation Tools). O mesmo limite vale para os widgets instalados por cima do site, discutido em overlay de acessibilidade resolve a lei?. Os seis critérios abaixo dependem bastante de teste manual.

2.4.11 Foco não encoberto (mínimo)

Falha quando um cabeçalho fixo, um rodapé fixo, um banner de cookies ou uma janela de chat cobre por inteiro o elemento que acabou de receber foco. O W3C cita o banner de cookies como falha quando esconde totalmente o elemento focado; um modal bem construído passa, porque o usuário precisa fechá-lo antes de continuar (Understanding 2.4.11).

1. Abra a página como um visitante novo, com o banner de cookies e o chat ainda na tela.

2. Navegue só com Tab, e Shift+Tab para voltar, do início ao fim da página.

3. Em cada parada, confira se o elemento em foco aparece pelo menos em parte. Escondido por completo é falha. Parcialmente coberto atende ao AA; o AAA (2.4.12) pede que nada fique coberto.

4. Repita na largura de celular, onde cabeçalhos fixos ocupam mais espaço.

Uma correção comum é a propriedade CSS scroll-padding, que reserva espaço para o cabeçalho ou rodapé fixo e faz a rolagem parar com o elemento visível. É a técnica C43 do W3C.

2.5.7 Movimentos de arrastar

Afeta listas reordenáveis, sliders, mapas, quadros kanban e carrosséis que só respondem a arrastar. Funcionar com teclado não resolve: o W3C diz que a equivalência por teclado não cumpre este critério por si só, porque quem usa tela de toque pode não ter teclado (Understanding 2.5.7).

1. Liste os componentes que respondem a arrastar.

2. Em cada um, tente fazer a mesma ação só com cliques ou toques simples, sem segurar e mover.

3. Se não houver caminho, é falha. Alternativas que o W3C aceita: botões de mover para cima e para baixo, clique em qualquer ponto da trilha do slider, botões de direção no mapa, um campo para digitar o valor.

2.5.8 Tamanho do alvo (mínimo)

Alvo é a área que recebe o clique ou o toque de um link, botão ou controle. Ele precisa ter pelo menos 24 por 24 pixels CSS, a unidade de medida do CSS, que não depende da densidade da tela. Um alvo menor passa se valer uma destas exceções (WCAG 2.2, 2.5.8):

• Espaçamento: um círculo de 24 pixels CSS de diâmetro, centrado no alvo, não encosta em outro alvo nem no círculo de outro alvo pequeno.

• Equivalente: a mesma função existe em outro controle da página que cumpre o tamanho.

• Em linha: o alvo está dentro de uma frase, como um link no meio do parágrafo.

• Controle do navegador: o tamanho é o padrão do navegador e o site não mexeu nele.

• Essencial: aquela apresentação é essencial ou exigida por lei.

Para testar, meça no DevTools os controles pequenos: fechar modal, ícones de redes sociais, paginação, filtros, setas de carrossel. No exemplo do W3C, seis ícones de 20 pixels colados falham, e os mesmos ícones com 4 pixels de espaço entre eles passam (Understanding 2.5.8). O critério AAA equivalente, 2.5.5, pede 44 por 44 pixels CSS.

3.2.6 Ajuda consistente (nível A)

O critério vale para quatro tipos de ajuda: dados de contato de uma pessoa (telefone, e-mail, horário), mecanismo de contato com uma pessoa (chat com atendente, formulário de contato), autoatendimento (como uma página de perguntas frequentes) e contato totalmente automatizado (como um chatbot). Se um deles se repete em várias páginas, ele aparece na mesma ordem em relação ao resto do conteúdo, salvo quando o próprio usuário muda algo (WCAG 2.2, 3.2.6). O critério não obriga o site a oferecer ajuda; ele pede consistência quando a ajuda existe.

1. Escolha páginas de tipos diferentes: inicial, categoria, produto, carrinho, contato.

2. Anote a posição de cada mecanismo de ajuda na ordem do código, que é a ordem de leitura do leitor de tela, e não só na posição visual.

3. Compare páginas na mesma largura de tela e no mesmo zoom. A WCAG compara a ordem dentro da mesma variação da página.

3.3.7 Entrada redundante (nível A)

No mesmo processo, o site não pede de novo um dado que o usuário já deu, a menos que o traga preenchido ou ofereça para seleção. O exemplo clássico é a opção "endereço de entrega igual ao de cobrança". O preenchimento automático do navegador não conta, porque quem precisa oferecer o dado é o site (Understanding 3.3.7). As exceções são três: digitar de novo é essencial, o pedido existe por segurança (como confirmar uma senha nova) ou o dado anterior deixou de valer.

1. Percorra os fluxos de várias etapas: cadastro, checkout, orçamento, agendamento.

2. Anote cada campo que pede algo já informado antes no mesmo fluxo.

3. Confira se ele vem preenchido ou se existe opção de reaproveitar.

4. Provoque um erro de envio e veja se o formulário mantém o que foi digitado. O W3C usa o caso de um número de cartão que não deveria ser apagado depois de uma falha.

3.3.8 Autenticação acessível (mínimo)

Teste de função cognitiva, na definição da WCAG, é uma tarefa que exige lembrar, manipular ou transcrever informação: decorar senha, digitar caracteres, acertar a grafia, fazer contas, resolver quebra-cabeça. Nome, e-mail e telefone não contam, porque são do próprio usuário e iguais em todo site (WCAG 2.2, glossário). O login pode ter uma etapa assim desde que ofereça uma alternativa sem esse teste ou um mecanismo que ajude a cumpri-lo. Segundo o Understanding 3.3.8:

• Campo de senha que aceita gerenciador de senhas e colar atende. Bloquear o colar ou o preenchimento automático é falha, salvo se houver alternativa.

• CAPTCHA que pede para digitar caracteres distorcidos falha sem alternativa. Um áudio que pede para transcrever o que se ouve não vale como alternativa.

• CAPTCHA de reconhecer objetos é aceito no nível AA, mas não no AAA (3.3.9).

• Código de verificação em duas etapas precisa aceitar colar. Exigir que a pessoa digite o código à mão não cumpre o critério.

• Link de acesso enviado por e-mail e login com um provedor externo via OAuth aparecem como formas de cumprir.

Para testar, abra o login com um gerenciador de senhas e veja se ele preenche usuário e senha; tente colar a senha e o código de verificação; identifique se há CAPTCHA e de que tipo.

Relação com a NBR 17225 e com a LBI

A Lei Brasileira de Inclusão (Lei 13.146/2015), no art. 63, torna obrigatória a acessibilidade nos sites de empresas com sede ou representação comercial no país e de órgãos de governo, "conforme as melhores práticas e diretrizes de acessibilidade adotadas internacionalmente" (Lei 13.146/2015). A lei não cita a WCAG pelo nome.

A ABNT NBR 17225:2025, "Acessibilidade em conteúdo e aplicações web: Requisitos", tem primeira edição de 11 de março de 2025 e segue os critérios de sucesso da WCAG 2.2. Ela separa os itens em requisitos e recomendações e define dois tipos de conformidade (ABNT NBR 17225:2025, seção 4):

• Conformidade regular: todos os requisitos atendidos. A norma diz que ela está alinhada ao nível AA da WCAG 2.2, de modo que um site em conformidade regular também cumpre os níveis A e AA.

• Conformidade plena: requisitos e recomendações, com justificativa razoável para cada recomendação não atendida.

Os critérios novos da 2.2 aparecem na norma com nomes próprios:

O 4.1.1 aparece no anexo A da norma (A.1.9), que repete a explicação do W3C de que o critério não é mais necessário. Um ponto em que a NBR vai além do AA da WCAG: o item 5.11.6 traz como requisito um contraste de pelo menos 3:1 para o indicador de foco, com base nos critérios 1.4.11 (AA) e 2.4.13 (AAA). Quem audita pela norma brasileira deve testar esse item mesmo que a 2.4.13 seja AAA na WCAG.

Quem está obrigado pela lei e o que ela pede estão no guia principal desta série, LBI e NBR 17225: o que a lei exige de um site. Este texto explica a norma técnica; não é parecer jurídico.

Como verificar o seu site

A checagem grátis do WebVyze analisa a página inicial, sem cadastro, e aponta riscos de acessibilidade ligados à lei. Ela cobre a parte automatizável. Critérios como foco encoberto, arrastar, ajuda consistente e autenticação pedem alguém navegando pelo site, como descrito acima. Para os dois temas que mais aparecem em auditoria, veja os guias de contraste de cores e de formulários acessíveis.