WCAG 2.1.4: Atalhos de Teclas de Caracteres

O Que Esta Regra Significa

WCAG 2.1.4 — Atalhos de Tecla de Caractere é um critério de sucesso de Nível A introduzido no WCAG 2.1. Ele aborda um risco de acessibilidade específico, porém sério: quando uma aplicação web atribui atalhos de teclado que consistem em um único caractere imprimível — uma letra, número, sinal de pontuação ou símbolo — sem exigir uma tecla modificadora como Ctrl, Alt, Meta ou Shift junto com ele.

O critério estabelece que, se um atalho de teclado for implementado no conteúdo usando apenas uma única tecla de caractere, pelo menos uma das seguintes condições deve ser verdadeira:

• Desativar: Um mecanismo está disponível para permitir que o usuário desative completamente o atalho.
• Remapear: Um mecanismo está disponível para permitir que o usuário remapeie o atalho para usar uma ou mais teclas modificadoras não imprimíveis (como Ctrl ou Alt).
• Ativo apenas com foco: O atalho de teclado para um componente da interface do usuário só fica ativo quando esse componente está em foco.

Um atalho de tecla de caractere único é aquele ativado ao pressionar uma única tecla que produz um caractere imprimível — por exemplo, pressionar G para abrir uma galeria, pressionar / para focar uma barra de pesquisa ou pressionar N para compor uma nova mensagem. Esses atalhos diferem fundamentalmente de atalhos como Ctrl+S ou Alt+F4, que exigem uma tecla modificadora não imprimível e, portanto, estão fora do escopo deste critério.

Um atalho atende a este critério se a aplicação: (1) fornece uma página de configurações ou preferências onde atalhos de tecla única podem ser desativados ou alterados para combinações de múltiplas teclas; (2) remapeia automaticamente para atalhos baseados em modificadores; ou (3) só dispara o atalho quando o próprio elemento acionador está com foco de teclado — o que significa que pressionar a tecla enquanto o foco está em outro lugar não faz nada.

Um atalho falha se uma tecla de caractere único dispara uma ação global a qualquer momento, independentemente de qual elemento está em foco, e não há maneira de o usuário desativá-lo ou alterá-lo. Um exemplo comum no mundo real é uma aplicação de página única que dispara uma ação de navegação sempre que o usuário pressiona uma tecla de letra, mesmo enquanto está preenchendo um campo de texto ou ditando texto.

O critério inclui uma exceção oficial importante: ele não se aplica quando o atalho só está ativo enquanto um componente específico está em foco. Por exemplo, um widget de dropdown personalizado que escuta teclas de letra apenas quando o próprio dropdown está aberto e em foco é aceitável, porque o confinamento de foco limita o risco de ativação acidental.

Por Que Isso Importa

Este critério existe principalmente para proteger dois grupos de usuários, embora seus benefícios se estendam além deles.

Usuários de entrada por voz são os mais diretamente afetados. Pessoas com deficiências motoras frequentemente controlam seus computadores inteiramente por meio de softwares de reconhecimento de voz, como Dragon NaturallySpeaking (agora Dragon Professional). Ao ditar texto ou emitir comandos de voz, essas ferramentas emitem pressionamentos de teclas que podem acidentalmente acionar atalhos de caractere único na página web ativa. Imagine um usuário ditando um formulário médico e dizendo “next” — se a aplicação escuta globalmente pela letra N, ela pode navegar para fora do formulário, destruindo o trabalho do usuário. De acordo com o CDC, aproximadamente 61 milhões de adultos nos Estados Unidos vivem com uma deficiência, e uma proporção significativa depende de métodos de entrada alternativos, incluindo reconhecimento de fala.

Usuários com deficiência motora que usam acesso por varredura, dispositivos de sopro e sucção ou navegação apenas por teclado também estão em risco. Esses usuários podem pressionar teclas inadvertidamente ou passar por várias teclas enquanto tentam alcançar um alvo. Um único pressionamento errado que aciona uma ação irreversível — como arquivar um e-mail, excluir um arquivo ou enviar um formulário — pode causar frustração significativa e perda de dados.

