WCAG 2.2 vs WCAG 2.1: O que há de novo e o que você precisa atualizar

Mais de 96% das homepages ainda falham nos requisitos básicos das WCAG, de acordo com a análise de acessibilidade de 2024 da WebAIM — e isso em relação a um padrão que já tinha cinco anos. Em 5 de outubro de 2023, o W3C publicou as WCAG 2.2 como padrão oficial da web, elevando o nível com nove novos critérios de sucesso e aposentando um critério que se tornou obsoleto. Se você gerencia um site, desenvolve produtos digitais ou supervisiona conformidade, essa atualização não é algo que você possa adiar indefinidamente. Regulamentações na UE, no Reino Unido e, cada vez mais, em estados dos EUA já estão se movendo para referenciar as WCAG 2.2 como seu parâmetro.

Um breve histórico: das WCAG 2.1 às WCAG 2.2

As Diretrizes de Acessibilidade para Conteúdo Web evoluíram de forma constante desde que as WCAG 2.0 foram lançadas em dezembro de 2008. As WCAG 2.1 chegaram em junho de 2018, adicionando 17 novos critérios de sucesso com foco particular em usuários de dispositivos móveis e pessoas com baixa visão ou deficiências cognitivas. Por cinco anos, elas serviram como referência de conformidade de fato para leis como a ADA, a Seção 508 e a Diretiva de Acessibilidade Web da UE.

As WCAG 2.2 retomam exatamente de onde as 2.1 pararam. O W3C as iniciou com o objetivo explícito de continuar aprimorando a orientação de acessibilidade para três grandes grupos: usuários com deficiências cognitivas ou de aprendizagem, usuários com baixa visão e usuários com deficiências em dispositivos móveis. Essa linhagem é importante porque significa que a atualização é evolutiva, não revolucionária — mas ainda é significativa o suficiente para exigir ação da sua parte.

Uma das coisas mais importantes a entender estruturalmente é que as WCAG 2.2 são totalmente retrocompatíveis com as WCAG 2.1. Estar em conformidade com as WCAG 2.2 significa automaticamente estar em conformidade também com as WCAG 2.1 e 2.0. Se a sua organização atualmente está em conformidade com WCAG 2.1 AA, você só precisa tratar dos novos critérios introduzidos nas 2.2 — você não está começando do zero. O W3C também orienta que, embora as WCAG 2.0 e 2.1 continuem sendo recomendações válidas, as organizações devem usar as WCAG 2.2 para maximizar a aplicabilidade futura do seu trabalho de acessibilidade.

Também é amplamente esperado que as WCAG 2.2 sejam a última versão “ponto” da família WCAG 2.x. A próxima versão principal, WCAG 3.0, é uma criatura totalmente diferente — uma reformulação completa de como as diretrizes de acessibilidade são estruturadas. Isso faz das WCAG 2.2 o ponto final definitivo de uma linhagem que remonta a 2008, e a versão que você precisa acertar agora.

Os números: o que realmente mudou

Vamos ser precisos sobre o escopo da mudança. As WCAG 2.1 continham 78 critérios de sucesso em três níveis de conformidade (A, AA e AAA). As WCAG 2.2 adicionam nove novos critérios de sucesso e removem um — o Critério de Sucesso 4.1.1 Parsing — deixando o total em 86 critérios ativos. Desses nove acréscimos, dois são de Nível A, quatro de Nível AA e três de Nível AAA.

Para a grande maioria das organizações que miram a conformidade de Nível AA — o nível referenciado na maioria das leis e regulamentações — o impacto prático é a implementação de seis novos critérios. As três adições de Nível AAA são consideradas boas práticas e são frequentemente recomendadas em contextos governamentais e de saúde, mas não são uma exigência legal rígida na maioria das jurisdições hoje.

Os novos critérios abordam principalmente quatro áreas problemáticas que auditorias de acessibilidade no mundo real repetidamente apontaram como pouco atendidas pelo padrão existente: visibilidade do foco de teclado, interações por toque e ponteiro, acessibilidade cognitiva e barreiras de autenticação. Essas não são preocupações teóricas. São o tipo de barreira que regularmente impede pessoas com deficiência de concluir tarefas cotidianas como fazer login, preencher um formulário ou navegar em uma página com um cabeçalho fixo.

