O que há de novo nas WCAG 2.2? Os 9 critérios explicados

Uma pessoa percorre o seu checkout com o teclado. O foco chega ao botão «Pagar agora», mas por cima dele está uma faixa de cookies fixa e a pessoa não consegue ver onde está. Com as WCAG 2.1, essa página ainda podia passar. Com as WCAG 2.2, falha.

É este tipo de lacuna que a atualização 2.2 fecha. Abaixo, cada novo critério de sucesso tem o mesmo tratamento: o que diz, a quem ajuda, um teste rápido e a correção habitual. Para ver os quatro princípios e os níveis numa só página, consulte a nossa referência das WCAG 2.2.

O que são as WCAG 2.2?

As WCAG 2.2 são a versão atual das Diretrizes de Acessibilidade para o Conteúdo da Web, a norma do W3C para a qual remete a maioria das leis e contratos de acessibilidade. Tornaram-se Recomendação do W3C a 5 de outubro de 2023 (abre num novo separador), foram atualizadas a 12 de dezembro de 2024 (abre num novo separador) e, em outubro de 2025, foram aprovadas como norma ISO/IEC 40500:2025 (abre num novo separador).

As WCAG são compostas por afirmações testáveis chamadas critérios de sucesso, cada uma com um nível: A (o mínimo), AA (o que as leis costumam exigir) ou AAA (o mais exigente). «Precisamos das WCAG 2.2 AA» significa cumprir todos os critérios A e AA da versão 2.2. A especificação diz que as 2.2 «se baseiam nas WCAG 2.1 e são retrocompatíveis com elas», ou seja, acrescentam às 2.1 em vez de as substituir.

O que mudou das WCAG 2.1 para as 2.2?

As WCAG 2.2 acrescentam nove critérios de sucesso e retiram um. Seis dos novos são de nível A ou AA, por isso contam para o objetivo habitual AA: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 e 3.3.8. Os outros três são AAA. O critério retirado é o 4.1.1 Análise, que o W3C considera agora obsoleto.

O 4.1.1 Análise verificava erros de marcação, como IDs duplicados. As perguntas frequentes sobre as WCAG 2 (abre num novo separador) explicam que esses problemas passaram a estar abrangidos por outros critérios, como o 4.1.2 Nome, função, valor. Um pormenor: se um contrato ainda exige as WCAG 2.0 ou 2.1, poderá «ter de continuar a testar e a reportar o 4.1.1».

Foco não obscurecido e aparência do foco: quem usa teclado vê onde está?

Estes critérios mantêm visível o elemento com o foco do teclado. No nível AA (2.4.11), uma ligação ou um botão com o foco não pode ficar totalmente escondido por conteúdo que o próprio site acrescentou, como um cabeçalho fixo, uma faixa de cookies ou uma bolha de chat. No nível AAA, nada pode tapar qualquer parte dele (2.4.12), e o contorno do foco tem de ser grande e ter um contraste nítido (2.4.13).

• A quem ajuda: a pessoas que veem e usam o teclado em vez do rato, muitas vezes por causa de uma deficiência motora. Se não veem o foco, estão a adivinhar.
• Teste rápido: abra uma página longa com a faixa de cookies, o cabeçalho fixo e o widget de chat visíveis e prima Tab várias vezes. Se o foco desaparecer completamente atrás de alguma coisa, é uma falha do 2.4.11.
• Correção habitual: acrescente no CSS um scroll-padding igual à altura do cabeçalho ou do rodapé fixos, para que o navegador desloque os elementos com foco até ficarem visíveis. O W3C indica esta solução como técnica suficiente (abre num novo separador). Uma faixa também pode passar se for modal e tiver de ser fechada primeiro.

A aparência do foco (2.4.13) pede um indicador pelo menos tão grande como um contorno de 2 píxeis CSS de espessura à volta do componente, com uma mudança de contraste de pelo menos 3:1 entre o estado com foco e sem foco. É AAA, mas um contorno contínuo de 2 píxeis numa cor forte costuma chegar. O nosso guia sobre contraste de cores explica como medir 3:1.

Movimentos de arrastar e tamanho do alvo: é possível usar o seu site sem apontar com precisão?

Estes dois critérios de nível AA ajudam quem tem dificuldade em controlar o ponteiro com precisão. O 2.5.7 diz que tudo o que se pode fazer a arrastar tem de funcionar também com cliques ou toques simples. O 2.5.8 diz que os alvos têm de ter pelo menos 24 por 24 píxeis CSS, ou estar afastados de forma que um círculo de 24 píxeis centrado em cada um não toque noutro alvo.

