WCAG 3.3.9: Autenticação Acessível (Aprimorada)

O Que Esta Regra Significa

WCAG 3.3.9 — Autenticação Acessível (Aprimorada) é o equivalente em nível AAA à WCAG 3.3.8 (Autenticação Acessível — Mínimo, AA). Juntas, elas formam um par de critérios introduzidos na WCAG 2.2, projetados para garantir que o processo de comprovar identidade a um site ou aplicativo não se torne, por si só, uma barreira de acessibilidade.

No nível AAA, a 3.3.9 torna os requisitos significativamente mais rígidos. O critério afirma: Um teste de função cognitiva não deve ser exigido em nenhuma etapa de um processo de autenticação, a menos que essa etapa forneça pelo menos um dos seguintes: um método de autenticação alternativo que não dependa de um teste de função cognitiva; um mecanismo esteja disponível para ajudar o usuário a concluir o teste de função cognitiva; ou o teste de função cognitiva seja reconhecer objetos. De forma crítica, ao contrário da versão AA (3.3.8), o critério AAA remove a exceção que permitia reconhecer conteúdo que não fosse objeto (como imagens de itens não-objetos que o usuário selecionou anteriormente). Neste nível, apenas o verdadeiro reconhecimento de objetos — reconhecer objetos comuns do mundo real, como imagens de um gato, uma bicicleta ou uma casa — é permitido como teste de função cognitiva, e somente se as outras condições não forem atendidas.

Um teste de função cognitiva é definido como qualquer tarefa que exija que o usuário se lembre, manipule ou transcreva informações. Isso inclui: lembrar um nome de usuário ou senha, resolver um quebra-cabeça matemático, completar um CAPTCHA que exija decifrar texto distorcido, responder a uma pergunta de segurança sobre histórico pessoal (por exemplo, "Qual era o nome do seu primeiro animal de estimação?") ou transcrever uma sequência de caracteres. Todos esses representam tarefas de memória ou transcrição que muitos usuários não conseguem realizar de forma confiável.

O que conta como aprovação: Uma etapa de autenticação atende à 3.3.9 se não exigir qualquer teste de função cognitiva, ou se atender a uma destas condições: (1) é oferecido um caminho de autenticação completamente separado e não cognitivo (por exemplo, um link mágico enviado por e-mail, WebAuthn/passkey, login biométrico); (2) um mecanismo auxilia na conclusão do teste (por exemplo, o gerenciador de senhas do navegador não é bloqueado, ou copiar e colar é permitido); ou (3) o único teste cognitivo envolvido é reconhecer um objeto comum do mundo real em um conjunto de imagens.

O que conta como reprovação: Qualquer fluxo que force o usuário — sem desvio ou alternativa — a lembrar uma senha de memória, transcrever um código que não pode ser colado, resolver um CAPTCHA visual ou de áudio sem alternativa, responder a perguntas de segurança baseadas em conhecimento ou identificar imagens previamente selecionadas de conteúdo que não seja objeto (por exemplo, formas abstratas ou fotos pessoais) sem um caminho de autenticação alternativo.

Exceções oficiais: A própria especificação WCAG observa que reconhecer objetos (fotografias de coisas do mundo real) é a única tarefa de reconhecimento de imagem permitida neste nível AAA. O critério AA (3.3.8) também permitia reconhecer imagens "não-objeto" escolhidas pessoalmente, mas a 3.3.9 remove essa exceção por completo. Não há exceção para padrões de autenticação "amplamente utilizados" — se um padrão exige um teste cognitivo sem alternativa, ele falha na 3.3.9.

Por Que Isso Importa

A autenticação é frequentemente a primeira interação significativa que um usuário tem com um serviço digital. Se essa interação for, em si, inacessível, o restante da acessibilidade do site torna-se irrelevante — o usuário simplesmente não consegue entrar. A WCAG 3.3.9 aborda diretamente essa barreira, e seu impacto abrange uma ampla gama de grupos de pessoas com deficiência.

