WCAG 3.3.8: Autenticação Acessível (Mínimo)

O que Esta Regra Significa

WCAG 3.3.8 Autenticação Acessível (Mínimo) é um critério de Nível AA introduzido no WCAG 2.2. Ele estabelece que um teste de função cognitiva — definido como uma tarefa que exige que o usuário memorize, manipule ou transcreva informações — não pode ser o único meio de concluir uma etapa de autenticação, a menos que pelo menos uma das seguintes condições seja atendida:

• Método alternativo: Outro caminho de autenticação está disponível que não depende de um teste de função cognitiva (por exemplo, um link mágico enviado por e-mail, login biométrico ou uma passkey).
• Mecanismo de assistência: O user agent ou uma ferramenta de terceiros tem permissão para concluir a etapa em nome do usuário — por exemplo, um gerenciador de senhas preenchendo automaticamente as credenciais, ou uma ação de copiar e colar para um código de uso único.
• Exceção de reconhecimento de objeto: O teste de função cognitiva envolve identificar um objeto em uma imagem (por exemplo, selecionar todas as imagens que contêm um semáforo) — esse tipo de teste é permitido no nível Mínimo (AA).
• Exceção de conteúdo pessoal: O teste depende de conteúdo fornecido pelo próprio usuário, como selecionar uma foto enviada anteriormente a partir de uma grade.

Na prática, um formulário de login que exige apenas nome de usuário e senha está em conformidade com esse critério, desde que o formulário permita o preenchimento automático do navegador e o funcionamento de gerenciadores de senhas (ou seja, os campos usam <input type='password'> padrão e não bloqueiam colar). Um CAPTCHA que exige a transcrição de texto distorcido sem qualquer rota alternativa de autenticação é uma falha clara. Um CAPTCHA que pede aos usuários para selecionar imagens que correspondem a uma categoria (reconhecimento de objeto) é permitido no nível AA, mas é tratado de forma mais rigorosa no AAA (3.3.9).

O critério se aplica a todas as etapas de um processo de autenticação: login inicial, autenticação reforçada, verificação multifator, recuperação de conta e reautenticação de sessão. Ele também se aplica a qualquer processo que proteja o acesso a funcionalidades, não apenas à tela principal de login.

Uma implicação técnica importante é que desenvolvedores não devem usar autocomplete='off' em campos de autenticação, não devem desabilitar colar por meio de manipuladores de eventos JavaScript e não devem quebrar as semânticas padrão de entrada que permitem que tecnologias assistivas e o preenchimento automático do navegador funcionem corretamente.

Por Que Isso Importa

A autenticação é um portal para praticamente todos os serviços digitais dos quais as pessoas dependem diariamente — bancos, portais de saúde, serviços governamentais, e-commerce e plataformas de comunicação. Quando esse portal impõe barreiras cognitivas, ele exclui sistematicamente uma parcela significativa da população.

Deficiências cognitivas abrangem um amplo espectro: dislexia, discalculia, transtornos de déficit de atenção, lesões cerebrais adquiridas, demência, deficiências intelectuais e transtornos de ansiedade. 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 condições cognitivas e neurológicas representam uma das maiores categorias. Para esses usuários, tarefas como transcrever com precisão uma sequência de caracteres distorcidos, resolver um quebra-cabeça visual sob pressão de tempo ou alternar entre um app autenticador e um formulário de login podem ser genuinamente impossíveis ou profundamente exaustivas.

Considere um cenário concreto: uma pessoa com dislexia tenta fazer login no portal de seu plano de saúde para ver resultados de exames. O site apresenta um CAPTCHA de texto sem alternativa em áudio e sem forma de contorná-lo. As formas de letras distorcidas são indistinguíveis para essa pessoa, e o campo de entrada bloqueia colar. Após várias tentativas fracassadas, a conta é bloqueada. A pessoa não consegue acessar informações médicas sensíveis ao tempo. Isso não é um caso hipotético extremo — é uma experiência rotineira para milhões de pessoas.

Usuários com deficiência motora que dependem de acesso por varredura (switch access) ou dispositivos de rastreamento ocular também são afetados. Reescrever um código de uso único complexo a partir de um dispositivo separado, ou arrastar blocos de imagem para uma ordem específica, pode ser fisicamente impossível com esses métodos de entrada. Permitir copiar e colar ou autenticação baseada em passkey elimina completamente essa barreira.

Idosos representam outro grupo significativo. O declínio cognitivo relacionado à idade afeta memória e velocidade de processamento, tornando CAPTCHAs complexos e tarefas de memorização em múltiplas etapas desproporcionalmente difíceis. À medida que as populações na Turquia e globalmente envelhecem, o argumento de negócios e regulatório para autenticação acessível se torna mais forte a cada ano.