Os nove novos critérios de sucesso explicados

A seguir está um detalhamento de cada novo critério, o que ele exige e por que importa na prática. Os critérios são apresentados por nível de conformidade para que você possa priorizar seu trabalho de correção.

Nível A (Mínimo — obrigatório para todos)

• 2.4.11 Foco não encoberto (Mínimo): Quando um componente de interface recebe foco de teclado, ele não pode ficar totalmente oculto por conteúdo criado pelo autor. Os culpados mais comuns aqui são cabeçalhos fixos, banners flutuantes de cookies e widgets de chat ao vivo que ficam sobre a página. Se um usuário pressionando Tab cair em um botão que está completamente coberto pela sua barra de navegação fixa, esse critério é violado. Observe que ficar parcialmente encoberto é aceitável no Nível A — o elemento apenas não pode ficar 100% oculto.
• 2.5.7 Movimentos de arrastar: Qualquer funcionalidade que exija um movimento de arrastar — pense em uploads de arquivos por arrastar e soltar, itens de lista ordenáveis ou controles deslizantes — também deve ser operável com uma única ação de ponteiro (como um clique ou toque) sem arrastar. Isso é fundamental para usuários com deficiências motoras que não conseguem executar gestos de arrastar controlados de forma confiável. A exigência se aplica a conteúdo criado pelo autor; comportamentos nativos do navegador estão isentos.

Nível AA (Obrigatório para conformidade padrão)

• 2.4.12 Foco não encoberto (Aprimorado): Uma versão mais rígida do 2.4.11. No Nível AA, nenhuma parte do indicador de foco pode ser encoberta por conteúdo criado pelo autor quando um elemento recebe foco de teclado. Isso fecha a brecha da versão de Nível A e exige que elementos em foco estejam totalmente visíveis — não apenas parcialmente.
• 2.5.8 Tamanho do alvo (Mínimo): A área clicável ou tocável de elementos interativos deve ter pelo menos 24×24 pixels CSS, com exceções específicas para links de texto em linha, elementos controlados pelo user agent e casos em que exista um alvo equivalente de 24×24 nas proximidades. Essa é uma mudança significativa em relação às WCAG 2.1, em que um tamanho de alvo de 44×44 pixels era apenas recomendado no nível AAA. Agora um mínimo é exigível no nível AA. Observe que, embora 24×24px seja o piso, o critério AAA (2.5.5) ainda recomenda 44×44px, e isso continua sendo o padrão ouro para design amigável ao toque.
• 3.2.6 Ajuda consistente: Se um site oferece quaisquer mecanismos de ajuda — detalhes de contato humano, ferramentas de autoatendimento, chat automatizado ou um formulário de contato — e esses mecanismos aparecem em várias páginas, eles devem aparecer na mesma posição relativa em todas essas páginas. Usuários que precisam de ajuda, especialmente aqueles com deficiências cognitivas, devem sempre conseguir encontrá-la no mesmo lugar, sem precisar procurar.
• 3.3.7 Entrada redundante: Informações que um usuário já inseriu em uma etapa anterior do mesmo processo devem ser preenchidas automaticamente para ele ou disponibilizadas para seleção, para que ele não precise digitá-las novamente. Pense em fluxos de checkout em várias etapas que pedem um endereço de cobrança e depois pedem novamente um endereço de entrega — os usuários devem ter uma forma de copiar o que já inseriram. Exceções são permitidas quando reinserir informações é essencial para segurança (como confirmar uma senha) ou quando os dados inseridos anteriormente não são mais válidos.
• 3.3.8 Autenticação acessível (Mínimo): Testes de função cognitiva — como resolver um quebra-cabeça, memorizar uma senha ou transcrever caracteres de um CAPTCHA em imagem — não podem ser exigidos como único meio de autenticação. Um método alternativo deve estar disponível, ou um mecanismo deve auxiliar o usuário (como permitir o uso de gerenciador de senhas ou permitir copiar e colar no campo de senha). Esse critério não proíbe CAPTCHAs por completo, mas exige que eles nunca sejam a única opção para usuários que não conseguem completá-los.