2.5.7 Movimentos de arrastar

Pense no controlo deslizante de intervalo de preços nos filtros de uma loja ou numa lista de desejos que se reordena a arrastar. Para alguém com tremores, ou que usa um ponteiro de cabeça, carregar, manter, mover e largar pode ser muito difícil.

Teste rápido: conclua cada tarefa de arrastar só com cliques ou toques. Correção habitual: permita clicar em qualquer ponto da barra do controlo deslizante, acrescente ao lado caixas de «mínimo» e «máximo», ou ponha botões «Mover para cima» e «Mover para baixo» nas listas ordenáveis. O suporte de teclado, por si só, não chega: o documento de compreensão do W3C (abre num novo separador) diz que a equivalência por teclado «não cumpre automaticamente este critério de sucesso».

2.5.8 Tamanho do alvo (mínimo)

As falhas habituais são os pequenos botões «×» das janelas pop-up, números de página muito juntos, classificações por estrelas e filas de ícones de redes sociais. Tocar no errado irrita qualquer pessoa e é uma barreira real para quem tem pouca destreza manual.

• Exceções: ligações dentro de uma frase, alvos com um controlo equivalente noutro ponto da página que cumpre o tamanho, controlos cujo tamanho é definido pelo navegador e que não alterou, e casos em que um determinado tamanho é essencial ou exigido por lei.
• Teste rápido: num telemóvel, experimente cada ícone e botão pequeno; para medir um deles, inspecione-o nas ferramentas de programador do navegador.
• Correção habitual: acrescente padding. A área clicável aumenta mesmo que o ícone pareça igual. E encare os 24 píxeis como um mínimo: o critério AAA mais antigo, o 2.5.5, pede 44 por 44.

Ajuda consistente e entrada redundante: obriga as pessoas a procurar ou a repetir-se?

Ambos são de nível A. O 3.2.6 Ajuda consistente diz que, se uma ajuda como os contactos, um chat ou uma ligação para as perguntas frequentes aparece em várias páginas, tem de estar sempre na mesma ordem em relação ao resto da página. O 3.3.7 Entrada redundante diz que ninguém deve ter de voltar a escrever informação que já deu no mesmo processo.

A ajuda consistente não o obriga a oferecer ajuda. Diz apenas que, se o número de telefone está no cabeçalho das páginas de produto, não deve passar para o rodapé no checkout, precisamente onde as pessoas mais precisam dele. Quem mais beneficia são as pessoas com dificuldades de memória ou de atenção. A correção costuma ser um modelo partilhado, em vez de colocar a ajuda página a página.

A entrada redundante visa os formulários com vários passos. Um formulário de reserva que pede o e-mail no passo 1 e outra vez no passo 3 falha, tal como um checkout que obriga a escrever de novo uma morada de faturação idêntica. Preencha o campo automaticamente ou deixe a pessoa selecioná-lo, por exemplo com uma caixa «A morada de faturação é igual à de entrega». As exceções: quando repetir é essencial, quando é necessário por segurança ou quando a informação anterior já não é válida.

Autenticação acessível: é possível iniciar sessão sem um teste de memória?

O critério de sucesso 3.3.8 (nível AA) diz que nenhum passo do início de sessão pode depender de um teste de função cognitiva, como memorizar uma palavra-passe, escrever caracteres distorcidos ou resolver um quebra-cabeças, a não ser que ofereça uma alternativa ou algo que ajude. Na prática: deixe os gestores de palavras-passe preencher os campos, permita colar e ofereça um método que não dependa da memória.

As WCAG definem o teste de função cognitiva como «uma tarefa que exige que o usuário lembre, manipule, ou transcreva informação» (na tradução autorizada para português do Brasil). Introduzir o nome, o e-mail ou o número de telefone não conta, porque são dados pessoais e sempre iguais. Um passo de início de sessão passa no nível AA se oferecer pelo menos uma destas opções:

• Uma alternativa sem teste cognitivo, como uma chave de acesso (passkey) ou uma ligação enviada por e-mail.
• Um mecanismo que ajude, como o suporte de gestores de palavras-passe ou a possibilidade de copiar e colar, para não ter de escrever de novo um código de utilização única.
• Reconhecimento de objetos, por exemplo «selecione as imagens com uma bicicleta».
• Conteúdo pessoal, como identificar uma imagem que a própria pessoa carregou.