Do ponto de vista de usabilidade e conversão, atrito em fluxos de autenticação aumenta diretamente as taxas de abandono. Plataformas de e-commerce que substituem CAPTCHAs de texto por autenticação baseada em risco ou passkeys relatam consistentemente taxas mais altas de conclusão de login e menores custos de suporte relacionados a contas bloqueadas.

Regras Relacionadas do Axe-core

WCAG 3.3.8 é classificado como exigindo testes manuais porque ferramentas automatizadas não conseguem avaliar completamente se um processo de autenticação impõe um teste de função cognitiva inacessível. Determinar se um fluxo de login não tem caminho alternativo, ou se colar é bloqueado de forma dependente de contexto, exige julgamento humano e interação com um fluxo de autenticação real. Dito isso, alguns verificadores automatizados dão suporte a esse critério:

• Revisão manual — auditoria do fluxo de autenticação: Testadores devem percorrer cada etapa de autenticação e determinar se há um teste de função cognitiva presente e, em caso afirmativo, se existe um método alternativo ou mecanismo de assistência em conformidade. Nenhuma regra do axe-core atualmente é disparada automaticamente para esse critério porque a lógica depende de entender o propósito e o contexto dos campos de formulário e da interface ao redor, não apenas sua marcação.
• Verificações do atributo autocomplete (relacionado): A regra autocomplete-valid do axe-core sinaliza campos de entrada cujo valor do atributo autocomplete não é retirado da lista de tokens do WCAG 1.3.5. Embora essa regra tenha como alvo diretamente o 1.3.5, ela é uma verificação de suporte para 3.3.8: se autocomplete='username' e autocomplete='current-password' estiverem ausentes ou configurados incorretamente, gerenciadores de senhas não podem preencher automaticamente, removendo o mecanismo de assistência que torna o login padrão por senha compatível com 3.3.8.
• Detecção de bloqueio de colar — manual: Scanners automatizados não conseguem detectar de forma confiável JavaScript que intercepta eventos de paste e os suprime em campos de autenticação. Um testador manual deve tentar colar uma credencial ou OTP em cada campo relevante e confirmar que a ação é bem-sucedida.
• Detecção de alternativa ao CAPTCHA — manual: O axe-core pode detectar a presença de widgets CAPTCHA comuns (por exemplo, iframes do reCAPTCHA), mas não consegue determinar se um caminho alternativo de autenticação é oferecido em outro lugar na página ou por uma rota diferente. Essa determinação exige inspeção manual de toda a experiência de autenticação.

Como Testar

1. Varredura automatizada (axe DevTools / Lighthouse): Execute o axe DevTools em cada página de autenticação (login, registro, recuperação de conta, MFA). Procure violações de autocomplete-valid em campos de nome de usuário e senha. No Lighthouse, revise a auditoria de Acessibilidade em busca de problemas relacionados a formulários. Observe que nenhuma regra automatizada irá sinalizar de forma definitiva uma falha em 3.3.8 — resultados automatizados são apenas um ponto de partida.
2. Identifique todos os testes de função cognitiva: Catalogue manualmente cada etapa do fluxo de autenticação. Observe qualquer etapa que exija que o usuário recorde informações não fornecidas na tela atual, transcreva caracteres, resolva um quebra-cabeça ou realize um cálculo. Verifique se cada uma dessas etapas possui uma alternativa em conformidade (reconhecimento de objeto, conteúdo pessoal, método alternativo de login ou mecanismo de assistência).
3. Teste a funcionalidade de colar: Em cada campo de autenticação (nome de usuário, senha, OTP, código de recuperação), tente colar texto usando o atalho de teclado (Ctrl+V no Windows/Linux, Cmd+V no macOS). Confirme que o conteúdo colado aparece no campo. Repita usando o menu de contexto do clique direito. Se colar for bloqueado, isso é uma falha, a menos que exista uma alternativa sem função cognitiva.
4. Teste o preenchimento automático com um gerenciador de senhas: Usando um navegador com um gerenciador de senhas (nativo ou baseado em extensão), salve credenciais durante o registro e depois retorne à página de login. Confirme que o gerenciador de senhas consegue detectar os campos e preenchê-los automaticamente. Teste no Firefox com NVDA, Safari com VoiceOver (macOS/iOS) e Chrome com JAWS para cobrir as principais combinações de tecnologia assistiva + navegador. Se os campos usam marcação não padrão ou JavaScript que limpa valores preenchidos automaticamente, isso é uma falha.
5. NVDA + Firefox — navegação com leitor de tela: Navegue pelo formulário de login usando apenas o teclado e o NVDA. Confirme que cada campo é alcançável, que os rótulos dos campos são anunciados corretamente e que qualquer widget CAPTCHA possui uma alternativa acessível. Se o CAPTCHA for puramente visual, sem opção em áudio e sem caminho alternativo de login, registre uma falha.
6. VoiceOver + Safari (iOS): Em um dispositivo móvel, tente fazer login usando Face ID ou Touch ID se o site oferecer login biométrico. Confirme que a opção biométrica é alcançável via navegação por gestos de deslizar e que o VoiceOver a anuncia corretamente. Isso valida que uma alternativa sem função cognitiva é operacionalmente acessível, não apenas presente nominalmente.
7. Verifique limites de tempo em etapas cognitivas: Se um CAPTCHA ou entrada de OTP impuser um limite de tempo, verifique se o usuário pode estendê-lo ou desativá-lo (relevante para 2.2.1) e, separadamente, observe se a etapa cronometrada constitui um teste de função cognitiva sem alternativa.

