QualiBooth

wcag

WCAG 2.1 vs 2.2: O Que Mudou e Por Que Importa

Uma análise clara de todas as alterações entre a WCAG 2.1 e a WCAG 2.2 — novos critérios de sucesso, o que foi removido e o que o seu site tem de corrigir para se manter conforme.

7 min read QualiBooth
Arte digital abstrata que representa a monitorização contínua da acessibilidade e as verificações de conformidade com a WCAG.

A WCAG 2.2 tornou-se Recomendação do W3C em outubro de 2023. Se o seu site foi auditado face à WCAG 2.1, é possível que já esteja a falhar em critérios que hoje definem a conformidade legal na UE, no Reino Unido e, cada vez mais, nas ações de fiscalização nos EUA. Este guia percorre todas as alterações — o que foi acrescentado, o que foi removido e o que cada critério significa na prática.

Contexto rápido: o que a WCAG 2.1 acrescentou

A WCAG 2.1 (publicada em 2018) alargou a norma 2.0 original com 17 novos critérios de sucesso centrados em três grupos até então mal servidos:

  • Utilizadores móveis — gestos táteis, orientação do ecrã, precisão do ponteiro
  • Utilizadores com baixa visão — redisposição do conteúdo, contraste de elementos não textuais, espaçamento do texto
  • Deficiências cognitivas e de linguagem — tempos limite, mensagens de estado

A WCAG 2.2 assenta diretamente na 2.1. Todos os requisitos da 2.1 continuam a aplicar-se. A questão é: o que é que a 2.2 acrescentou por cima?

O que a WCAG 2.2 acrescentou: 9 novos critérios de sucesso

2.4.11 Foco Não Obscurecido (Mínimo) — Nível AA

Quando um componente recebe o foco do teclado, não pode ficar totalmente escondido por outro conteúdo (cabeçalhos fixos, banners de cookies, widgets de chat). Pelo menos parte do elemento em foco tem de permanecer visível.

Falha comum: uma barra de navegação fixa tapa o campo de formulário em foco quando o utilizador percorre a página com o Tab.

2.4.12 Foco Não Obscurecido (Aprimorado) — Nível AAA

Versão mais exigente do 2.4.11 — o componente em foco tem de estar totalmente visível, e não apenas parcialmente.

2.4.13 Aparência do Foco — Nível AA

Os indicadores de foco do teclado têm de cumprir limiares mínimos de tamanho e contraste:

  • A área do indicador de foco tem de ser, no mínimo, tão grande quanto um perímetro de 2 pixels CSS em redor do componente
  • O contraste entre os estados com e sem foco tem de ser de, pelo menos, 3:1

Isto vai mais longe do que o já existente 2.4.7 (Foco Visível), que apenas exigia que existisse algum indicador de foco.

Falha comum: um contorno pontilhado fino de 1px com baixo contraste passa no 2.4.7 mas falha no 2.4.13.

2.5.7 Movimentos de Arrastar — Nível AA

Qualquer ação que exija arrastar tem de poder ser realizada também com um único ponteiro (toque ou clique). Isto serve os utilizadores com deficiências motoras que não conseguem controlar operações de arrastar de forma fiável.

Exemplo: uma lista ordenável tem de oferecer uma alternativa (como botões para cima/para baixo) aos utilizadores que não conseguem arrastar itens.

2.5.8 Tamanho do Alvo (Mínimo) — Nível AA

Os alvos interativos (botões, ligações, controlos de formulário) têm de ter, no mínimo, 24×24 pixels CSS — ou dispor de espaçamento suficiente face aos alvos adjacentes para que a área total de ativação cumpra o limiar.

Esta é a versão mínima. O critério aprimorado (2.5.5, herdado da 2.1 no Nível AAA) recomenda 44×44px.

Falhas comuns: botões apenas com ícone, ícones de fechar (×) e ligações de texto em linha em menus de navegação apertados.

3.2.6 Ajuda Consistente — Nível A

Se um site oferece um mecanismo de ajuda (número de telefone, ligação para chat, formulário de contacto, ligação para FAQ), este tem de aparecer na mesma posição relativa em todas as páginas em que está presente. Os utilizadores com deficiências cognitivas dependem muitas vezes de uma colocação previsível.

3.3.7 Introdução Redundante — Nível A

A informação que um utilizador já submeteu na mesma sessão não pode voltar a ser exigida — a menos que a reintrodução seja essencial (por exemplo, um campo de confirmação de palavra-passe) ou que os dados sejam sensíveis do ponto de vista da segurança.