Nível AAA (Aprimorado — recomendado, mas não obrigatório para a maioria)

• 2.4.13 Aparência do foco: Quando o indicador de foco de teclado estiver visível, ele deve atender a requisitos mínimos específicos de tamanho e contraste: a área de foco deve ser pelo menos tão grande quanto um perímetro de 2 pixels CSS de espessura ao redor do elemento, e deve haver uma taxa de contraste de pelo menos 3:1 entre os estados em foco e sem foco. Esse critério foi originalmente planejado para o Nível AA, mas foi movido para AAA devido à sua complexidade. Isso significa que, para conformidade apenas AA, ainda não há um tamanho mínimo normativamente definido para um indicador de foco — apenas que ele deve ser visível.
• 2.5.9 Movimentos de arrastar (Aprimorado): Espere — não existe 2.5.9 nesta versão. A melhoria de arrastar em AAA está contemplada em 3.3.9 abaixo.
• 3.3.9 Autenticação acessível (Aprimorado): Uma versão mais rígida de 3.3.8. No Nível AAA, testes de reconhecimento de objetos e de conteúdo pessoal (como “clique em todos os semáforos” ou “selecione fotos da sua conta”) também são proibidos, não apenas as exceções previstas no Nível AA. Restam apenas duas exceções em vez de quatro.

O que foi removido: 4.1.1 Parsing

As WCAG 2.2 removem um critério de sucesso que estava em vigor desde as WCAG 2.0: 4.1.1 Parsing. Esse critério originalmente exigia que o HTML fosse bem formado, com tags de abertura e fechamento completas, aninhamento adequado e sem atributos duplicados. A intenção era garantir que navegadores e tecnologias assistivas pudessem analisar o código de marcação de forma confiável e apresentar o conteúdo corretamente aos usuários.

A remoção não é controversa — ela reflete uma mudança real no cenário técnico. Desde 2008, os navegadores se tornaram extraordinariamente bons em lidar graciosamente com HTML malformado, seguindo um algoritmo de correção de erros consistente e padronizado. Tecnologias assistivas como leitores de tela agora dependem do Document Object Model (DOM) do navegador, não do código-fonte HTML bruto. O W3C concluiu que o critério não oferece mais nenhum benefício significativo de acessibilidade no ambiente moderno. Problemas de acessibilidade que costumavam ser capturados pelo 4.1.1 ainda são cobertos por critérios mais específicos como 1.3.1 (Informações e relacionamentos) e 4.1.2 (Nome, função, valor).

As implicações práticas para sua equipe: se suas ferramentas de teste automatizado vinham sinalizando falhas de 4.1.1 Parsing, elas não são mais questões de WCAG 2.2. Você pode ver uma redução nas falhas relatadas puramente pela atualização de versão, não porque algo foi corrigido. Dito isso, escrever HTML válido e bem estruturado continua sendo uma forte boa prática — apenas não é mais um requisito de conformidade por si só.

Implicações regulatórias e legais

Entender os novos critérios é uma coisa. Entender o que eles significam para sua exposição legal é outra. A resposta curta é: as WCAG 2.2 estão se tornando a lei em várias jurisdições, e o cronograma está avançando mais rápido do que muitas organizações percebem.

No Reino Unido, órgãos do setor público já são obrigados a atender às WCAG 2.2 Nível AA sob os Regulamentos de Acessibilidade de Órgãos do Setor Público. Na União Europeia, a EN 301 549 — o padrão técnico que sustenta o Ato Europeu de Acessibilidade — está em processo de adoção das WCAG 2.2 como sua base. O próprio EAA tem um prazo de aplicação em junho de 2025 para a maioria das organizações do setor privado que oferecem produtos e serviços na UE. Vários estados dos EUA, incluindo o Colorado, também manifestaram intenção de atualizar suas leis estaduais de acessibilidade de WCAG 2.1 para WCAG 2.2.

