Banners de Consentimento Inacessíveis Agora Criam Duas Responsabilidades Legais, Não Uma

Desde 28 de junho de 2025, um banner de consentimento que um usuário de teclado não consegue navegar completamente não é apenas uma falha de acessibilidade — é uma violação do GDPR. A Lei Europeia de Acessibilidade (EAA, na sigla em inglês) entrou em vigor em todos os 27 estados-membros da UE nessa data, tornando o WCAG 2.2 Nível AA o padrão legalmente exigível para serviços digitais, incluindo as interfaces de consentimento das quais as ferramentas de analytics dependem.

Os dois regimes regulatórios estão agora diretamente acoplados. Resolver um sem o outro ainda deixa você exposto.

O que a EAA realmente exige

A EAA se apoia na norma europeia EN 301 549, que por sua vez referencia o WCAG 2.2. Para interfaces de consentimento, os requisitos mais relevantes na prática são:

• Foco não obscurecido (WCAG 2.4.11): Quando um usuário pressiona Tab para chegar a um botão, ele não pode ficar completamente escondido atrás do próprio banner ou de um cabeçalho fixo.
• Acessibilidade por teclado (WCAG 2.1.1): Todos os elementos interativos — Aceitar, Recusar, Gerenciar preferências — devem ser alcançáveis e operáveis sem mouse.
• Indicadores de foco visíveis (WCAG 2.4.7): Os anéis de foco devem ser visíveis. Muitas plataformas de gerenciamento de consentimento suprimem os estilos de foco padrão do navegador por razões estéticas, o que descumpre esse critério.
• Contraste de cor suficiente (WCAG 1.4.3): O texto sobre o fundo deve atingir a proporção de 4,5:1 para texto de corpo. Links "Recusar tudo" em cinza claro ao lado de botões "Aceitar" em azul negrito são um padrão de falha comum.
• Sem fechamento automático: O banner não pode fechar sem interação explícita do usuário. A aceitação automática com temporizador, mesmo após vários segundos, é inválida.

As penalidades variam por estado-membro. A Alemanha aplica até €100.000 por infração. A Espanha escala até €1.000.000 em casos graves. A França combina multas financeiras com a possível suspensão do serviço não conforme.

Por que falhas de acessibilidade invalidam o consentimento do GDPR

O Considerando 32 do GDPR exige que o consentimento seja "livre, específico, informado e inequívoco". O Artigo 7 acrescenta que retirar o consentimento deve ser "tão fácil quanto dá-lo". Esses requisitos só se sustentam se o usuário conseguir acessar de fato a interface de consentimento.

Um usuário de leitor de tela que não consegue navegar até o botão "Recusar" não pode negar seu consentimento. O consentimento que seu pipeline de analytics registra para esse usuário é legalmente inválido — não porque ele o tenha recusado, mas porque o mecanismo era inacessível. Sob o GDPR, isso equivale à ausência total de consentimento.

A CNIL deixou essa lógica clara em sua ação de fiscalização de setembro de 2025 contra o Google, onde uma multa de €325 milhões decorreu em parte de um design assimétrico — aceitar exigia um clique, recusar exigia navegar até uma tela de configurações. O princípio se generaliza: qualquer design que torne a recusa estruturalmente mais difícil do que a aceitação, incluindo um banner inacessível que um usuário de teclado não consegue operar completamente, compromete a validade legal de cada registro de consentimento que ele gera.

Os resultados de auditoria não são animadores

Testes independentes de plataformas de gerenciamento de consentimento amplamente utilizadas em 2025 concluíram que nenhuma das soluções examinadas atendia plenamente ao WCAG 2.2 Nível AA. As falhas mais comuns incluíam indicadores de foco suprimidos, contraste insuficiente nos botões de ação secundária e marcação do banner posicionada no final do DOM, fazendo com que leitores de tela chegassem ao conteúdo da página antes da interface de consentimento.

Não são casos extremos. É o comportamento padrão de ferramentas que dezenas de milhares de sites implantam porque querem usar analytics sem realizar a análise legal por conta própria.

O que um banner conforme custaria operacionalmente

Suponha que você corrija os problemas de acessibilidade. Agora você tem um banner que um leitor de tela consegue navegar completamente, com controles acessíveis por teclado, contraste suficiente e sem fechamento automático. Ainda assim, você enfrentará:

• Perda de dados por recusa: Estudos mostram consistentemente que entre 15 e 30% dos visitantes rejeitam cookies de analytics ou fecham o banner sem interagir. Essa população é invisível para o seu analytics.
• Variabilidade da taxa de consentimento por dispositivo: Usuários móveis fecham banners com mais frequência do que usuários de desktop. Seus dados de analytics são sistematicamente enviesados em direção aos usuários que aceitaram no desktop.
• Manutenção contínua: O WCAG 2.2 já está em desenvolvimento rumo ao WCAG 3.0. Cada atualização da sua plataforma de consentimento é uma potencial regressão na conformidade de acessibilidade que você precisa retestar.

Corrigir o banner trata da exposição à EAA. Não trata do problema de qualidade dos dados.

A alternativa estrutural

Analytics sem cookies que nunca toca o dispositivo — sem cookies, sem localStorage, sem fingerprinting — não aciona os requisitos de consentimento do PECR. Nenhum mecanismo de consentimento é necessário, portanto nenhuma interface de consentimento existe para ser inacessível.

A abordagem do hash diário de visitante — SHA-256(IP + UA + SALT_SECRET + YYYY-MM-DD) — é executada inteiramente no servidor na borda (edge), não produz nenhum identificador persistente e não armazena nada no dispositivo do visitante. Não há interação para o WCAG governar nem registro de consentimento para o GDPR validar.

Isso não é um contorno. É a consequência técnica de construir um sistema de analytics que genuinamente não processa dados pessoais. Quando não há nada para consentir, toda a maquinaria de consentimento e suas obrigações de conformidade desaparecem.

As duas perguntas que vale a pena fazer agora

Se seu site atualmente executa analytics por trás de um banner de consentimento, duas perguntas determinam sua exposição:

1. Um usuário que usa apenas o teclado consegue chegar à opção
   "Recusar tudo" no seu banner sem mouse, com um indicador de
   foco visível, em todos os navegadores que você suporta?

2. Se sim — qual percentual de visitantes recusa ou fecha o banner,
   e como seu analytics leva em conta essa lacuna?

A primeira pergunta é a pergunta da EAA. A segunda é a pergunta da qualidade dos dados. Um banner de consentimento conforme que 20% dos visitantes fecha ainda deixa você com um ponto cego de 20% que se acumula ao longo do tempo enquanto suas decisões são tomadas sobre dados de tráfego incompletos.

Nenhuma das duas perguntas surge se não há nenhum banner para navegar.