Por que um captcha é um problema de acessibilidade
Duas afirmações circulam: que a WCAG proíbe captchas e que por isso veio uma onda de notificações extrajudiciais. Nenhuma se sustenta. Ainda assim, um captcha de imagem continua sendo a resposta mais fraca ao problema que pretende resolver.
Duas frases aparecem em quase todo guia sobre o assunto. A primeira: a WCAG proíbe captchas. A segunda: por causa disso corre uma onda de notificações extrajudiciais. A primeira cai na leitura do texto dos critérios, a segunda cai na busca por casos documentados.
O incômodo é que um argumento falso prejudica uma causa correta. Um captcha de imagem diante de um formulário de contato é a resposta mais fraca disponível para o problema que ele pretende resolver. Para enxergar isso não é preciso inventar uma proibição.
O que a WCAG diz de fato sobre captchas
A WCAG 2.2 é a versão em vigor desde 12 de dezembro de 2024 e tem status de W3C Recommendation. Captchas aparecem nela em dois pontos, e esses dois pontos são confundidos o tempo todo.
1.1.1 pede uma alternativa, não uma proibição
O critério de sucesso 1.1.1 Non-text Content está no nível A. Para captchas ele exige "text alternatives that identify and describe the purpose of the non-text content" e, junto disso, "alternative forms of CAPTCHA using output modes for different types of sensory perception". Ou seja: uma alternativa textual que diga para que o elemento está ali e pelo menos mais uma forma de captcha voltada a outro canal sensorial.
Um captcha só de imagem, sem alternativa, viola 1.1.1. Esse é o ponto aplicável no formulário de contato, e é o único. Até onde vai a exceção o próprio W3C esclarece: "WCAG still requires that alternative text identify the graphical object as a CAPTCHA."
3.3.8 vale no login, não no formulário de contato
O critério 3.3.8 Accessible Authentication (Minimum) é novidade da WCAG 2.2 e está no nível AA. A frase de abertura: "A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following." Duas palavras decidem o alcance, "authentication process". Um captcha diante de um formulário de contato, de comentários ou de newsletter, sem login, não é alcançado. Ali vale somente 1.1.1.
E mesmo dentro do processo de acesso, o documento Understanding do W3C sobre 3.3.8 diz o contrário do que muita gente conclui: "While recognizing objects, or a picture the user has previously provided, are cognitive function tests, these are excepted in this criterion at AA level." Um "selecione todas as imagens com semáforos" portanto não reprova em 3.3.8 no nível AA. Quem afirma o contrário não leu o critério.
A exceção não é ilimitada: contas de somar saem da lista assim que o teste vai além do reconhecimento. E no nível AAA a avaliação vira, porque o critério 3.3.9 Accessible Authentication (Enhanced) mantém apenas as exceções Alternative e Mechanism.
Por que a alternativa em áudio não fecha a lacuna
A resposta óbvia a 1.1.1 é o botão de alto-falante ao lado da imagem. Por que ele não basta está no documento do W3C "Inaccessibility of CAPTCHA", que desde 16 de dezembro de 2021 é uma Group Draft Note, ou seja, um rascunho sem efeito normativo.
O som não tem equivalente à imagem parada: quem escuta não consegue examinar o desafio com calma. O estudo citado no documento constatou que os captchas em áudio ficaram incompreensíveis para as quatro pessoas testadas, todas com boa audição. A distorção que deveria barrar as máquinas destrói a inteligibilidade. Além disso, o áudio exclui pessoas surdas, e quem tem perda visual e auditiva ao mesmo tempo fica de fora por completo.
Some-se um ponto normativo: segundo o documento Understanding de 3.3.8, uma alternativa em áudio que precise ser transcrita não cumpre a exceção Alternative. E o canal acessível é ao mesmo tempo o canal menos seguro: o documento do W3C cita um trabalho da Universidade de Maryland que resolveu o reCAPTCHA em áudio do Google em cerca de 90 por cento dos casos usando o próprio reconhecimento de voz do Google. A WebAIM Screen Reader User Survey #10 (1.539 respostas, dezembro de 2023 e janeiro de 2024) coloca os captchas em primeiro lugar entre os elementos mais problemáticos, sem mudança há 14 anos.
O que a lei europeia de acessibilidade exige e a quem ela alcança
O que vem a seguir é uma leitura da situação jurídica em 21 de agosto de 2026 e não é consultoria jurídica. Quem precisa de segurança no caso concreto resolve isso com um advogado.
O European Accessibility Act, a Diretiva (UE) 2019/882, é direito da União Europeia e vale em todos os Estados membros para serviços prestados a consumidores a partir de 28 de junho de 2025. No Brasil essa diretiva não se aplica; ela entra na conta de quem atende clientes na União Europeia. A transposição é nacional e sai diferente em cada país, então os limites e as exceções concretas precisam ser conferidos na norma do país em questão. Como exemplo serve aqui a lei alemã de transposição, o Barrierefreiheitsstärkungsgesetz (BFSG), porque a redação dela mostra bem onde fica o ponto sensível: o § 2 nº 26 BFSG define serviços de comércio eletrônico como serviços digitais prestados a pedido individual de um consumidor "com vistas à celebração de um contrato de consumo". A última parte é o que pesa. Uma loja online cumpre isso, um site de mera apresentação, sem contratação, não. É o que também explica o FAQ sobre o BFSG da agência federal alemã de acessibilidade.
A isso se soma o § 3, item 3 BFSG, que dispensa microempresas prestadoras de serviços. Microempresa é, segundo o § 2 nº 17 BFSG, quem emprega menos de dez pessoas e ao mesmo tempo não passa de 2 milhões de euros de faturamento anual ou de 2 milhões de euros de balanço anual. A dispensa vale só para serviços: o § 1, item 2 BFSG lista de forma fechada os produtos alcançados e são categorias de hardware, de modo que um plugin de WordPress vendido como download não é produto no sentido dessa lei. Como isso está resolvido na norma de outro Estado membro é outra questão e precisa ser visto lá.
O gancho do captcha está no regulamento alemão de execução. O § 19 nº 2 BFSGV exige que, nos serviços de comércio eletrônico, as funções de identificação, autenticação, segurança e pagamento sejam perceptíveis, operáveis, compreensíveis e robustas. Um captcha é função de segurança nesse sentido, e o § 12 nº 2 letra g BFSGV acrescenta uma apresentação alternativa dos conteúdos não textuais.
A norma que todo mundo cita não está harmonizada para o EAA
Em 21 de agosto de 2026 não havia nenhuma norma harmonizada do European Accessibility Act listada no Jornal Oficial da União Europeia. A agência federal alemã de acessibilidade escreve expressamente que as normas previstas no mandato de normalização M/587 ainda não foram publicadas, então nessa data não existe presunção de conformidade, na Alemanha conforme o § 4 BFSG. A tão citada harmonização da EN 301 549 V3.2.1 pela Decisão de Execução (UE) 2021/1339 diz respeito à diretiva web (UE) 2016/2102, voltada a órgãos do setor público. Muitos guias tratam as duas coisas como uma só, e a contradição segue sem solução.
O BFSGV, de resto, não menciona a EN 301 549 em lugar nenhum: o § 3, item 1 dele exige o estado da técnica. Um detalhe: a versão publicada V3.2.1, de março de 2021, remete à WCAG 2.1, de modo que o critério 3.3.8 nem sequer está incorporado por meio da norma.
O que existe de fato documentado em matéria de multas
Na data da pesquisa, 21 de agosto de 2026, não foi possível localizar na Alemanha nenhuma multa nem notificação extrajudicial confirmada por tribunal que tivesse por objeto especificamente um captcha não acessível. A autoridade competente lá é o órgão de fiscalização de mercado dos estados alemães (MLBF), em Magdeburgo, em funcionamento desde 26 de setembro de 2025, que não publica números de casos. A faixa do § 37, item 2 BFSG chega, para operadores de sites, a cem mil euros.
Documentado, por fontes de escritórios de advocacia, é que desde o verão europeu de 2025 circulam notificações extrajudiciais (Abmahnungen) baseadas no BFSG. Cita-se a CLAIM Rechtsanwalts GmbH, de Düsseldorf, em nome de uma pessoa física, com cobranças em torno de 595 euros. Nada disso é específico de captcha, e se as regras do BFSG são cobráveis por essa via, pelo § 3a UWG, a lei alemã contra a concorrência desleal, ainda não foi decidido por tribunal. Disso não decorre carta branca: um formulário pelo qual parte dos interessados não consegue passar custa contatos, com ou sem autoridade de fiscalização.
Para onde vão os dados quando o captcha vem da nuvem
Google LLC e Cloudflare, Inc. ficam nos Estados Unidos. A base jurídica da transferência é a decisão de adequação do EU-US Data Privacy Framework, de 10 de julho de 2023. O Tribunal Geral da União Europeia julgou improcedente a ação de anulação em 3 de setembro de 2025 (T-553/23, Latombe contra Comissão), mas a decisão não é definitiva: há recurso no Tribunal de Justiça desde 31 de outubro de 2025 (C-703/25 P). Os dois fornecedores são apenas autocertificados.
No Google mudou algo relevante em 2 de abril de 2026: o reCAPTCHA passou a operar no mundo todo como operador de tratamento e, segundo a documentação do Google, desde então o cliente é "the sole data controller of Customer Data". Se isso derruba a necessidade de consentimento é questão em aberto, porque o acesso ao dispositivo do usuário é regulado nacionalmente e não depende do papel que se tem sob o RGPD europeu. Na Alemanha quem faz isso é o § 25 TDDDG. Até agora existe uma única decisão claramente citável sobre o reCAPTCHA, e ela é austríaca: o Tribunal Administrativo Federal de lá decidiu em 13 de setembro de 2024 (W298 2274626-1/8E) que o reCAPTCHA sem consentimento prévio viola o RGPD. No Brasil vale a LGPD, que também exige uma base legal para o tratamento de dados pessoais, mas essa decisão trata do regime europeu e não pode ser transportada sem exame.
O Cloudflare Turnstile em regra dispensa desafios de imagem e de áudio e se descreve no próprio blog de 29 de setembro de 2023 como "WCAG 2.1 Level AA compliant". No texto sobre o redesenho, de 27 de fevereiro de 2026, entra ainda o objetivo WCAG 2.2 AAA. São declarações do fornecedor, e não existe relatório de auditoria independente para nenhum dos dois. O nó prático fica de todo modo no banner de consentimento: se o captcha precisa de consentimento, quem recusa não passa pelo formulário.
Quatro métodos que não pedem nada de ninguém
A finalidade de um captcha é barrar bots. Para isso ele impõe uma tarefa a cada visitante e descarta uma parcela pequena. Existem métodos que não exigem nada de ninguém: o documento do W3C cita honeypots, heurísticas e filtros de spam.
Honeypot: um campo que só as máquinas enxergam
O formulário ganha um campo extra, invisível para pessoas. Um visitante nunca o preenche, um bot que preenche cegamente todos os campos preenche. Se no envio ele não estiver vazio, o caso está decidido. A implementação importa: um campo apenas deslocado visualmente, mas mantido na árvore de acessibilidade, é lido pelo leitor de tela e passa a pegar justamente as pessoas que não deveria pegar. Ele precisa ser marcado com aria-hidden e ficar fora da ordem de tabulação. O limite: quem mira o seu site especificamente deixa o campo em branco daí em diante. Contra os bots de massa habituais funciona de forma confiável.
Armadilha de tempo: quanto tempo levou o preenchimento
Na entrega do formulário vai junto uma marca de tempo assinada e, no envio, o servidor compara quanto tempo passou. Quem preenche um formulário em menos de dois segundos não o leu. O limiar deve ficar baixo, porque alguns visitantes preenchem com autopreenchimento em frações de segundo. Um bot pode esperar, mas esperar derruba a vazão dele: o método encarece o ataque, não o impede.
Limite de frequência: quanto chega da mesma origem
O servidor conta os envios que chegam da mesma origem dentro de uma janela de tempo e recusa a partir de um limiar. Isso freia a origem única que dispara cem vezes contra um formulário e não resolve nada em ataques distribuídos por muitos endereços. O limiar não pode ser apertado demais, porque em redes corporativas e em redes móveis muita gente divide um mesmo endereço.
Avaliação do conteúdo: o que a mensagem diz
O quarto caminho olha para o texto. Uma classificação bayesiana avalia a mensagem a partir de exemplos marcados antes como spam ou como desejados, e roda inteiramente no seu próprio servidor. Ela pega também a propaganda que uma pessoa mandou na mão, e tem uma taxa de erro. Em que uma checagem local difere de um filtro na nuvem é o assunto do artigo sobre a alternativa ao Akismet.
| Método | Esforço para o usuário | Acessibilidade | Para onde vão os dados | Contra bots de massa | Contra ataques direcionados |
|---|---|---|---|---|---|
| Captcha de imagem | Resolver uma tarefa, 32 segundos em média segundo o documento do W3C | Viola a WCAG 1.1.1 sem alternativa para outro canal sensorial | Para o fornecedor, em regra para os Estados Unidos | Funciona enquanto a tarefa não puder ser resolvida automaticamente | Canal de áudio resolvido em cerca de 90 por cento no estudo citado |
| Captcha invisível vindo da nuvem | Em geral nenhum | Declaração do fornecedor de WCAG 2.1 AA, sem auditoria independente | Para o fornecedor nos Estados Unidos, com a questão do consentimento em aberto | Funciona | Não verificável, a detecção não é divulgada |
| Honeypot mais armadilha de tempo | Nenhum | Sem impacto quando o campo é retirado da árvore de acessibilidade | Para lugar nenhum, tudo fica no seu próprio servidor | Funciona contra bots que preenchem cegamente todo formulário | Um bot feito sob medida contorna |
| Checagem local do conteúdo | Nenhum | Sem impacto, o visitante não percebe nada | Para lugar nenhum, tudo fica no seu próprio servidor | Funciona, inclusive com propaganda enviada na mão | Depende do texto, não do remetente |
O que acontece quando a checagem erra
Todo método que descarta automaticamente descarta errado uma hora, na nuvem e localmente. A pergunta, portanto, não é se um contato real será atingido, e sim o que acontece com ele depois. Se for descartado em silêncio, ninguém fica sabendo: o interessado espera resposta e quem cuida do site vê uma caixa de entrada tranquila. Proteção contra spam sem um arquivo consultável é perda silenciosa de contatos.
A coisa fica utilizável com três elementos: mensagens descartadas ficam em uma lista com busca, em cada uma consta qual checagem disparou, e um button libera a mensagem depois e devolve esse resultado para a avaliação. Se você vai reformar o formulário de qualquer jeito, o lado dos campos está no artigo sobre as alternativas ao Contact Form 7.
Proteção contra spam que não pede nada de ninguém
O Wellenbrecher checa honeypot, armadilha de tempo, limite de frequência e o texto da mensagem direto na sua instalação. Sem serviço na nuvem, sem cota de checagens, sem captcha diante do formulário.
O Wellenbrecher está no diretório do WordPress desde 21 de agosto de 2026 e o nível Free pode ser usado também comercialmente sem custo. O Pro custa 19 euros por ano para um site e acrescenta prova de trabalho, proteção do checkout do WooCommerce, GeoIP e ASN, consulta ao AbuseIPDB e uma segunda opinião de IA com chave própria. A licença de frota para dez sites custa 69 euros. Preços sem imposto sobre valor agregado, em 21 de agosto de 2026, visão geral na página de preços.
Perguntas frequentes
A WCAG proíbe captchas?
Não. O critério 1.1.1 Non-text Content, no nível A, exige em um captcha uma alternativa textual que descreva a finalidade do elemento e, além dela, outra forma de captcha para um canal sensorial diferente. Um captcha de imagem sem alternativa nenhuma viola isso. Um captcha de imagem com uma alternativa utilizável não viola.
O critério 3.3.8 vale também para um formulário de contato sem login?
Não. A frase de abertura de 3.3.8 se refere a etapas de um processo de autenticação. Um captcha diante de um formulário de contato, de comentários ou de newsletter, sem login, não é alcançado, e ali vale apenas 1.1.1. Dentro do processo de acesso, captchas de imagem baseados no simples reconhecimento de objetos ficam expressamente excetuados no nível AA segundo o documento Understanding do W3C, enquanto no nível AAA, no critério 3.3.9, não ficam.
Uma alternativa em áudio ao lado do captcha de imagem basta?
O documento do W3C sobre a inacessibilidade dos captchas diz que não. O som não pode ser examinado com calma como uma imagem parada, a distorção que barra as máquinas destrói a inteligibilidade, e pessoas surdas e surdocegas ficam de fora por completo. O documento Understanding de 3.3.8 registra ainda que uma alternativa em áudio que precise ser transcrita não cumpre a exceção Alternative.
Existem multas ou notificações por captchas inacessíveis?
Na data da pesquisa, 21 de agosto de 2026, não foi possível localizar na Alemanha nenhuma multa nem notificação confirmada por tribunal que tivesse por objeto especificamente um captcha não acessível. Documentadas estão notificações gerais baseadas no BFSG desde o verão europeu de 2025, com cobranças em torno de 595 euros e sem relação com captcha. Se essas regras são sequer cobráveis pela via do § 3a UWG ainda não foi decidido por tribunal. Carta branca isso não é.
O que protege um formulário quando não há captcha diante dele?
Quatro métodos que não exigem nada do visitante: um campo honeypot que só máquinas preenchem, uma armadilha de tempo que detecta envios rápidos demais, um limite de frequência contra envios em série da mesma origem e uma avaliação do conteúdo do texto. Contra os bots de massa habituais essa combinação funciona. Um ataque feito sob medida para o seu site contorna o honeypot e a armadilha de tempo.