Usuários com deficiências cognitivas também podem ser prejudicados. Usuários com transtornos de atenção ou usuários que não estão familiarizados com uma interface podem pressionar teclas de forma experimental para explorar a página, sem saber que atalhos de caractere único estão ativos. Navegações ou mudanças de estado inesperadas aumentam a carga cognitiva e a desorientação.

Considere este cenário do mundo real: uma plataforma de e-commerce turca implementa atalhos de tecla única para usuários avançados — pressionar C para ir ao carrinho de compras, pressionar F para ir aos favoritos. Um usuário de entrada por voz tenta ditar seu endereço de entrega em um campo de formulário. Ao dizer “Caddesi” (a palavra turca para “rua”), o software de voz emite a letra C antes de o foco entrar totalmente no campo de entrada, acionando a navegação para a página do carrinho. O endereço parcialmente inserido é perdido. O usuário precisa recomeçar e, se a experiência se repetir, pode abandonar o site completamente.

Além da acessibilidade, corrigir este critério melhora a usabilidade geral. Fornecer uma interface de personalização de atalhos sinaliza um produto maduro e que respeita o usuário. Também pode reduzir chamados de suporte de usuários frustrados que acionam atalhos acidentalmente.

Regras Relacionadas do Axe-core

WCAG 2.1.4 exige testes manuais porque ferramentas automatizadas não conseguem detectar de forma confiável todos os atalhos de teclado de caractere único ou verificar se existe um mecanismo de remapeamento/desativação. Eis por que a automação é insuficiente e o que os testadores devem verificar manualmente:

• Nenhuma regra dedicada do axe-core (verificação manual necessária): Axe-core e Lighthouse não têm uma regra automatizada que sinalize especificamente atalhos de teclado de caractere único. A razão é arquitetural: o comportamento de atalhos de teclado é implementado em listeners de eventos JavaScript (keydown, keyup, keypress), e a análise estática do DOM não consegue determinar que ação um determinado pressionamento de tecla irá acionar, se essa ação é global ou limitada ao foco, ou se existe um mecanismo de desativação/remapeamento voltado ao usuário. Uma ferramenta precisaria simular pressionamentos de teclas para todas as possíveis entradas de caracteres e observar as mudanças resultantes no estado da aplicação — uma tarefa combinatoriamente cara e dependente de contexto que excede as capacidades atuais de testes automatizados.
• Inspeção de listeners de eventos (automação parcial): As DevTools do navegador podem enumerar listeners de eventos anexados aos elementos document, window ou body. Se um site anexar um listener de keydown ao document e a inspeção de seu código revelar lógica de correspondência de caracteres únicos, isso é um forte indicativo que exige verificação manual. No entanto, a ferramenta não consegue determinar por conta própria se o comportamento resultante constitui um atalho ou se existe um mecanismo de desativação.
• Bibliotecas de atalhos específicas de framework: Muitas aplicações em React, Vue ou Angular usam bibliotecas como react-hotkeys-hook, tinykeys ou Mousetrap que registram atalhos globais. Uma auditoria manual deve verificar essas dependências no código-fonte da página ou na aba de rede e, em seguida, testar cada atalho registrado em relação aos requisitos do critério.

Como Testar

