WCAG 2.1.2: Sem armadilha de teclado

O Que Esta Regra Significa

WCAG 2.1.2 — Sem Armadilha de Teclado — é um critério de sucesso de Nível A sob o princípio Operável. Ele afirma: "Se o foco do teclado puder ser movido para um componente da página usando uma interface de teclado, então o foco poderá ser movido para fora desse componente usando apenas uma interface de teclado e, se for necessário mais do que teclas de seta ou Tab não modificadas para mover o foco para fora, o usuário será informado sobre o método para mover o foco."

Em termos práticos, isso significa que todo componente interativo em uma página da web no qual um usuário de teclado possa entrar com Tab também deve permitir que o usuário saia dele com Tab. Uma armadilha de teclado ocorre quando um usuário navega para dentro de um widget, diálogo, controle de formulário personalizado, player de mídia incorporado ou qualquer outra região focável e então é incapaz de sair usando controles padrão de teclado — ele fica, na prática, preso.

O critério abrange todos os elementos HTML que podem receber foco de teclado: elementos interativos nativos como tags <input>, <select>, <textarea>, <button> e <a>, bem como widgets personalizados que recebem foco via tabindex, papéis ARIA ou gerenciamento de foco em JavaScript. Aplica-se igualmente a componentes de terceiros incorporados, como widgets de chat, players de vídeo, mapas incorporados, seletores de data e editores de rich text.

Um componente atende a este critério se um usuário de teclado sempre puder mover o foco para fora dele usando teclas padrão — tipicamente Tab, Shift+Tab, Escape ou teclas de seta — ou se a página informar claramente os usuários sobre um mecanismo de teclado não padrão para mover o foco para fora. Um componente falha se o foco ficar bloqueado dentro dele sem nenhuma rota de saída acessível por teclado, ou se o único mecanismo de saída exigir um clique de mouse, gesto de toque ou outra entrada que não seja de teclado.

As WCAG fornecem uma exceção limitada: é aceitável restringir o foco do teclado dentro de um componente temporariamente quando isso fizer parte de um padrão de design deliberado e acessível — mais notavelmente, um diálogo modal. Um diálogo modal deve prender o foco dentro do diálogo enquanto estiver aberto (para impedir que usuários interajam com conteúdo de fundo obscurecido), mas deve sempre fornecer um meio acessível por teclado para fechar o diálogo e liberar o foco — como um manipulador da tecla Escape ou um botão de fechar claramente rotulado e alcançável com Tab. Esse tipo de contenção de foco intencional e escapável não é uma armadilha de teclado; é uma implementação correta do padrão de diálogo modal. A armadilha só se torna uma falha quando o usuário não consegue escapar de forma alguma.

Por Que Isso Importa

Armadilhas de teclado são uma das falhas de acessibilidade mais graves que um site pode ter. Diferentemente de muitos outros problemas de acessibilidade que degradam a experiência para certos usuários, uma armadilha de teclado pode bloquear completamente um usuário de continuar a usar uma página. É essencialmente o equivalente a colocar uma barreira física em um corredor e não fornecer nenhuma forma de contorná-la.

Os grupos mais severamente afetados são usuários com deficiências motoras ou físicas que não conseguem operar um mouse e dependem inteiramente da navegação por teclado. Isso inclui pessoas com condições como lesão por esforço repetitivo, esclerose múltipla, doença de Parkinson, quadriplegia e paralisia cerebral. De acordo com a Organização Mundial da Saúde, aproximadamente 1,3 bilhão de pessoas — 16% da população global — vivem com algum tipo de deficiência significativa, e deficiências motoras representam uma parcela substancial desse número. Para esses usuários, encontrar uma armadilha de teclado em uma página de checkout, um formulário de login ou um widget de chat de atendimento ao cliente pode significar que eles são totalmente incapazes de concluir a tarefa.

Usuários de leitores de tela — principalmente pessoas cegas e com baixa visão — também são fortemente afetados. Leitores de tela como NVDA, JAWS e VoiceOver navegam inteiramente por comandos de teclado. Se o foco ficar preso em um componente, o usuário do leitor de tela ouve o mesmo elemento repetido ao pressionar Tab, sem nenhuma forma de avançar ou retroceder pela página. Isso é profundamente desorientador e força o usuário a fechar a aba do navegador ou atualizar a página, perdendo qualquer progresso que tenha feito.