Usuários com deficiências cognitivas — incluindo pessoas com dislexia, TDAH, lesão cerebral traumática, demência ou dificuldades de aprendizagem — podem achar extremamente difícil ou impossível memorizar senhas complexas, transcrever manualmente códigos únicos com tempo limitado ou decodificar texto distorcido em CAPTCHAs. A Organização Mundial da Saúde estima que aproximadamente 1 em cada 6 pessoas no mundo vivenciam algum tipo de deficiência significativa, e as deficiências cognitivas representam uma das maiores e mais negligenciadas categorias em acessibilidade na web.

Usuários com deficiências motoras — como pessoas com doença de Parkinson, tremor essencial, lesões na medula espinhal ou condições que exigem acesso por varredura (switch) ou tecnologia de rastreamento ocular — podem ter dificuldade em digitar senhas com precisão ou transcrever códigos caractere por caractere. Bloquear colagem da área de transferência (uma medida antifraude comum que é ativamente prejudicial) significa que esses usuários precisam inserir cada caractere de forma trabalhosa por meio de seu dispositivo assistivo, aumentando dramaticamente as taxas de erro e a fadiga.

Usuários cegos ou com baixa visão podem depender inteiramente de leitores de tela ou ferramentas de ampliação. CAPTCHAs visuais são completamente inacessíveis sem uma alternativa em áudio, e mesmo CAPTCHAs em áudio são notoriamente difíceis para usuários com deficiências auditivas ou distúrbios de processamento auditivo. Desafios baseados em imagem do tipo "selecione todos os semáforos" também podem ser problemáticos quando as descrições das imagens estão ausentes ou são enganosas.

Usuários surdos ou com deficiência auditiva podem enfrentar barreiras em métodos de autenticação que dependem exclusivamente de chamadas telefônicas para entregar códigos únicos, especialmente quando essas chamadas são apenas de voz, sem alternativa por SMS.

Um cenário concreto do mundo real: Considere um usuário de 72 anos com declínio cognitivo leve tentando acessar seu portal de banco on-line. O banco exige um nome de usuário (que deve ser lembrado, não o endereço de e-mail), uma senha complexa (colagem da área de transferência é bloqueada) e um CAPTCHA envolvendo texto distorcido. O usuário falha no CAPTCHA duas vezes, é bloqueado e precisa ligar para a central de atendimento do banco — um processo de 40 minutos. Se o banco tivesse implementado passkeys ou um link mágico, esse usuário teria se autenticado em segundos. Esse cenário se repete milhões de vezes diariamente na web, e é totalmente evitável.

Além da deficiência, a autenticação acessível beneficia todos os usuários. Gerenciadores de senhas, usados por centenas de milhões de pessoas, dependem da capacidade de colar credenciais. Bloquear colagem, exigir transcrição manual ou incorporar CAPTCHAs inacessíveis frustra também usuários em geral. Há ainda argumentos de segurança: forçar a digitação manual de senhas complexas aumenta a probabilidade de os usuários escolherem senhas mais simples e fracas ou reutilizarem senhas em vários sites. Passkeys e links mágicos, as alternativas recomendadas, são ao mesmo tempo mais acessíveis e mais seguras do que fluxos tradicionais de senha mais CAPTCHA.

Regras Relacionadas do Axe-core

WCAG 3.3.9 é classificada como exigindo apenas testes manuais. A partir do axe-core 4.10, não há regra automatizada que avalie totalmente esse critério. Entender por que ferramentas automatizadas não conseguem detectar essas violações exige entender o que o critério está realmente medindo.