1. Revise a aplicação em busca de atalhos de caractere único conhecidos: Leia qualquer documentação disponível, páginas de ajuda ou diálogos de referência de atalhos de teclado (frequentemente abertos com ? ou acessíveis via um menu de Ajuda). Liste todos os atalhos documentados que usam um único caractere sem uma tecla modificadora.
2. Inspecione os listeners de eventos JavaScript: Abra o Chrome DevTools ou Firefox DevTools, navegue até o painel Elements ou Sources e use a aba Event Listeners para inspecionar listeners em document, window e body. Procure handlers de keydown, keyup ou keypress. Expanda e leia o código do handler para ver se teclas de caractere único são testadas sem verificações de modificadores (isto é, se o código verifica event.key === 'n' sem também verificar event.ctrlKey || event.metaKey || event.altKey).
3. Teste atalhos de teclado enquanto o foco está em uma entrada de texto: Clique em um campo de texto, caixa de pesquisa ou textarea. Em seguida, pressione cada atalho de caractere único que você identificou. Se o atalho for disparado (ocorrer navegação, uma ação for acionada, o estado mudar), isso é uma falha — o atalho não é limitado ao foco e está ativo mesmo quando o usuário está digitando.
4. Teste com NVDA + Firefox: Ative o modo Browse do NVDA (Insert+Space para alternar). No modo Browse, o NVDA usa teclas de navegação de uma letra (H para headings, B para buttons, etc.). Inicie a aplicação web testada. Mude para o modo Focus (Insert+Space) e dite ou digite texto. Verifique se os atalhos de caractere único da página não entram em conflito com as teclas do modo Browse do NVDA e se nenhuma ação indesejada é disparada.
5. Teste com JAWS + Chrome: Da mesma forma, o JAWS usa teclas de navegação rápida de uma letra. Inicie a aplicação, navegue via cursor virtual do JAWS e verifique se os atalhos da aplicação não são disparados inesperadamente enquanto o JAWS processa pressionamentos de teclas.
6. Teste com VoiceOver + Safari (macOS): Ative o VoiceOver (Cmd+F5). Use VO+Shift+Down para interagir com áreas de conteúdo. Verifique se atalhos de letras na página não interferem com os comandos de navegação do VoiceOver.
7. Simule entrada por voz: Se Dragon NaturallySpeaking ou Windows Speech Recognition estiver disponível, dite texto em um campo de formulário enquanto a aplicação estiver aberta. Fale palavras e frases comuns que comecem com letras usadas como atalhos. Verifique se nenhuma ação indesejada é disparada.
8. Verifique o mecanismo de desativação ou remapeamento: Se existirem atalhos de caractere único, localize a interface de configurações ou preferências que permite desativá-los ou remapeá-los. Confirme que ela é acessível apenas com teclado e funciona corretamente. Teste se, após desativar um atalho, pressionar o caractere não aciona mais a ação.

Como Corrigir

Atalho global de caractere único sem verificação de modificador — Incorreto

<!-- JavaScript anexado ao document dispara em qualquer pressionamento de 'n' globalmente -->
<script>
document.addEventListener('keydown', function(event) {
  if (event.key === 'n') {
    // Navegar para compor nova mensagem
    openComposeWindow();
  }
});
</script>

Atalho global de caractere único — Correto: adicionar requisito de modificador e um botão de desativação

<!-- Abordagem correta 1: Exigir uma tecla modificadora (Ctrl+N) para evitar disparos acidentais -->
<script>
document.addEventListener('keydown', function(event) {
  // Só dispara quando Ctrl ou Meta (Cmd no Mac) também estiver pressionado
  if ((event.ctrlKey || event.metaKey) && event.key === 'n') {
    openComposeWindow();
  }
});
</script>

<!-- Abordagem correta 2: Se o atalho de caractere único for necessário, forneça um botão de desativação -->
<button type='button' id='toggle-shortcuts' aria-pressed='true'>
  Keyboard shortcuts enabled
</button>
<script>
let shortcutsEnabled = true;
document.getElementById('toggle-shortcuts').addEventListener('click', function() {
  shortcutsEnabled = !shortcutsEnabled;
  this.setAttribute('aria-pressed', shortcutsEnabled.toString());
  this.textContent = shortcutsEnabled ? 'Keyboard shortcuts enabled' : 'Keyboard shortcuts disabled';
});

document.addEventListener('keydown', function(event) {
  if (!shortcutsEnabled) return; // Respeitar a preferência do usuário
  if (event.key === 'n') {
    openComposeWindow();
  }
});
</script>

Atalho ativo dentro de um widget focado — Incorreto

<!-- Atalho escuta o document inteiro, não é limitado ao widget -->
<div id='autocomplete-list' role='listbox'>
  <div role='option'>Istanbul</div>
  <div role='option'>Ankara</div>
</div>
<script>
// BUG: anexado ao document, dispara mesmo quando o autocomplete não está em foco
document.addEventListener('keydown', function(e) {
  if (e.key === 'Enter') selectHighlightedOption();
});
</script>

Atalho ativo dentro de um widget focado — Correto: limitar o listener ao widget

