Por que a Acessibilidade e o Consentimento Agora se Sobrepõem

O GDPR exige que o consentimento possa ser obtido de cada utilizador, não apenas daqueles que conseguem ver e clicar num banner. O Conselho Europeu para a Proteção de Dados esclareceu que, se um titular de dados não conseguir interagir de forma significativa com a interface de consentimento — devido a uma deficiência que o site não acomodou — o consentimento não foi obtido de forma válida. Isso significa que os cookies nunca deveriam ter sido carregados.

Do lado da acessibilidade, a Lei Europeia de Acessibilidade (EAA), transposta para a legislação nacional em todos os Estados-Membros da UE, faz com que o WCAG 2.1 AA seja o mínimo para sites e aplicações do setor privado que oferecem serviços ao consumidor. O regime de sanções varia por país, mas normalmente varia entre €50.000 e €500.000 por infração, além de ordens de retirada do mercado por incumprimento persistente.

Os Requisitos Centrais do WCAG para Banners de Cookies

Operabilidade por Teclado

Cada controlo do banner — Aceitar, Rejeitar, Gerir Preferências, fechar — deve ser acessível e operável apenas com o teclado. Os utilizadores devem conseguir usar Tab para navegar entre os botões numa ordem lógica e ativá-los com Enter ou Space. O foco deve ser visível com uma relação de contraste mínima de 3:1 em relação ao fundo.

Captura de Foco em Banners Modais

Se o banner bloquear a interação com o resto da página, o foco do teclado deve ser capturado dentro do banner até que o utilizador faça uma escolha. Os utilizadores não devem conseguir sair do banner com Tab para rolar a página subjacente. Quando o foco estava capturado e o banner fecha, o foco deve retornar ao elemento que ativou o banner ou a um padrão razoável.

Anúncios do Leitor de Ecrã

O banner deve ser anunciado como um diálogo com um nome e papel acessíveis. Use `role="dialog"` ou `role="alertdialog"` com `aria-labelledby` apontando para o cabeçalho do banner e `aria-describedby` apontando para o texto explicativo.

Contraste de Cor

O texto do corpo deve cumprir um contraste de 4,5:1 em relação ao fundo; texto grande (18pt+ ou 14pt negrito) necessita de 3:1. O texto dos botões, ícones e indicadores de foco têm todos os seus próprios mínimos de contraste. Um botão "Rejeitar" cinzento claro sobre fundo branco é uma falha WCAG frequente que vemos em auditorias.

Sem Pistas Apenas de Cor

Não confie apenas na cor para diferenciar Aceitar de Rejeitar. Use rótulos, ícones ou formas distintos para que os utilizadores com daltonismo possam distinguir os botões.

Padrões Obscuros e Acessibilidade

O WCAG 2.2 introduz novos critérios que visam diretamente os padrões obscuros — especialmente relevantes para o consentimento:

• 3.3.8 Autenticação Acessível — proíbe quebra-cabeças cognitivos como atrito no consentimento.
• 3.3.7 Entrada Redundante — os utilizadores não devem ter de reintroduzir informações apenas para retirar o consentimento.
• 2.4.11 Foco Não Obscurecido — o próprio banner não deve obscurecer o indicador de foco de elementos atrás dele.
• 2.5.7 Movimentos de Arrastar — se o seu banner usa uma interação arrastar-para-aceitar, deve existir uma alternativa com ponteiro único.

RTL e Internacionalização

A acessibilidade estende-se a línguas da direita para a esquerda (árabe, hebraico, persa, urdu) e à pronúncia do leitor de ecrã:

• Defina `dir="rtl"` no banner quando o idioma do documento for RTL para que a ordem dos botões e o fluxo do foco correspondam à direção de leitura.
• Use atributos `lang` corretos no texto do banner traduzido para que os leitores de ecrã pronunciem as palavras com a fonética correta.
• Espelhar a iconografia — chevrons, setas e indicadores de progresso devem ser invertidos para locais RTL.

Testar o Seu Banner para Conformidade com o WCAG

Não confie numa única ferramenta. Combine a varredura automática com testes reais de tecnologia assistiva:

• axe DevTools ou Lighthouse — deteta automaticamente cerca de 30–40% das falhas WCAG.
• NVDA ou JAWS no Windows, VoiceOver no Mac/iOS, TalkBack no Android — teste com leitores de ecrã reais. O banner pode ser anunciado, navegado e dispensado usando apenas o leitor de ecrã?
• Navegação apenas por teclado — desconecte o rato. Se não conseguir Aceitar, Rejeitar e gerir preferências, os utilizadores de teclado também não conseguem.
• Simulação de daltonismo — o Chrome DevTools tem simuladores de deficiência visual integrados. Verifique se Aceitar e Rejeitar são distinguíveis sob protanopia, deuteranopia e tritanopia.
• Zoom para 400% — o WCAG exige que o conteúdo permaneça utilizável a 400% de zoom sem rolagem horizontal. Os banners de posição fixa geralmente falham neste teste.

Falhas de Acessibilidade Comuns que Vemos

• Rejeitar escondido atrás de um ícone de engrenagem — padrão obscuro mais falha de acessibilidade (sem nome acessível no botão de ícone).
• O foco nunca alcança o banner — banners que roubam atenção visual mas são ignorados na ordem Tab.
• Banner modal sem captura de foco — os utilizadores podem usar Tab para a página de fundo enquanto o banner afirma bloquear a interação.
• Sem `aria-live` nas alterações de preferências — os utilizadores de leitor de ecrã não ouvem confirmação de que a sua escolha foi guardada.
• Banners traduzidos sem atributo `lang` — os leitores de ecrã pronunciam texto espanhol com fonética inglesa.

Como o FlexyConsent Oferece Acessibilidade