Nos Estados Unidos, o Título II da ADA atualmente faz referência às WCAG 2.1 AA como padrão técnico para sites de governos estaduais e locais. No entanto, tribunais norte-americanos têm citado cada vez mais as WCAG 2.2 em ações judiciais de acessibilidade, e a trajetória é clara. Esperar por um mandato federal formal antes de agir é uma estratégia de conformidade que traz risco jurídico crescente, particularmente para organizações de comércio eletrônico, serviços financeiros e saúde, que são alvos de alto valor para litígios de acessibilidade.

Mesmo que sua organização ainda não seja legalmente obrigada a se conformar às WCAG 2.2, atender aos novos critérios de sucesso mais cedo, em vez de mais tarde, garantirá que você se antecipe às mudanças regulatórias — e, mais importante, às barreiras reais de acessibilidade que seus usuários enfrentam hoje.

Como auditar e atualizar seu site

Se você já está em conformidade com WCAG 2.1 AA, o caminho de atualização para WCAG 2.2 é administrável. Aqui está uma estrutura prática para abordá-lo.

Comece com uma auditoria direcionada dos seis novos critérios de Nível AA. São eles que têm peso legal para a maioria das organizações. Foque especialmente em 2.4.11 e 2.4.12 (foco encoberto), 2.5.8 (tamanho do alvo), 3.2.6 (ajuda consistente), 3.3.7 (entrada redundante) e 3.3.8 (autenticação acessível). Um engenheiro de acessibilidade experiente normalmente consegue auditar esses critérios manualmente em poucas horas para um site de complexidade moderada.

Audite primeiro seus elementos fixos/posicionados como “sticky”. Os critérios de foco encoberto (2.4.11 e 2.4.12) são violados por alguns dos padrões de interface mais comuns na web — cabeçalhos fixos, botões de ação flutuantes, barras de consentimento de cookies e widgets de chat. Percorra todo o seu site usando apenas a tecla Tab e observe se algum elemento em foco desaparece sob uma camada fixa. Uma correção em CSS geralmente é simples:

/* Impedir que o cabeçalho fixo cubra elementos em foco */
:focus {
  scroll-margin-top: 80px; /* iguale à altura do seu cabeçalho fixo */
}

Audite o tamanho do alvo de toque de cada elemento interativo. Isso costuma ser um ganho rápido em termos de conformidade e experiência do usuário. Botões, links, controles de formulário e ícones precisam de um mínimo de 24×24 pixels CSS. Muitos sistemas de design já excedem esse limite, mas pequenos botões de ícone — ícones de fechar, botões de compartilhamento em redes sociais e links de ação em linha — são infratores frequentes. Inspecione seus componentes e adicione padding ou ajuste dimensões conforme necessário.

Revise cuidadosamente seus fluxos de autenticação. O CS 3.3.8 (Autenticação acessível) tem impacto real. Se você usa um CAPTCHA que não pode ser contornado ou resolvido por um método alternativo, provavelmente está em não conformidade. Avalie se seus fluxos de login, registro e autenticação em duas etapas permitem que gerenciadores de senha preencham automaticamente, permitem copiar e colar, oferecem um método de verificação alternativo (como um link mágico ou código único) ou fornecem qualquer outra acomodação para usuários que não conseguem completar um desafio cognitivo.

Audite formulários em várias etapas em busca de entrada redundante. Mapeie quaisquer processos que se estendam por várias etapas — checkouts, fluxos de onboarding, inscrições — e identifique cada instância em que o usuário é solicitado a fornecer informações que já forneceu. Adicione lógica de preenchimento automático ou um botão “igual ao acima” quando aplicável. Isso normalmente é uma mudança de back-end ou de gerenciamento de estado do formulário, em vez de uma reformulação arquitetural complexa.