• Teste manual necessário — detecção de função cognitiva: Varredores automatizados podem detectar a presença de certos elementos HTML (como um <input type='password'> ou um iframe incorporando um widget CAPTCHA de terceiros), mas não conseguem determinar se um fluxo de autenticação completo exige um teste de função cognitiva sem alternativa acessível. O critério diz respeito a toda a jornada do usuário, potencialmente em várias etapas e páginas, não às propriedades de um único elemento. Um varredor não consegue avaliar se a colagem é bloqueada programaticamente via JavaScript, se um limite de tempo em um campo de entrada de código é razoável ou se um caminho de autenticação alternativo realmente evita testes cognitivos. Essas são questões comportamentais e arquiteturais que exigem que um avaliador humano percorra o processo de autenticação real.
• Teste manual necessário — verificação de caminho alternativo: Mesmo que um varredor detecte um widget CAPTCHA, ele não consegue verificar se existe um método de autenticação alternativo acessível na mesma página ou no mesmo fluxo. Ele não consegue avaliar se uma opção "use uma passkey em vez disso" é genuinamente equivalente ou se está escondida em uma página de configurações secundária que, por sua vez, exige passar primeiro pelo CAPTCHA inacessível. Avaliar a equivalência de caminhos alternativos exige julgamento humano sobre a completude e a proeminência dessas alternativas.
• Teste manual necessário — comportamento de colagem da área de transferência: JavaScript que intercepta eventos de paste e os cancela (event.preventDefault() em um listener de paste) é invisível para análise estática de HTML. Um varredor vê um elemento <input> válido; ele não tem como saber que colar nele foi desabilitado. Apenas testes manuais — tentar fisicamente colar uma senha ou código — podem revelar essa falha.
• Teste manual necessário — compatibilidade de widgets de autenticação com tecnologias assistivas: SDKs de autenticação de terceiros (botões de login social, provedores de CAPTCHA, prompts biométricos) podem ser renderizados em iframes ou Shadow DOM que varredores automatizados não conseguem penetrar totalmente. Testes manuais com leitores de tela como NVDA, JAWS e VoiceOver são essenciais para confirmar que todos os elementos interativos dentro do fluxo de autenticação são operáveis e compreensíveis.

Como Testar

1. Identifique todos os pontos de entrada de autenticação: Antes de testar, mapeie todos os locais no aplicativo em que um usuário precisa se autenticar ou verificar sua identidade. Isso inclui login inicial, criação de conta, redefinição de senha, prompts de autenticação em duas etapas, reautenticação após expiração de sessão, telas de confirmação de pagamento e barreiras de verificação de idade. Cada um desses fluxos deve ser avaliado de forma independente.
2. Execute uma varredura automatizada de base: Use o axe DevTools (extensão de navegador) ou o Lighthouse no Chrome DevTools em cada página de autenticação. Embora essas ferramentas não sinalizem diretamente violações da 3.3.9, elas revelarão problemas relacionados — rótulos ausentes em campos de formulário, conteúdo de iframe inacessível, gerenciamento de foco ausente — que agravam barreiras de autenticação. Anote quaisquer problemas sinalizados como contexto para a avaliação manual. No axe DevTools, consulte a aba "Needs Review" para itens que exigem julgamento manual.
3. Audite em busca de testes de função cognitiva: Para cada etapa de autenticação, pergunte: esta etapa exige que o usuário (a) se lembre de algo, (b) transcreva algo ou (c) resolva um quebra-cabeça? Em caso afirmativo, verifique se pelo menos um dos seguintes está presente e é igualmente proeminente: um caminho alternativo não cognitivo; um mecanismo (como permitir colagem da área de transferência ou um campo compatível com preenchimento automático) que auxilie na conclusão; ou que a única tarefa cognitiva seja reconhecer um objeto comum do mundo real.
4. Teste o comportamento de colagem da área de transferência: Em cada campo de senha e de entrada de código, copie uma sequência de texto para a área de transferência e tente colá-la usando Ctrl+V (Windows/Linux) ou Cmd+V (macOS). Se a colagem for bloqueada, isso é uma falha. Teste também se o preenchimento automático do gerenciador de senhas do navegador é suprimido (verifique se há autocomplete='off' ou JavaScript que limpe valores de preenchimento automático ao focar).
5. Teste com NVDA + Firefox: Navegue por todo o fluxo de autenticação usando apenas o teclado e o leitor de tela NVDA. Verifique se todos os campos de formulário são anunciados com rótulos significativos, se todos os controles interativos (botões, links, desafios de CAPTCHA) são alcançáveis e operáveis e se quaisquer mensagens de erro estão programaticamente associadas ao campo relevante e são anunciadas imediatamente, sem exigir navegação adicional.
6. Teste com VoiceOver + Safari (macOS/iOS): Repita todo o fluxo de autenticação. No iOS, verifique também se a autenticação biométrica (Face ID / Touch ID) é oferecida como alternativa quando a autenticação nativa é usada e se o fluxo baseado na web é totalmente operável com o Switch Control caso a biometria não esteja disponível.
7. Teste com JAWS + Chrome: Repita o fluxo, prestando atenção especial a como widgets de terceiros (login social via OAuth, iframes de CAPTCHA) são anunciados. O JAWS lida com certos padrões ARIA de forma diferente do NVDA; ambos devem ser testados.
8. Avalie caminhos alternativos quanto à verdadeira equivalência: Se existir um método de autenticação alternativo (por exemplo, "Entrar com um link mágico"), conclua todo o fluxo usando apenas essa alternativa. Confirme que ele atinge o mesmo estado autenticado sem exigir qualquer teste cognitivo. Se o próprio caminho alternativo contiver um CAPTCHA ou teste de memória, ele não é uma alternativa válida sob a 3.3.9.
9. Documente as descobertas com evidências: Para cada falha, capture uma gravação de tela ou captura de tela anotada mostrando exatamente qual etapa falha e por quê. Essa documentação é essencial para repassar a correção às equipes de desenvolvimento e para fins de trilha de auditoria.