A versão AAA, o 3.3.9, deixa cair as duas últimas opções, por isso um CAPTCHA de imagens pode passar no nível AA, mas não no AAA. Falhas típicas: campos de palavra-passe que impedem colar ou usar gestores de palavras-passe, caixas de código de utilização única que deixam de funcionar quando se cola e um CAPTCHA de texto sem alternativa. Quem mais ganha são as pessoas com dislexia ou dificuldades de memória, mas qualquer pessoa que já ficou sem acesso à conta ao fim de um dia longo reconhece o problema.

As WCAG 2.2 são obrigatórias por lei?

Depende de onde está e de quem é. As leis raramente indicam uma versão das WCAG, e várias ainda remetem para as WCAG 2.1 AA. Como as WCAG 2.2 são retrocompatíveis, cumprir as 2.2 AA significa cumprir as 2.1 AA, à exceção do 4.1.1, que foi retirado. Apontar para as 2.2 cobre ambas. Se um contrato indicar uma versão, siga o contrato.

• União Europeia: no âmbito do Ato Europeu da Acessibilidade, presume-se a conformidade quando se cumpre a norma harmonizada EN 301 549. Segundo o AccessibleEU (abre num novo separador), a versão 4.1.1, publicada em setembro de 2026, adota as WCAG 2.2, mas ainda não é a referência legal; até ser citada no Jornal Oficial, aplica-se a v3.2.1 (baseada nas WCAG 2.1 AA). O nosso guia sobre o Ato Europeu da Acessibilidade explica a quem se aplica.
• Reino Unido: as orientações do governo (abre num novo separador) dizem que os sites e apps do setor público têm de cumprir as WCAG 2.2 AA. Essas orientações abrangem organismos públicos, não empresas privadas.
• Estados Unidos: a regra do Departamento de Justiça para os governos estaduais e locais usa as WCAG 2.1 AA, com prazos de cumprimento adiados em abril de 2026 (abre num novo separador) para 26 de abril de 2027 e 26 de abril de 2028. Para as empresas privadas, as orientações de 2022 (abre num novo separador) do Departamento dizem que a ADA se aplica aos seus sites, mas não fixam nenhuma norma técnica concreta.

E as WCAG 3?

As WCAG 3 são um rascunho, por isso ainda ninguém as pode cumprir. O W3C publicou rascunhos atualizados em setembro de 2026 e prevê que as WCAG 3 só estejam concluídas «daqui a alguns anos». As WCAG 2 não serão descontinuadas durante vários anos depois disso, por isso a versão com que trabalhar agora é a 2.2.

Como verificar os critérios novos em 15 minutos?

Consegue detetar a maioria das falhas dos seis critérios A e AA em cerca de 15 minutos, com um teclado, um telemóvel e a sua própria página de início de sessão. Não substitui uma auditoria completa nem testes com pessoas com deficiência, mas mostra-lhe por onde começar e dá a quem programa uma lista concreta para trabalhar.

1. Percorra com Tab a página inicial, uma página de produto e o checkout com todas as faixas visíveis. Vê sempre o foco? (2.4.11)
2. Conclua cada controlo deslizante ou tarefa de arrastar e largar só com cliques ou toques. (2.5.7)
3. Num telemóvel, experimente cada botão de fechar, número de página e ícone pequeno. (2.5.8)
4. Compare onde aparecem a ajuda e os contactos em três tipos de página. (3.2.6)
5. Faça uma compra ou uma reserva e anote qualquer pergunta a que responda duas vezes. (3.3.7)
6. Inicie sessão com um gestor de palavras-passe e depois cole uma palavra-passe e um código de utilização única. Algum CAPTCHA tem alternativa? (3.3.8)

Para o resto das WCAG, o nosso guia sobre como testar a acessibilidade do seu site apresenta ferramentas gratuitas e verificações manuais, e a nossa lista de verificação de acessibilidade web transforma as falhas mais comuns numa lista de tarefas. O que ainda não conseguir corrigir deve constar da sua declaração de acessibilidade.

Uma nota sobre widgets, incluindo o nosso: nenhum destes critérios pode ser cumprido a partir de um painel para visitantes. Um cursor grande facilita apontar para alvos pequenos, mas não lhes dá 24 píxeis de largura, e realçar o foco não afasta uma faixa fixa. Todos os critérios novos dizem respeito à forma como as suas páginas são construídas, por isso a correção está nos seus modelos e no seu código.