Verifique se os mecanismos de ajuda estão posicionados de forma consistente. Se você tem um widget de chat, um link de ajuda ou um número de telefone que aparece em um rodapé ou barra lateral em várias páginas, verifique se sua posição relativa não muda. Isso geralmente é uma questão de template ou layout, e não um problema página a página — corrija na sua biblioteca de componentes ou no template do CMS e a correção se propaga para todo lugar.

Use ferramentas automatizadas para descoberta inicial, mas não pare por aí. Scanners automatizados conseguem detectar cerca de 40% dos problemas de WCAG 2.2 — eles são úteis para capturar violações de tamanho de alvo e problemas óbvios de gerenciamento de foco, mas não conseguem avaliar se um CAPTCHA é a única opção de autenticação ou se um mecanismo de ajuda está posicionado de forma consistente. Testes manuais, incluindo navegação apenas por teclado e testes com leitor de tela, continuam essenciais. Testes com usuários reais com deficiência vão identificar problemas que nenhuma ferramenta automatizada jamais encontrará.

WCAG 2.2 e widgets de overlay: o que você deve saber

Widgets de overlay de acessibilidade e SDKs — ferramentas como Accsible — podem fornecer ajuda significativa na identificação e correção de certas categorias de problemas de acessibilidade, especialmente para usuários que precisam de ajustes em tempo real, como aumento de tamanho de fonte, mudanças de contraste ou melhorias na navegação por teclado. Vale a pena ter clareza sobre o que overlays podem e não podem fazer no contexto da conformidade com WCAG 2.2.

Overlays podem ajudar a tratar certos problemas de visibilidade de foco, fornecer modos alternativos de navegação e oferecer personalização do lado do usuário que compensa algumas falhas de design. Eles são uma camada útil na pilha de acessibilidade, especialmente para equipes que precisam melhorar a experiência do usuário rapidamente enquanto o trabalho de correção de longo prazo está em andamento. No entanto, eles não substituem a correção do código subjacente. Os novos critérios das WCAG 2.2 — especialmente em torno de autenticação (3.3.8), entrada redundante (3.3.7) e movimentos de arrastar (2.5.7) — exigem mudanças estruturais em como sua aplicação é construída, não apenas em como é apresentada.

A abordagem mais eficaz combina um overlay bem implementado para adaptabilidade voltada ao usuário com correções adequadas em nível de código para os novos critérios 2.2. Pense em um SDK de overlay como um multiplicador de força: ele amplia seu alcance, melhora a experiência para mais usuários e preenche lacunas — mas a base ainda precisa ser sólida.

Pontos principais

• As WCAG 2.2 adicionam nove novos critérios de sucesso e removem uma regra obsoleta (4.1.1 Parsing). Elas são totalmente retrocompatíveis com 2.1, então seu trabalho de conformidade existente não é desperdiçado — você só precisa acrescentar o que é novo.
• Para conformidade de Nível AA, foque em seis novos critérios específicos: Foco não encoberto (2.4.11 e 2.4.12), Tamanho mínimo do alvo (2.5.8), Ajuda consistente (3.2.6), Entrada redundante (3.3.7) e Autenticação acessível (3.3.8). Esses são os legalmente relevantes para a maioria das organizações.
• A adoção regulatória está acelerando. O setor público do Reino Unido já aplica as WCAG 2.2, a UE está em transição para elas sob o Ato Europeu de Acessibilidade, e tribunais dos EUA as citam cada vez mais. Não espere por um mandato formal na sua jurisdição antes de agir.
• Ferramentas automatizadas capturam apenas cerca de 40% dos problemas de WCAG 2.2 — testes manuais, walkthroughs de navegação apenas por teclado e testes com usuários reais são essenciais para alcançar conformidade genuína, especialmente para os novos critérios em torno de autenticação e acessibilidade cognitiva.
• Os ganhos rápidos mais comuns são corrigir cabeçalhos fixos que encobrem elementos em foco, aumentar alvos de toque pequenos e auditar seus fluxos de login/autenticação quanto à dependência de CAPTCHA. Essas mudanças costumam exigir pouco esforço e ter alto impacto — um bom ponto de partida para o seu sprint de correção para WCAG 2.2.