<!-- Correto: listener está no elemento do widget; atalho só dispara quando ele está em foco -->
<div id='autocomplete-list' role='listbox' tabindex='0'>
  <div role='option'>Istanbul</div>
  <div role='option'>Ankara</div>
</div>
<script>
var widget = document.getElementById('autocomplete-list');
// Listener no próprio widget: Enter só dispara quando a listbox está em foco
widget.addEventListener('keydown', function(e) {
  if (e.key === 'Enter') selectHighlightedOption();
});
</script>

Nenhuma interface de remapeamento acessível ao usuário — Incorreto

<!-- Aplicação registra atalhos com uma biblioteca, mas não oferece página de configurações -->
<!-- Usuário não tem como alterar ou desativar 'g' (ir para galeria) ou 'c' (ir para carrinho) -->
<script src='hotkeys.min.js'></script>
<script>
hotkeys('g', function() { goToGallery(); });
hotkeys('c', function() { goToCart(); });
</script>

Nenhuma interface de remapeamento acessível ao usuário — Correto: adicionar painel de configurações acessível

<!-- Painel de configurações acessível via teclado; permite ao usuário alternar todos os atalhos de caractere único -->
<nav aria-label='Accessibility settings'>
  <button type='button' id='open-shortcut-settings'>Keyboard shortcut settings</button>
</nav>

<dialog id='shortcut-settings-dialog' aria-labelledby='dialog-title'>
  <h2 id='dialog-title'>Keyboard Shortcuts</h2>
  <label>
    <input type='checkbox' id='enable-single-char' checked />
    Enable single-character keyboard shortcuts (G, C, N...)
  </label>
  <p>Disable this if you use speech recognition software or experience accidental activations.</p>
  <button type='button' id='close-dialog'>Save and close</button>
</dialog>

<script src='hotkeys.min.js'></script>
<script>
var checkbox = document.getElementById('enable-single-char');

function applyShortcuts() {
  if (checkbox.checked) {
    hotkeys('g', function() { goToGallery(); });
    hotkeys('c', function() { goToCart(); });
  } else {
    hotkeys.unbind('g');
    hotkeys.unbind('c');
  }
}

applyShortcuts();
checkbox.addEventListener('change', applyShortcuts);

document.getElementById('open-shortcut-settings').addEventListener('click', function() {
  document.getElementById('shortcut-settings-dialog').showModal();
});
document.getElementById('close-dialog').addEventListener('click', function() {
  document.getElementById('shortcut-settings-dialog').close();
});
</script>

Erros Comuns