Como Corrigir

CAPTCHA sem alternativa — Incorreto

<!-- Fails 3.3.9: The only authentication path requires solving a visual CAPTCHA.
     No alternative is provided, and there is no object-recognition option. -->
<form method='post' action='/login'>
  <label for='username'>Username</label>
  <input type='text' id='username' name='username' autocomplete='username'>

  <label for='password'>Password</label>
  <input type='password' id='password' name='password' autocomplete='off'>

  <!-- Third-party CAPTCHA widget with no accessible alternative path -->
  <div class='g-recaptcha' data-sitekey='YOUR_SITE_KEY'></div>

  <button type='submit'>Log In</button>
</form>

CAPTCHA substituído por passkey e link mágico — Correto

<!-- Passes 3.3.9: CAPTCHA removed entirely. Primary path uses a passkey
     (WebAuthn — no cognitive test). A magic link fallback is offered
     for devices without passkey support. Password entry allows paste
     and browser autofill. -->
<form method='post' action='/login'>
  <label for='email'>Email address</label>
  <input type='email' id='email' name='email' autocomplete='email'>

  <!-- Passkey login: no password to remember, no CAPTCHA -->
  <button type='button' id='passkey-btn'>Sign in with Passkey</button>

  <!-- Password fallback: paste and autofill explicitly enabled -->
  <label for='password'>Password (optional)</label>
  <input type='password' id='password' name='password'
         autocomplete='current-password'>
  <!-- NOTE: Do NOT add autocomplete='off' or paste-blocking JS here -->

  <button type='submit'>Log In</button>
</form>

<!-- Non-cognitive alternative: magic link -->
<p><a href='/send-magic-link'>Send me a sign-in link instead</a></p>

<script>
  // WebAuthn passkey authentication — no cognitive function test
  document.getElementById('passkey-btn').addEventListener('click', async () => {
    const credential = await navigator.credentials.get({ publicKey: publicKeyOptions });
    // submit credential to server
  });
</script>

Colagem bloqueada no campo de OTP — Incorreto

<!-- Fails 3.3.9: The one-time code field blocks paste via JavaScript,
     forcing users to manually transcribe a time-limited code.
     This is a transcription cognitive function test with no bypass. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='off'>

<script>
  document.getElementById('otp').addEventListener('paste', function(e) {
    e.preventDefault(); // Blocks paste — FAILS 3.3.9
  });
</script>

Campo de OTP com colagem habilitada e dica de autocomplete — Correto

<!-- Passes 3.3.9: Paste is allowed. The autocomplete='one-time-code' attribute
     enables browsers and password managers to automatically fill the OTP,
     eliminating the transcription requirement entirely. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='one-time-code'>

<!-- No paste-blocking JavaScript. autocomplete='one-time-code' allows
     the OS (iOS, Android, desktop browsers) to suggest the OTP
     automatically from SMS or authenticator apps. -->