Considere este cenário do mundo real: uma pessoa com mobilidade limitada nas mãos visita um site de e-commerce turco para comprar um produto. Ela adiciona um item ao carrinho e segue para o checkout. A página de checkout inclui um widget de preenchimento automático de endereço de terceiros, construído com um framework JavaScript personalizado. O widget abre uma lista suspensa de sugestões quando o campo de endereço recebe foco. O desenvolvedor esqueceu de adicionar tratamento de eventos de teclado para fechar essa lista suspensa — então, uma vez que o usuário entra no campo de endereço com Tab e a lista suspensa aparece, ele não consegue sair com Tab, não consegue pressionar Escape e não consegue fechar a lista suspensa sem um clique de mouse. O usuário fica completamente impedido de concluir a compra. Isso não é um pequeno incômodo — é uma exclusão total do serviço.

Além do acesso para pessoas com deficiência, armadilhas de teclado também afetam usuários avançados que preferem navegação por teclado pela rapidez, usuários em ambientes corporativos onde o uso de mouse é restrito e usuários em certos dispositivos móveis ou híbridos com teclados físicos. Corrigir armadilhas de teclado, portanto, melhora a experiência para um público mais amplo do que apenas usuários com deficiência.

Regras Relacionadas do Axe-core

WCAG 2.1.2 exige testes manuais. Nenhuma regra automatizada do axe-core detecta armadilhas de teclado de forma direta e confiável. Isso ocorre porque ferramentas automatizadas operam analisando a estrutura estática do DOM — elas podem identificar elementos focáveis, verificar a ordem de tabulação e validar atributos ARIA, mas não podem simular a experiência completa de navegação interativa por teclado que um testador humano realiza. Uma armadilha de teclado normalmente surge da lógica de tratamento de eventos JavaScript que intercepta ou suprime eventos de teclado em tempo de execução; esse comportamento não é visível na estrutura do DOM e não pode ser inferido por um analisador estático.

• Teste manual obrigatório — nenhuma regra dedicada do axe-core: O axe-core não inclui uma regra que detecte automaticamente armadilhas de teclado porque o modo de falha é fundamentalmente comportamental. A armadilha só se manifesta quando um usuário realmente navega para dentro de um componente com a tecla Tab e tenta sair. Um scanner automatizado não pode replicar isso porque precisaria simular navegação sequencial por teclado em cada elemento focável da página, acionar todos os listeners de eventos JavaScript associados e então determinar se o foco escapou da região pretendida — um problema computacionalmente intratável para páginas complexas. Além disso, o que constitui uma armadilha versus contenção de foco intencional (como um modal) exige julgamento contextual que regras automatizadas não conseguem fazer de forma confiável. Testadores devem usar axe DevTools ou Lighthouse para identificar elementos focáveis e problemas de ordem de tabulação como ponto de partida, mas depois precisam navegar manualmente com teclado por cada região interativa para confirmar que não existem armadilhas.

Como Testar

