As Web Content Accessibility Guidelines (WCAG) 2.2 foram publicadas como recomendação oficial do W3C em outubro de 2023, substituindo o WCAG 2.1. Esta atualização introduz 9 novos critérios de sucesso focados principalmente em melhorar a acessibilidade para utilizadores com deficiências cognitivas e motoras, além de remover um critério obsoleto relacionado à análise sintática do HTML.
Resumo rápido das alterações entre WCAG 2.1 e 2.2
O WCAG 2.2 adiciona 9 novos critérios de sucesso e remove 1 critério existente (4.1.1 Análise Sintática). Dos 9 novos critérios, 6 são de nível AA e 3 são de nível AAA. As principais áreas de melhoria incluem visibilidade do foco do teclado, tamanho dos alvos de toque, autenticação simplificada, prevenção de entradas redundantes e consistência dos mecanismos de ajuda. O WCAG 2.2 mantém total retrocompatibilidade com o WCAG 2.1 - qualquer conteúdo que cumpra o WCAG 2.2 também cumpre automaticamente o WCAG 2.1.
Novos critérios de sucesso no WCAG 2.2
Os 9 novos critérios foram desenvolvidos com foco especial em utilizadores com deficiências motoras, visuais e cognitivas. Três critérios abordam a visibilidade do indicador de foco, dois tratam de interações por toque, dois simplificam processos de autenticação, e dois melhoram a experiência do utilizador em formulários e mecanismos de ajuda.
2.4.11 Foco não obscurecido (Mínimo) - Nível AA
Este critério garante que quando um elemento recebe o foco do teclado, pelo menos uma parte do indicador de foco permaneça visível. Elementos flutuantes como banners de cookies, cabeçalhos fixos ou janelas modais não podem cobrir completamente o indicador de foco. Por exemplo, se um utilizador navega por tabulação até um botão e um rodapé fixo cobre metade do indicador, ainda assim é aceitável - mas se cobrir totalmente, viola este critério. Isto é especialmente importante para utilizadores que dependem exclusivamente do teclado para navegar.
2.4.12 Foco não obscurecido (Melhorado) - Nível AAA
A versão melhorada deste critério exige que o indicador de foco nunca seja obscurecido por conteúdo criado pelo autor. Ao contrário do nível AA que permite obscurecimento parcial, o nível AAA requer que o indicador de foco permaneça 100% visível em todas as circunstâncias. Isto oferece a melhor experiência possível para utilizadores de teclado, eliminando qualquer necessidade de deslocar ou mover elementos da interface para ver onde está o foco.
2.4.13 Aparência do foco - Nível AAA
Este critério estabelece requisitos específicos para a aparência visual do indicador de foco do teclado. O indicador deve ter uma área mínima equivalente a um contorno de 2 pixels CSS ao redor do componente, e o contraste entre os estados com e sem foco deve ser de pelo menos 3:1. Por exemplo, se um botão azul escuro usa um contorno amarelo para o foco, esse amarelo deve contrastar suficientemente tanto com o fundo do botão quanto com a cor original da borda. Muitos navegadores modernos já fornecem indicadores de foco que cumprem este critério por padrão.
2.5.7 Movimentos de arrastar - Nível AA
Qualquer funcionalidade que utilize movimentos de arrastar (drag) deve ter uma alternativa de interação com um único ponteiro, a menos que o arrastar seja essencial. Por exemplo, um controlo deslizante que permite arrastar para ajustar valores também deve permitir tocar diretamente em posições específicas ou usar botões de incremento/decremento. Isto beneficia utilizadores com tremores, amplitude de movimento limitada, ou que utilizam dispositivos de ponteiro adaptativos. As exceções aplicam-se apenas quando o caminho do arrastar é funcionalmente essencial, como em aplicações de desenho ou assinatura.
2.5.8 Tamanho do alvo (Mínimo) - Nível AA
Os alvos de toque devem ter pelo menos 24×24 pixels CSS, com algumas exceções. Este critério é mais permissivo que o anterior 2.5.5 (nível AAA, 44×44 pixels) e permite exceções quando: o alvo está embutido numa frase, o tamanho é controlado pelo navegador (não pelo autor), existe espaçamento adequado (pelo menos 24 pixels) entre alvos pequenos, ou uma alternativa maior está disponível na mesma página. Por exemplo, ícones de redes sociais de 20×20 pixels são aceitáveis se tiverem pelo menos 24 pixels de espaço ao redor, mas links de texto em parágrafos podem ser menores pois estão embutidos em frases.
3.2.6 Ajuda consistente - Nível A
Mecanismos de ajuda como números de telefone, formulários de contacto, opções de chat ou páginas de FAQ devem aparecer na mesma ordem relativa em todas as páginas de um site. Se a página inicial tem um link "Contacte-nos" no rodapé após "Sobre nós", essa mesma ordem deve ser mantida em todas as páginas que incluem esses links. Isto não significa que todas as páginas devem ter os mesmos mecanismos de ajuda - apenas que quando estão presentes, devem manter ordem consistente. Esta previsibilidade é crucial para utilizadores com deficiências cognitivas que dependem de padrões consistentes para navegar eficientemente.
3.3.7 Entrada redundante - Nível A
Informações já fornecidas pelo utilizador na mesma sessão não devem ser solicitadas novamente, a menos que seja essencial para segurança ou a informação anterior já não seja válida. Por exemplo, num processo de checkout em várias etapas, se o utilizador já introduziu o endereço de entrega, não deve ser obrigado a reintroduzi-lo manualmente na página de revisão - deve ser preenchido automaticamente ou selecionável. As exceções incluem reinserir passwords por motivos de segurança ou quando os dados anteriores expiraram. Este critério reduz significativamente a carga cognitiva e física, especialmente para utilizadores com deficiências de memória ou destreza limitada.
3.3.8 Autenticação acessível (Mínimo) - Nível AA
Os processos de autenticação não podem depender de testes de função cognitiva, a menos que forneçam alternativas acessíveis. Isto significa que não pode exigir que os utilizadores memorizem passwords complexos, resolvam puzzles ou recordem informações específicas sem oferecer alternativas. Métodos permitidos incluem gestores de passwords, autenticação biométrica, códigos enviados por email/SMS copiáveis, ou reconhecimento de objetos (desde que não sejam testes cognitivos). Por exemplo, exigir que um utilizador digite uma password de memória viola este critério, mas permitir colar de um gestor de passwords cumpre-o.
3.3.9 Autenticação acessível (Melhorado) - Nível AAA
A versão melhorada deste critério elimina completamente os testes de função cognitiva dos processos de autenticação, mesmo para métodos de autenticação secundários. Ao contrário do nível AA que permite testes cognitivos se houver alternativas, o nível AAA proíbe-os totalmente. Isto significa que mesmo recursos como perguntas de segurança ("Qual era o nome do seu primeiro animal de estimação?") não são permitidos, a menos que sejam opcionais. Os métodos de autenticação devem depender exclusivamente de algo que o utilizador tem (dispositivo, email) ou algo que o utilizador é (biometria), não do que o utilizador lembra.
Critério removido: 4.1.1 Análise sintática
O critério 4.1.1 Parsing (Análise Sintática) foi oficialmente removido do WCAG 2.2 e considerado obsoleto. Este critério originalmente exigia HTML válido sem erros de sintaxe que interferissem com tecnologias assistivas. A remoção ocorreu porque os navegadores modernos tornaram-se extremamente robustos na correção automática de erros de HTML, e as tecnologias assistivas agora utilizam APIs de acessibilidade do navegador em vez de analisar diretamente o HTML. Embora HTML válido continue sendo uma boa prática, os erros de sintaxe já não são considerados uma barreira significativa à acessibilidade na maioria dos casos práticos.
O que o European Accessibility Act exige
O European Accessibility Act (EAA), que entra em vigor em junho de 2025, não especifica explicitamente qual versão do WCAG deve ser seguida. No entanto, a norma harmonizada europeia EN 301 549 v3.2.1 (publicada em março de 2021) referencia o WCAG 2.1 nível AA como base para conformidade. Espera-se que futuras atualizações da EN 301 549 incorporem os requisitos do WCAG 2.2. Para garantir conformidade futura e fornecer a melhor experiência possível aos utilizadores, é altamente recomendável visar o WCAG 2.2 nível AA desde já, especialmente porque é retrocompatível com o WCAG 2.1.
Deve visar o WCAG 2.2?
Sim, definitivamente deve visar o WCAG 2.2 nível AA para novos projetos e atualizações significativas. Dado que o WCAG 2.2 é totalmente retrocompatível com o WCAG 2.1, cumprir o WCAG 2.2 garante automaticamente conformidade com versões anteriores. Os 9 novos critérios abordam necessidades reais de utilizadores que foram negligenciadas nas versões anteriores, especialmente para pessoas com deficiências cognitivas e motoras. Além disso, com a evolução das legislações de acessibilidade globalmente, incluindo o EAA na Europa e atualizações da Section 508 nos Estados Unidos, é provável que o WCAG 2.2 torne-se o padrão exigido legalmente num futuro próximo.
Como testar a conformidade com WCAG 2.2
Testar a conformidade com WCAG 2.2 requer uma combinação de ferramentas automatizadas e testes manuais. Ferramentas como WAVE, axe DevTools, ou Lighthouse podem identificar automaticamente muitos problemas relacionados com contraste, estrutura HTML e atributos ARIA. No entanto, aproximadamente 30-40% dos critérios WCAG 2.2 - especialmente os novos - requerem verificação manual, incluindo navegação completa por teclado, teste com leitores de ecrã, verificação da ordem de foco, validação de tamanhos de alvos, e análise de fluxos de autenticação. Para garantir conformidade completa, considere contratar auditores especializados em acessibilidade que possam realizar testes com tecnologias assistivas reais e fornecer recomendações detalhadas de remediação.