Perguntas de segurança baseadas em conhecimento — Incorreto

<!-- Fails 3.3.9: Requiring answers to knowledge-based security questions
     is a memory-recall cognitive function test. No alternative is offered. -->
<form method='post' action='/verify-identity'>
  <p>To verify your identity, please answer your security question:</p>
  <label for='sq-answer'>What was the name of your childhood pet?</label>
  <input type='text' id='sq-answer' name='sq-answer' autocomplete='off'>
  <button type='submit'>Verify</button>
</form>

Verificação de identidade com alternativas não cognitivas — Correto

<!-- Passes 3.3.9: Security questions replaced with email magic link
     and government ID upload options — neither requires memory recall.
     If security questions are retained for some users, a clearly labeled
     alternative path is provided upfront. -->
<form method='post' action='/verify-identity'>
  <p>We need to verify your identity. Choose one of the following methods:</p>

  <fieldset>
    <legend>Verification method</legend>

    <label>
      <input type='radio' name='verify-method' value='magic-link' checked>
      Send a verification link to my registered email
    </label>

    <label>
      <input type='radio' name='verify-method' value='id-upload'>
      Upload a photo of a government-issued ID
    </label>
  </fieldset>

  <button type='submit'>Continue</button>
</form>

Erros Comuns

• Adicionar autocomplete='off' a campos de senha para impedir o preenchimento automático do navegador. Isso desabilita o principal mecanismo que permite aos usuários evitar memorizar senhas e falha diretamente na 3.3.9. Remova autocomplete='off' e use autocomplete='current-password' ou autocomplete='new-password' em seu lugar.
• Anexar um listener de evento de paste em JavaScript que chama event.preventDefault() em campos de entrada de autenticação, acreditando que isso melhora a segurança. Na realidade, isso bloqueia gerenciadores de senhas e tecnologias assistivas e constitui um requisito de transcrição sob a 3.3.9.
• Tratar a alternativa de CAPTCHA em áudio como um desvio suficiente para CAPTCHAs visuais. CAPTCHAs em áudio ainda constituem um teste de função cognitiva (transcrever caracteres de áudio distorcidos) e não satisfazem a 3.3.9. É necessário um caminho alternativo verdadeiramente não cognitivo.
• Oferecer uma opção de passkey ou login social, mas colocá-la atrás de um desafio de CAPTCHA primeiro. Se o usuário precisar passar por um teste cognitivo para acessar a alternativa acessível, a alternativa não é genuinamente equivalente e o fluxo falha na 3.3.9.
• Usar seis campos <input> separados de um único caractere para entrada de OTP (um padrão de UI comum) sem suportar colagem para preenchimento em todos os campos. Muitas implementações apenas colam no primeiro campo e exigem digitação manual, caractere por caractere, nos cinco restantes, o que é uma barreira de transcrição.
• Confiar em "Lembrar-me" ou cookies de sessão persistentes como a única acomodação para usuários que não conseguem se autenticar repetidamente. Embora reduzir a frequência de autenticação ajude, isso não corrige um processo de autenticação inacessível — os usuários ainda precisam passar pelo teste cognitivo pelo menos uma vez, e sessões expiram ou são limpas.
• Implementar campos de OTP com tempo limitado que são limpos ao expirar sem aviso, forçando os usuários a solicitar um novo código e tentar a transcrição novamente. Isso aumenta a carga cognitiva para usuários com velocidade motora ou de processamento cognitivo mais lenta.
• Usar desafios de CAPTCHA baseados em imagem que exigem reconhecer conteúdo que não seja objeto — como padrões abstratos, cores ou sequências de fotos pessoais selecionadas — e acreditar que isso satisfaz a 3.3.9. O critério AAA só permite reconhecimento de objetos (objetos do mundo real como carros, bicicletas, semáforos); reconhecimento de imagens que não sejam objetos não é isento neste nível.
• Bloquear o acesso ao gerenciador de credenciais do navegador via autocomplete='new-password' em campos de login (em vez de campos de registro). O valor new-password sinaliza aos navegadores que este é um campo para criação de nova senha, impedindo o preenchimento automático de credenciais salvas durante o login.
• Deixar de testar fluxos de autenticação com tecnologias assistivas reais e, em vez disso, confiar apenas em resultados de varreduras automatizadas. Como a 3.3.9 é testável apenas manualmente, equipes que pulam testes manuais com leitores de tela e teclado perderão sistematicamente falhas neste critério em todos os ciclos de lançamento.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial nº 2025/10 da Turquia, publicada no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece obrigações abrangentes de acessibilidade web e móvel para uma ampla gama de entidades públicas e privadas que operam na Turquia. A circular exige conformidade com a WCAG 2.2, tornando-se o primeiro instrumento jurídico turco a referenciar explicitamente a versão 2.2 do padrão.