1. Execute uma varredura automatizada de acessibilidade como linha de base. Abra o axe DevTools (extensão de navegador) ou execute uma auditoria de acessibilidade do Lighthouse no Chrome DevTools. Embora nenhuma das ferramentas sinalize diretamente uma armadilha de teclado, a varredura identificará elementos focáveis, papéis ARIA ausentes e ordem de tabulação incorreta que podem indicar componentes interativos arriscados que valem a pena investigar manualmente. Observe quaisquer widgets personalizados, iframes incorporados, componentes de terceiros, diálogos modais, menus suspensos, seletores de data, carrosséis e editores de rich text — essas são as fontes mais comuns de armadilhas de teclado.
2. Desconecte ou afaste o mouse. Para que o teste manual de teclado seja válido, você não deve usar um mouse. Coloque o mouse fora de alcance ou desative-o nas configurações do sistema operacional para evitar depender dele acidentalmente durante o teste.
3. Navegue pela página inteira usando apenas as teclas Tab e Shift+Tab. Começando pela barra de endereços do navegador ou pelo topo da página, pressione Tab repetidamente e observe para onde o foco se move. Acompanhe visualmente o indicador de foco a cada passo. Quando você alcançar cada componente interativo — especialmente qualquer widget personalizado, conteúdo incorporado ou elemento de interface complexo — verifique se pressionar Tab ou Shift+Tab move o foco de forma limpa para fora do componente, para o próximo ou anterior elemento focável na página.
4. Teste cada componente interativo individualmente. Para diálogos modais: abra o modal, verifique se o foco se move para dentro dele, depois pressione Escape e confirme se o foco retorna ao elemento que o acionou. Para menus suspensos: abra o menu, navegue dentro dele, depois pressione Escape e confirme se o menu fecha e o foco retorna ao gatilho. Para seletores de data, seletores de cor e widgets semelhantes: entre com Tab, interaja e depois saia com Tab, confirmando que o foco é removido. Para iframes incorporados (por exemplo, mapas, players de vídeo, widgets de chat): entre no iframe com Tab, navegue dentro dele e confirme que você consegue sair dele com Tab de volta para a página principal.
5. Teste com NVDA e Firefox. Abra o NVDA, navegue até a página no Firefox e use Tab para percorrer os elementos interativos. Preste atenção se o NVDA lê um novo elemento a cada vez que você pressiona Tab ou se parece voltar ao mesmo elemento. Se Tab não avançar o foco além de um componente, isso é uma armadilha de teclado.
6. Teste com VoiceOver e Safari no macOS. Ative o VoiceOver (Command + F5), abra a página no Safari e use a tecla Tab para navegar. Confirme que o VoiceOver anuncia um novo elemento a cada pressionamento de Tab e que o foco nunca fica preso em uma região da qual você não consegue sair.
7. Teste com JAWS e Chrome. Abra o JAWS, navegue pela página no Chrome e use Tab para percorrer todos os componentes interativos. Teste especificamente qualquer componente que use gerenciamento de foco acionado por JavaScript, já que o JAWS interage com a árvore de acessibilidade de maneiras que podem revelar armadilhas não visíveis apenas com testes visuais.
8. Verifique mecanismos de escape não padrão. Se algum componente exigir uma tecla diferente de Tab, Shift+Tab ou Escape para sair, verifique se a página comunica isso claramente ao usuário — por exemplo, por meio de instruções na tela, um tooltip ou um anúncio em região ao vivo ARIA quando o foco entra no componente.

Como Corrigir

Diálogo Modal Sem Tratamento da Tecla Escape — Incorreto

<!-- Modal abre mas não tem manipulador da tecla Escape nem botão de fechar alcançável por teclado -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- Sem botão de fechar, sem listener da tecla Escape -- usuários de teclado ficam presos -->
</div>

Diálogo Modal Sem Tratamento da Tecla Escape — Correto

<!-- Modal com armadilha de foco adequada, manipulador da tecla Escape e botão de fechar acessível -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- Botão de fechar é alcançável com Tab e permite que usuários de teclado saiam -->
  <button id='modal-close' onclick='closeModal()' aria-label='Close dialog'>Cancel</button>
</div>

<script>
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') {
      closeModal(); // Tecla Escape fecha o modal e retorna o foco ao gatilho
    }
  });

  function closeModal() {
    document.getElementById('modal').hidden = true;
    document.getElementById('modal-trigger').focus(); // Retorna o foco ao elemento que abriu
  }
</script>

Dropdown Personalizado Capturando Todos os Eventos da Tecla Tab — Incorreto

<!-- Dropdown personalizado intercepta todos os eventos keydown, incluindo Tab, impedindo que o foco saia -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='true'>
  <ul role='listbox'>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  // BUG: Isto captura TODOS os eventos de teclado e chama preventDefault em Tab,
  // o que significa que o usuário nunca consegue sair deste componente com Tab
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    e.preventDefault(); // Isto prende o teclado
    if (e.key === 'ArrowDown') { /* move o foco para baixo */ }
    if (e.key === 'ArrowUp') { /* move o foco para cima */ }
  });
</script>