Exemplo: um processo de compra com vários passos não deve pedir a morada de faturação no passo 3 se o utilizador já a introduziu no passo 1.

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

Os passos de autenticação não podem depender de um teste de função cognitiva — reconhecer objetos, transcrever carateres ou resolver enigmas — a menos que seja fornecida uma alternativa ou que o teste consista em reconhecer conteúdo controlado pelo utilizador (como uma fotografia que o próprio carregou).

Falhas comuns: CAPTCHA que exigem identificar texto distorcido sem alternativa áudio, ou desafios do tipo «clique em todas as imagens com semáforos».

3.3.9 Autenticação Acessível (Aprimorado) — Nível AAA

A versão aprimorada elimina até a exceção relativa ao conteúdo controlado pelo utilizador. Não é permitido qualquer teste de função cognitiva no fluxo de autenticação.

O que a WCAG 2.2 removeu: 4.1.1 Análise Sintática

A WCAG 2.1 incluía o 4.1.1 Análise Sintática (Nível A), que exigia HTML bem formado — IDs de elemento únicos, etiquetas corretamente aninhadas e pares completos de etiquetas de abertura e fecho. Os navegadores modernos tornaram-se tão bons a corrigir silenciosamente HTML malformado que este critério deixou de ser mensurável na prática.

Na WCAG 2.2, o 4.1.1 Análise Sintática está marcado como obsoleto e é sempre considerado cumprido. Já não precisa de o auditar, embora escrever HTML limpo continue a ser uma boa prática.

Tabela-resumo

CritérioNívelTema
2.4.11 Foco Não Obscurecido (Mín.)AAFoco do teclado
2.4.12 Foco Não Obscurecido (Aprimorado)AAAFoco do teclado
2.4.13 Aparência do FocoAAIndicador de foco
2.5.7 Movimentos de ArrastarAAEntrada por ponteiro
2.5.8 Tamanho do Alvo (Mínimo)AAAlvos táteis
3.2.6 Ajuda ConsistenteAPrevisibilidade
3.3.7 Introdução RedundanteAFormulários
3.3.8 Autenticação Acessível (Mín.)AAInício de sessão / CAPTCHA
3.3.9 Autenticação Acessível (Aprimorado)AAAInício de sessão / CAPTCHA
4.1.1 Análise SintáticaARemovido

Quem precisa de atualizar?

Praticamente toda a gente. A WCAG 2.2 é agora a referência de base invocada por:

  • O European Accessibility Act (EAA), em vigor desde junho de 2025
  • A norma harmonizada EN 301 549 (atualizada para remeter para a WCAG 2.2)
  • Os regulamentos de acessibilidade dos organismos do setor público do Reino Unido (orientações atualizadas)
  • Muitas leis estaduais dos EUA e posições informais de fiscalização do DOJ

Se a sua última auditoria completa foi feita face à WCAG 2.1 AA, concentre o esforço de atualização nestes cinco critérios, que afetam a maioria dos sites: 2.4.11, 2.4.13, 2.5.8, 3.3.8 e 3.3.7 (se tiver formulários ou processos de compra com vários passos).

Como auditar os novos critérios

A maioria dos analisadores automáticos já sinaliza o 2.5.8 (tamanho do alvo) e casos parciais do 2.4.13 (aparência do foco). No entanto, os seguintes exigem teste manual:

  • 2.4.11 / 2.4.12 — percorra todas as páginas com o Tab, com cabeçalhos/rodapés fixos ativos, e confirme que os elementos em foco ficam visíveis
  • 2.4.13 — meça as dimensões e o contraste do indicador de foco com as DevTools do navegador ou um verificador de contraste
  • 2.5.7 — identifique todas as interações de arrastar e verifique se existe uma alternativa apenas com ponteiro
  • 3.2.6 — confirme que as ligações de ajuda surgem em posições consistentes em todas as páginas
  • 3.3.7 — percorra todos os fluxos com vários passos e confirme que não são pedidos dados duas vezes
  • 3.3.8 — teste todos os passos de início de sessão, registo e verificação em busca de testes de função cognitiva

A WCAG 2.2 não é uma reformulação total — é um conjunto direcionado de acrescentos que resolvem barreiras reais que a 2.1 deixou passar. A boa notícia é que a maioria dos novos critérios AA pode ser resolvida com trabalho de remediação focado, em vez de uma reconstrução completa do site.

Relacionado: Como Tornar o Seu Site Conforme à WCAG 2.2 · Guia de Auditorias Manuais de Acessibilidade

Precisa de ajuda para auditar o seu site face à WCAG 2.2?