As entidades abrangidas pela circular incluem: instituições e órgãos públicos em todos os níveis de governo; plataformas de e-commerce e marketplaces on-line; bancos e instituições financeiras; hospitais e prestadores de serviços de saúde; operadoras de telecomunicações com 200.000 ou mais assinantes; agências de viagens; empresas de transporte privado; e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE). Para essas organizações, serviços digitais — incluindo portais de login, portais de pacientes, painéis bancários, sistemas de emissão de bilhetes e sistemas de informação estudantil — devem atender aos requisitos de acessibilidade definidos pela circular.

A WCAG 3.3.9, como um critério de nível AAA, não é uma obrigação legal mínima sob a circular. A base legalmente exigida corresponde à conformidade com a WCAG 2.2 nos níveis A e AA. No entanto, o espírito e o escopo da circular tornam a 3.3.9 altamente relevante na prática por várias razões.

Primeiro, a WCAG 3.3.8 (Autenticação Acessível — Mínimo) é um requisito de nível AA e, portanto, é juridicamente vinculante para todas as entidades abrangidas. Organizações que trabalham para cumprir a 3.3.8 descobrirão que o caminho para a conformidade com a 3.3.9 é frequentemente um pequeno passo incremental — principalmente remover a exceção de reconhecimento de imagem que a 3.3.8 permite e garantir que todos os testes cognitivos tenham alternativas não cognitivas, não apenas mecanismos de assistência.

Segundo, para entidades que prestam serviços a populações com taxas mais altas de deficiência cognitiva ou motora — especialmente hospitais, portais públicos de saúde e portais de serviços governamentais — alcançar conformidade AAA em critérios de autenticação representa um compromisso significativo com o acesso igualitário, alinhado com os princípios constitucionais mais amplos de igualdade da Turquia e com as obrigações do país sob a Convenção da ONU sobre os Direitos das Pessoas com Deficiência (CRPD), que a Turquia ratificou.

Terceiro, bancos turcos e provedores de fintech enfrentam escrutínio particular em relação à autenticação. A Agência de Regulação e Supervisão Bancária (BDDK) e a Unidade de Investigação de Crimes Financeiros (MASAK) impõem requisitos rigorosos de verificação de identidade, e as organizações frequentemente implementam fluxos de autenticação complexos e em várias etapas para satisfazer esses requisitos. Implementar autenticação compatível com a 3.3.9 — usando passkeys, WebAuthn ou fluxos de link mágico — é ao mesmo tempo mais acessível e alinhado com as melhores práticas modernas de autenticação segura endossadas por reguladores financeiros internacionais, tornando-o um objetivo de design que atende à conformidade em múltiplas frentes simultaneamente.

Organizações que buscam diferenciar sua postura de acessibilidade, se preparar para um possível endurecimento regulatório futuro ou atender usuários de maneiras acessíveis e inclusivas são fortemente encorajadas a tratar a WCAG 3.3.9 como um padrão de design, não apenas como um aprimoramento opcional. Implementar caminhos de autenticação totalmente não cognitivos é cada vez mais viável com APIs modernas de navegador (WebAuthn/passkeys) e SDKs de autenticação, tornando o custo de conformidade mais baixo do que nunca, enquanto o benefício — eliminar uma das barreiras de acessibilidade mais consequentes em qualquer produto digital — é substancial.