Dropdown Personalizado Capturando Todos os Eventos da Tecla Tab — Correto

<!-- Correto: Só chama preventDefault para teclas de seta usadas para navegação interna;
     permite que Tab e Escape funcionem normalmente para que usuários possam sair -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='false'>
  <ul role='listbox' hidden>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    if (e.key === 'ArrowDown' || e.key === 'ArrowUp') {
      e.preventDefault(); // Só impede o padrão para teclas de navegação interna
      // move o foco entre as opções
    }
    if (e.key === 'Escape' || e.key === 'Tab') {
      // NÃO chame preventDefault -- permita que Tab e Escape se propaguem
      // para que o navegador possa mover o foco para fora deste componente naturalmente
      closeDropdown();
    }
  });
</script>

Iframe de Terceiros Incorporado Sem Caminho de Saída — Incorreto

<!-- Um iframe de widget de chat incorporado que absorve todas as teclas Tab
     e nunca retorna o foco à página pai -->
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<!-- O JavaScript interno do iframe consome eventos de Tab, prendendo usuários dentro dele -->

Iframe de Terceiros Incorporado Sem Caminho de Saída — Correto

<!-- Use um botão para abrir o chat em uma nova janela em vez de incorporar
     um iframe que possa prender usuários de teclado -->
<button
  id='open-chat'
  onclick='window.open("https://example-chat-widget.com", "_blank", "noopener")'>
  Open Customer Support Chat (opens in new window)
</button>

<!-- Se um iframe precisar ser usado, adicione um link de pular visível antes dele
     para que usuários de teclado possam ignorá-lo se quiserem -->
<a href='#after-chat-widget' class='skip-link'>Skip chat widget</a>
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<span id='after-chat-widget' tabindex='-1'></span>

Erros Comuns

• Chamar event.preventDefault() dentro de um listener de keydown sem restringi-lo a teclas específicas — aplicar preventDefault() a todos os eventos de teclado em um componente focável bloqueia o funcionamento de Tab e Shift+Tab, criando instantaneamente uma armadilha de teclado. Sempre restrinja preventDefault() apenas às teclas específicas que seu componente precisa tratar internamente (como teclas de seta para listboxes).
• Construir um diálogo modal que define o foco dentro dele, mas não fornece manipulador da tecla Escape nem botão de fechar — desenvolvedores frequentemente implementam corretamente a parte de entrada de foco do padrão de modal, mas esquecem que a contenção de foco dentro de um modal só é aceitável se houver sempre uma saída acessível por teclado. Todo modal deve tratar a tecla Escape e incluir um botão de fechar tabulável.
• Usar tabindex='-1' em um elemento contêiner para impedir que ele apareça na ordem de tabulação, enquanto ainda permite que o JavaScript mova o foco para dentro dele programaticamente — quando o foco é movido para um elemento com tabindex='-1' via element.focus(), não há alvo natural de Tab para sair dele, o que pode deixar o usuário preso se nenhum tratamento adicional de teclado for implementado.
• Incorporar widgets de terceiros (chat, mapas, vídeo) sem auditá-los quanto a comportamento de armadilha de teclado — fornecedores nem sempre constroem seus widgets incorporados para serem acessíveis por teclado. Donos de sites continuam responsáveis por todo o conteúdo em suas páginas, incluindo embeds de terceiros. Sempre teste componentes incorporados manualmente e, se eles prenderem usuários de teclado, envolva-os com um link de pular ou substitua-os por uma alternativa segura para teclado.
• Implementar uma armadilha de foco para um modal ou gaveta, mas não liberá-la quando o componente é fechado — se o JavaScript que restringe o foco não for devidamente limpo quando o modal fecha, ele pode continuar interceptando eventos de Tab e prender o usuário na camada agora invisível.
• Usar CSS visibility: hidden ou display: none para ocultar o botão de fechar de um diálogo por razões de design visual sem fornecer uma saída alternativa por teclado — se o botão de fechar estiver visualmente oculto, mas não removido da árvore de acessibilidade, usuários de leitores de tela ainda podem encontrá-lo; mas se ele também estiver oculto da árvore de acessibilidade, pode não haver saída. Confirme que todos os mecanismos de fechamento são operáveis por teclado, mesmo que visualmente estilizados para serem discretos.
• Construir componentes personalizados de preenchimento automático ou digitação antecipada que abrem uma lista de sugestões e então direcionam todas as teclas Tab para circular pelas sugestões em vez de sair — usuários devem poder pressionar Escape para fechar a lista de sugestões e depois Tab para ir para o próximo campo do formulário. Widgets de preenchimento automático que redirecionam Tab para navegação interna violam este critério.
• Esquecer de testar editores de rich text (editores WYSIWYG como TinyMCE, CKEditor ou Quill) — esses componentes gerenciam sua própria interação de teclado internamente e são uma fonte frequente de armadilhas de teclado. Sempre confirme que pressionar Escape ou uma sequência de teclas documentada sai do editor e retorna o foco à ordem normal de tabulação da página.
• Presumir que, porque um componente usa elementos HTML nativos, ele não pode ser uma armadilha de teclado — um elemento <select> dentro de um formulário que usa JavaScript para sobrescrever seu evento blur ainda pode prender o foco. O uso de HTML semântico não garante comportamento livre de armadilhas de teclado quando tratamento de eventos JavaScript personalizado é adicionado por cima.
• Não fornecer documentação na tela quando uma tecla não padrão é necessária para sair de um componente — a WCAG 2.1.2 permite explicitamente componentes que exigem teclas não padrão para sair, desde que o usuário seja informado. Se seu widget exigir pressionar F6 ou uma combinação de teclas personalizada para sair, você deve comunicar isso claramente ao usuário, idealmente por meio de instruções visíveis adjacentes ao componente ou um anúncio em região ao vivo ARIA quando o foco entra.

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 requisitos obrigatórios de acessibilidade digital para uma ampla gama de entidades dos setores público e privado que operam na Turquia. A circular exige conformidade com padrões de acessibilidade na web reconhecidos internacionalmente — alinhando-se com WCAG 2.1 Nível AA como base, o que abrange todos os critérios de Nível A, incluindo WCAG 2.1.2 Sem Armadilha de Teclado.