• Registrar atalhos em document ou window sem verificar se um elemento de entrada está em foco: Mesmo que exista um mecanismo de desativação, muitas implementações esquecem de verificar document.activeElement e suprimir o atalho quando o usuário está dentro de um elemento <input>, <textarea> ou contenteditable, levando à interferência com a digitação normal.
• Tratar o atalho ? (abrir ajuda) como isento: O caractere de interrogação é um caractere imprimível e um atalho de caractere único. Ele não está isento deste critério, a menos que seja limitado ao foco ou exista um mecanismo de desativação/remapeamento.
• Desativar atalhos apenas em entradas de texto, mas não em regiões contenteditable ou editores de rich text: Usuários de entrada por voz frequentemente ditam em elementos contenteditable usados por editores de rich text (como aqueles em plataformas de CMS). Deixar de suprimir atalhos globais nesses contextos ainda viola o critério.
• Armazenar a preferência de atalhos do usuário apenas na memória de sessão: Se o usuário desativar atalhos e, em seguida, atualizar a página, a preferência deve ser persistida (em localStorage ou em uma configuração de perfil de usuário) para que ele não precise desativar atalhos a cada visita.
• Tornar a própria interface de configurações de atalhos inacessível: Colocar a opção de desativar/remapear profundamente em um menu que não pode ser alcançado por teclado, ou usar um widget de alternância personalizado sem um role='switch' adequado e aria-checked, significa que o mecanismo de correção é inutilizável justamente pelas pessoas que ele deveria ajudar.
• Presumir que apenas teclas de letras importam: Teclas numéricas (1–9), teclas de pontuação (/, ., vírgula, ponto e vírgula) e teclas de símbolo (#, @, !) são todos caracteres imprimíveis. Atalhos de tecla única usando esses caracteres também estão sujeitos ao critério.
• Não documentar quais atalhos existem: Mesmo que exista um mecanismo de desativação, os usuários não podem usá-lo de forma eficaz se não souberem quais atalhos estão ativos. Fornecer uma referência de atalhos visível e acessível por teclado (como um diálogo aberto por meio de um botão de Ajuda) é fortemente recomendado.
• Usar a configuração padrão de uma biblioteca de atalhos que faz binding global sem ler sua documentação: Bibliotecas como Mousetrap, Hotkeys.js e tinykeys fazem binding no escopo global por padrão. Desenvolvedores frequentemente as usam sem ler a documentação sobre restrição de escopo ou requisitos de modificadores, criando inadvertidamente violações do critério em larga escala.
• Não testar com reconhecimento de fala antes do lançamento: Equipes que não têm Dragon NaturallySpeaking em seu kit de QA frequentemente descobrem conflitos de atalhos de caractere único apenas após a implantação, quando usuários de entrada por voz relatam problemas.
• Acreditar que, porque o atalho é “opcional” ou “para usuários avançados”, ele está isento: O critério se aplica a todos os atalhos de caractere único, independentemente de serem divulgados como recursos avançados. A opcionalidade do recurso não o isenta do requisito de conformidade.

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 web e móvel alinhados com o WCAG 2.2. WCAG 2.1.4 — Atalhos de Tecla de Caractere é um critério de sucesso de Nível A, colocando-o na camada de obrigações de mais alta prioridade sob a circular.

A circular abrange uma ampla gama de entidades que operam na Turquia. Instituições públicas — incluindo ministérios, prefeituras, universidades públicas, hospitais públicos e agências governamentais — devem alcançar conformidade total de Nível A dentro de um ano a partir da data de publicação da circular. Entidades do setor privado em categorias cobertas recebem um prazo de conformidade de dois anos. Entidades privadas cobertas incluem plataformas de e-commerce, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagens, empresas de transporte privado e escolas privadas que operam sob autorização do Ministério da Educação Nacional (MoNE).

Para essas organizações, deixar de cumprir o WCAG 2.1.4 não é apenas uma questão de boas práticas — é uma obrigação legal. Um site de e-commerce turco que implemente atalhos de navegação de produtos com caracteres únicos sem um mecanismo de desativação, ou o portal online de um banco turco que use atalhos de teclas de letras em seu fluxo de transações, estaria em violação direta dos requisitos da circular.

Na prática, equipes de conformidade em entidades cobertas devem auditar seus codebases JavaScript e quaisquer bibliotecas de widgets de terceiros em busca de atalhos de caractere único registrados globalmente como uma tarefa específica durante seus projetos de remediação de Nível A do WCAG 2.2. Como este critério exige testes manuais, varreduras automatizadas de acessibilidade por si só não revelarão violações — é necessário um ciclo dedicado de testes com teclado e entrada por voz. Organizações que usam sistemas de gerenciamento de conteúdo ou frameworks de front-end devem revisar implementações de atalhos em nível de plataforma (por exemplo, atalhos de teclado padrão do admin do CMS expostos em páginas voltadas ao cliente) além do código de aplicação personalizado.

O SDK de overlay da Accsible auxilia entidades cobertas fornecendo um painel de preferências de acessibilidade acessível ao usuário que pode expor uma opção de desativação de atalhos para usuários finais, ajudando organizações a atender ao requisito de “mecanismo para desativar” do WCAG 2.1.4 sem exigir uma refatoração completa do codebase. Isso é particularmente valioso para organizações que gerenciam aplicações legadas em que modificar a lógica subjacente de atalhos JavaScript é intensivo em recursos. No entanto, as organizações devem observar que depender exclusivamente de um overlay para conformidade não substitui a correção das implementações de atalhos subjacentes, e uma abordagem em camadas que combine ferramentas de overlay com remediação no código-fonte oferece o caminho mais robusto para a conformidade sob a circular presidencial.