Como Corrigir

CAPTCHA de texto sem alternativa — Incorreto

<!-- Fails 3.3.8: only authentication method is transcribing distorted text;
     no alternative login path is offered, and paste is disabled -->
<form action='/login' method='post'>
  <label for='user'>Username</label>
  <input type='text' id='user' name='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='off'
         onpaste='return false;'>

  <img src='/captcha-image.png' alt=''>
  <label for='captcha'>Type the characters above</label>
  <input type='text' id='captcha' name='captcha'
         autocomplete='off'
         onpaste='return false;'>

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

CAPTCHA de texto sem alternativa — Correto

<!-- Passes 3.3.8: text CAPTCHA is replaced with a passkey / magic-link option;
     password field supports autofill and paste so password managers can assist -->
<form action='/login' method='post'>
  <label for='user'>Username or email</label>
  <input type='text' id='user' name='username'
         autocomplete='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='current-password'>

  <!-- No CAPTCHA; bot protection handled server-side via risk-based signals -->
  <button type='submit'>Log in</button>
</form>

<!-- Cognitive-function-free alternative always visible -->
<p><a href='/magic-link'>Send me a sign-in link by email instead</a></p>
<p><a href='/passkey-login'>Sign in with a passkey or biometrics</a></p>

Campo de OTP bloqueando colar — Incorreto

<!-- Fails 3.3.8: user must manually type a 6-digit OTP;
     paste is suppressed, forcing a transcription task -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='off'
       onpaste='event.preventDefault();'
       ondrop='event.preventDefault();'>

Campo de OTP bloqueando colar — Correto

<!-- Passes 3.3.8: paste and autofill are permitted;
     autocomplete='one-time-code' enables OS-level SMS/OTP autofill on mobile -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='one-time-code'>
<!-- Remove all paste/drop prevention handlers.
     Risk of credential stuffing is managed server-side, not by blocking paste. -->

CAPTCHA de seleção de imagem sem alternativa (preocupação AAA, aprovado em AA) — Correto em AA

<!-- Passes 3.3.8 (AA): object recognition CAPTCHAs are explicitly
     exempted at the Minimum level. Selecting images of bicycles
     qualifies as object recognition, not character transcription.
     Note: this would fail 3.3.9 (AAA) — provide an alternative for full conformance. -->
<fieldset>
  <legend>Select all images that contain a bicycle</legend>
  <ul role='list'>
    <li>
      <input type='checkbox' id='img1' name='captcha' value='1'>
      <label for='img1'>
        <img src='/grid/img1.jpg' alt='A city street with parked vehicles'>
      </label>
    </li>
    <!-- additional grid items -->
  </ul>
</fieldset>

Erros Comuns