WCAG 2.1.2 é um critério de Nível A, que representa o nível mínimo de conformidade. Sob a circular, a conformidade de Nível A é obrigatória para todas as entidades abrangidas. Instituições públicas são obrigadas a alcançar essa conformidade dentro de um ano da publicação da circular, enquanto entidades do setor privado têm dois anos para se adequar.

As entidades abrangidas pela circular são amplas e incluem instituições públicas e órgãos governamentais em todos os níveis, plataformas de e-commerce e operadores de marketplaces online, bancos e instituições de serviços financeiros, hospitais e prestadores de serviços de saúde, empresas 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). Isso significa que a falha em tratar armadilhas de teclado em um site ou aplicação web operado por qualquer uma dessas entidades constitui uma violação direta dos regulamentos obrigatórios de acessibilidade da Turquia.

Dada a prevalência de falhas de armadilha de teclado em aplicações web complexas — particularmente em portais de banco online, sistemas de agendamento de consultas hospitalares, fluxos de checkout de e-commerce e páginas de gerenciamento de contas de telecom — a WCAG 2.1.2 merece atenção especial no contexto de conformidade turco. Esses são exatamente os tipos de interfaces intensivas em interação, impulsionadas por JavaScript, mais propensas a conter widgets personalizados, diálogos modais e embeds de terceiros que podem, inadvertidamente, prender usuários de teclado.

Organizações sujeitas à circular devem tratar o teste de armadilhas de teclado como uma parte inegociável de seu processo de auditoria de acessibilidade. Como ferramentas automatizadas não conseguem detectar armadilhas de teclado de forma confiável, entidades abrangidas devem investir em testes manuais de teclado conduzidos por especialistas qualificados em acessibilidade, idealmente incluindo pessoas com deficiência, como parte de seu caminho para a conformidade. A falha em corrigir armadilhas de teclado identificadas durante a auditoria representa não apenas um risco legal sob a circular, mas também uma barreira significativa de acesso para usuários com deficiências motoras e visuais que dependem da navegação por teclado para usar serviços digitais.