• Definir autocomplete='off' em campos de senha: Isso desabilita o preenchimento automático de gerenciadores de senhas, removendo o mecanismo de assistência que torna a autenticação padrão por senha compatível. Use autocomplete='current-password' em vez disso e deixe o navegador gerenciar o armazenamento de credenciais.
• Bloquear colar com onpaste='return false;' ou addEventListener('paste', e => e.preventDefault()): Isso força os usuários a digitar credenciais manualmente, criando uma tarefa de transcrição inacessível. Remova todos os manipuladores de prevenção de colar dos campos de autenticação.
• Oferecer uma opção de passkey que não é acessível por teclado: Uma alternativa biométrica só satisfaz 3.3.8 se for alcançável e operável via teclado e tecnologia assistiva. Um botão de passkey escondido atrás de um menu acionado por hover ou renderizado como um <div> não focável não conta como alternativa em conformidade.
• Usar um CAPTCHA de texto como única estratégia de mitigação de bots: Migrar para detecção de bots baseada em risco no lado do servidor (analisando impressão digital do dispositivo, cadência de digitação, reputação de IP) elimina completamente o teste de função cognitiva sem sacrificar a segurança. Confiar apenas em CAPTCHA no lado do cliente é tanto uma falha de acessibilidade quanto uma prática de segurança ruim.
• Dividir um OTP em vários campos de um único caractere e bloquear colar entre campos: Algumas implementações usam seis campos separados <input maxlength='1'> para entrada de OTP e avançam o foco automaticamente via JavaScript. Esse padrão rotineiramente quebra o colar a partir de gerenciadores de senhas e viola 3.3.8, a menos que a implementação trate explicitamente o colar de um código inteiro no primeiro campo e distribua os caracteres corretamente.
• Exigir CAPTCHA baseado em imagem apenas em fluxos de recuperação de conta: Equipes frequentemente adicionam alternativas de login acessíveis à página principal de login, mas esquecem autenticação reforçada, redefinição de senha e fluxos de desbloqueio de conta. Cada um desses é uma etapa de autenticação separada e deve cumprir 3.3.8 de forma independente.
• Tratar CAPTCHA em áudio como alternativa completa ao CAPTCHA de texto: Uma alternativa em áudio atende usuários cegos, mas não ajuda usuários com deficiências cognitivas ou aqueles em ambientes barulhentos. CAPTCHAs em áudio também apresentam seu próprio requisito de transcrição. A correção adequada é eliminar o CAPTCHA ou fornecer um caminho que não tenha qualquer teste de função cognitiva.
• Gerar dinamicamente IDs de campos de entrada que quebram a detecção por gerenciadores de senhas: Quando atributos id em campos de nome de usuário e senha são randomizados a cada carregamento de página (uma técnica equivocada de combate a bots), gerenciadores de senhas não conseguem identificar os campos de forma confiável. Isso efetivamente desabilita o preenchimento automático e remove o mecanismo de assistência em conformidade.
• Presumir que widgets CAPTCHA de terceiros são automaticamente compatíveis: Serviços CAPTCHA populares podem oferecer variantes acessíveis, mas elas não são ativadas por padrão. Desenvolvedores devem configurar explicitamente a versão acessível e ainda precisam verificar se ela atende aos requisitos da norma, em vez de simplesmente adicionar um novo tipo de teste inacessível.
• Limpar valores preenchidos automaticamente via JavaScript ao focar: Alguns formulários limpam o conteúdo de entrada quando um campo recebe foco para exibir texto de placeholder ou solicitar redigitação. Se esse comportamento limpar o valor preenchido automaticamente por um gerenciador de senhas, ele força a digitação manual e falha em 3.3.8.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece obrigações de acessibilidade web e móvel alinhadas ao WCAG 2.2. A circular exige que as entidades abrangidas alcancem conformidade de Nível AA em seus produtos e serviços digitais. WCAG 3.3.8, como critério de Nível AA no WCAG 2.2, está, portanto, diretamente dentro do escopo dos requisitos obrigatórios de conformidade introduzidos por essa circular.

A circular abrange uma ampla gama de entidades dos setores público e privado. Instituições públicas e órgãos governamentais devem alcançar conformidade AA completa. No setor privado, a circular se aplica a plataformas de e-commerce, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde privados, operadoras de telecomunicações com 200.000 ou mais assinantes, agências de viagem, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE). Para essas organizações, fluxos de autenticação inacessíveis — como páginas de login com CAPTCHAs sem suporte ou campos de OTP que bloqueiam colar — criam exposição regulatória direta.

O Logotipo de Acessibilidade (Erişilebilirlik Logosu), emitido pelo Ministério da Família e Serviços Sociais, é a marca oficial de certificação de conformidade em acessibilidade digital na Turquia. Obter esse logotipo exige conformidade demonstrada de Nível AA, que inclui 3.3.8. Para operadores de e-commerce, bancos e outros provedores de serviços digitais de alto tráfego, o logotipo funciona como um sinal de confiança pública e pode ser mencionado em requisitos de compras e licitações. Fluxos de autenticação que dependem de testes cognitivos inacessíveis impediriam a certificação e exporiam a organização a reclamações e ações de fiscalização.

Do ponto de vista prático de conformidade, organizações turcas devem auditar cada ponto de contato de autenticação — incluindo login, registro, MFA, redefinição de senha e desbloqueio de conta — em relação a 3.3.8 antes de enviar para avaliação do Logotipo de Acessibilidade. Substituir CAPTCHAs de texto por controles baseados em risco no lado do servidor, habilitar autocomplete em todos os campos de credenciais e oferecer alternativas de passkey ou link mágico são as ações de remediação de maior impacto. Essas mudanças satisfazem simultaneamente o requisito regulatório e melhoram a experiência de autenticação para os estimados 8,5 milhões de pessoas com deficiência na Turquia que usam serviços digitais.