WCAG 2.5.6: Mecanismos de Entrada Concorrentes

O que Esta Regra Significa

\n

WCAG 2.5.6 — Mecanismos de Entrada Concorrentes é um critério de sucesso de Nível AAA na WCAG 2.2. Seu requisito central é direto: o conteúdo da web não deve restringir nem interferir na capacidade do usuário de usar múltiplos mecanismos de entrada simultaneamente ou de forma intercambiável. Em termos práticos, isso significa que uma página da web ou aplicação não pode detectar programaticamente qual dispositivo de entrada o usuário está utilizando no momento e, em seguida, prendê-lo a essa única modalidade, negando acesso a outros métodos de entrada disponíveis.

\n

Dispositivos modernos oferecem uma grande variedade de mecanismos de entrada: teclados físicos, mouses e trackpads, telas sensíveis ao toque, canetas (stylus), controles por switch, entrada por voz, rastreamento ocular e mais. Muitos usuários dependem de mais de um desses ao mesmo tempo — por exemplo, uma pessoa usando um laptop com tela sensível ao toque pode alternar de forma fluida entre o touchpad e a interface de toque com o dedo. Um usuário avançado pode navegar por um formulário com o teclado enquanto usa o mouse para rolar a página. Uma pessoa com deficiência motora pode usar uma combinação de ponteiro de cabeça e um dispositivo de switch. O critério protege todos esses fluxos de trabalho.

\n

Uma falha ocorre quando um site usa JavaScript para detectar o tipo de entrada que está sendo usado e então remove ou desabilita funcionalidades para outros tipos de entrada. Por exemplo, se um site detecta um evento de toque e, em seguida, remove indicadores de foco do teclado ou desabilita a navegação por teclado, isso é uma violação direta. Da mesma forma, bloquear a entrada por ponteiro após detectar o uso do teclado, ou usar APIs de plataforma para restringir artificialmente a entrada a uma única modalidade, tudo isso constitui falhas.

\n

Uma conformidade ocorre quando os usuários podem interagir com qualquer e todos os mecanismos de entrada disponíveis a qualquer momento durante sua interação. O conteúdo deve responder corretamente a qualquer mecanismo de entrada que o usuário escolha empregar em determinado momento, sem exigir recarregamento da página, mudança de modo ou qualquer ação adicional do usuário para reativar um tipo de entrada.

\n

O critério contém uma exceção oficial definida na WCAG: a restrição é permitida quando for essencial — ou seja, quando uma modalidade específica de entrada é intrinsecamente necessária. Um exemplo clássico é um aplicativo de reconhecimento de escrita manual em que a entrada por toque ou stylus é justamente o objetivo da funcionalidade. Outro exemplo pode ser um campo de captura de assinatura digital que exige uma entrada específica por ponteiro. Mesmo nesses casos, a exceção deve ser interpretada de forma restrita e o autor deve fornecer meios alternativos de concluir a tarefa sempre que possível.

\n

É importante observar que este critério não exige que autores adicionem suporte a mecanismos de entrada que o dispositivo não possui. Ele regula as restrições impostas a mecanismos que o dispositivo e a plataforma já suportam. Se um dispositivo não tem tela sensível ao toque, não há nada a restringir.

\n\n

Por Que Isso Importa

\n

A liberdade de usar mecanismos de entrada concorrentes ou intercambiáveis não é um recurso de conveniência — é um requisito crítico de acessibilidade que afeta diretamente vários grupos distintos de usuários.

\n

Usuários com deficiências motoras frequentemente dependem de tecnologia assistiva que combina múltiplos mecanismos de entrada. Uma pessoa com mobilidade limitada nas mãos pode usar um dispositivo de switch de sopro e sucção junto com um teclado virtual na tela. Alguém com tremor pode começar a navegar por uma página com o teclado, mas alternar para o mouse ou interface de toque quando um atalho de teclado falha. Se um site detecta um tipo de entrada e desabilita outros, esses usuários podem ficar completamente impedidos de acessar o conteúdo ou a funcionalidade.

\n

Usuários com deficiências cognitivas ou de aprendizagem frequentemente se beneficiam da capacidade de escolher o método de entrada que parece mais confortável ou natural para uma determinada tarefa. Forçar uma única modalidade remove essa escolha e pode introduzir carga cognitiva desnecessária, especialmente quando o usuário não é proficiente com o método de entrada primário do dispositivo.

\n

Pessoas idosas, que podem ter desafios motores relacionados à idade, estão usando cada vez mais dispositivos que suportam tanto entrada por toque quanto por teclado. A capacidade de alternar entre esses mecanismos à medida que o controle motor fino oscila ao longo do dia é importante para o uso independente e contínuo da web.

\n

Usuários avançados e usuários de dispositivos multimodais — como usuários de Surface Pro ou iPad Pro — usam regularmente teclado, stylus e interface de toque no mesmo dispositivo e na mesma sessão. Um site que detecta entrada por toque e remove atalhos de teclado, ou vice-versa, degrada a experiência de uma enorme base de usuários que pode nem se identificar como tendo uma deficiência.

\n

Considere este cenário do mundo real: o portal online de um banco turco detecta que um cliente está usando um tablet com tela sensível ao toque e alterna para um "modo móvel" que desabilita a navegação por teclado. Um cliente com deficiência motora que usa o tablet com um teclado Bluetooth agora não consegue percorrer campos de formulário com a tecla Tab, navegar em menus com as setas ou usar atalhos de teclado. Essa pessoa não consegue concluir suas tarefas bancárias de forma independente. Isso não é apenas uma falha de acessibilidade, mas também uma potencial exposição legal sob as regulamentações de acessibilidade turcas.

\n

Do ponto de vista de usabilidade e SEO, respeitar mecanismos de entrada concorrentes se correlaciona com melhores pontuações de Core Web Vitals, menores taxas de rejeição e maior satisfação do usuário em diversas categorias de dispositivos — todos sinais que os mecanismos de busca recompensam.

\n\n

Regras Relacionadas do Axe-core

\n

WCAG 2.5.6 exige testes manuais — não há regra automatizada do axe-core que possa detectar de forma confiável todas as violações deste critério. A razão é fundamental: ferramentas automatizadas podem inspecionar o DOM e o CSS estáticos e podem detectar certos padrões de JavaScript, mas não conseguem observar completamente o comportamento em tempo de execução de listeners de eventos à medida que respondem a diferentes modalidades de entrada durante uma sessão real de usuário. A decisão de restringir um mecanismo de entrada costuma estar codificada na lógica da aplicação que só é executada em resposta a eventos específicos, tornando a análise estática insuficiente.

\n

\n
• Não existe regra automatizada dedicada do axe-core para 2.5.6. O axe-core não inclui uma regra que verifique especificamente restrições de mecanismos de entrada concorrentes, porque a violação se manifesta como comportamento dinâmico de JavaScript, e não como um problema estrutural de HTML ou ARIA. Uma página pode passar em todas as verificações automatizadas do axe e ainda violar a 2.5.6 se seus manipuladores de eventos removerem ou desabilitarem programaticamente modalidades de entrada em tempo de execução.
\n
• Eventos de ponteiro e detecção de eventos de toque: Embora o axe-core não consiga detectar a própria restrição, auditores manuais devem procurar JavaScript que escute eventos touchstart ou pointerdown e então modifique o DOM, remova o gerenciamento de foco ou defina flags que alterem o comportamento do teclado. Da mesma forma, listeners de keydown que disparam mudanças de classes CSS que escondem alvos de toque são sinais de alerta a serem inspecionados manualmente.
\n
• Por que a automação é insuficiente: Scanners automatizados analisam o documento em um ponto no tempo. Restrições de mecanismos de entrada são condicionais — elas são ativadas apenas depois que um evento de entrada específico é disparado. Um scanner executado antes da interação do usuário não consegue ver que um handler de touchstart posteriormente chamará document.querySelectorAll('[tabindex]').forEach(el => el.setAttribute('tabindex', '-1')) e efetivamente destruirá a navegação por teclado. Somente um testador humano que exerça ambas as modalidades de entrada em sequência pode descobrir essa falha.
\n

\n\n

Como Testar

\n

\n
1. Varredura automatizada de base: Execute o axe DevTools ou o Lighthouse na página para estabelecer uma linha de base e capturar quaisquer problemas concomitantes. Embora nenhuma das ferramentas tenha uma regra dedicada para 2.5.6, as verificações de boas práticas do axe DevTools podem sinalizar armadilhas de teclado ou problemas de gerenciamento de foco que são sintomáticos de restrição de entrada. Anote quaisquer falhas para correção junto com as verificações manuais abaixo.
\n
2. Inspecione o código-fonte JavaScript e os listeners de eventos: Abra o Chrome DevTools, vá para o painel Elements e use o painel Event Listeners para inspecionar se listeners touchstart, pointerdown, pointermove ou MSPointerDown estão anexados ao document ou ao body. No Console, pesquise no código-fonte JavaScript da página por padrões como ontouchstart in window, navigator.maxTouchPoints ou 'pointer' in navigator combinados com modificações do DOM. Essas são técnicas comuns usadas para detectar modalidade de entrada e controlar o acesso à funcionalidade.
\n
3. Teste de interação multimodal (teclado + toque): Em um dispositivo que suporte tanto entrada por toque quanto por teclado (por exemplo, um Surface, um iPad com teclado ou um laptop com tela sensível ao toque), comece navegando pela página exclusivamente com o teclado (Tab, Shift+Tab, Enter, Espaço, teclas de seta). Observe quais elementos interativos são alcançáveis e funcionais. Em seguida, sem recarregar a página, mude para navegação por toque — toque em links, botões e controles de formulário. Verifique se toda a funcionalidade disponível via teclado permanece acessível via toque e vice-versa. Documente qualquer elemento que se torne inalcançável ou não funcional após a alternância.
\n
4. Teste de entrada combinada com leitor de tela: Usando NVDA com Firefox, navegue pela página com o teclado para ativar o modo de leitor de tela. Em seguida, use a tela sensível ao toque (se disponível) para tentar interagir com os mesmos elementos. Confirme se o leitor de tela e a página respondem corretamente a ambas as entradas. Repita com o VoiceOver no Safari em um iPad, usando tanto os gestos de toque quanto um teclado Bluetooth emparelhado. Com o JAWS no Chrome, verifique se alternar entre teclado e mouse não quebra o gerenciamento de foco nem torna elementos interativos inoperantes.
\n
5. Revisão de código em busca de padrões de bloqueio de modalidade: Revise manualmente quaisquer bibliotecas ou frameworks JavaScript usados na página em busca de detecção de modalidade embutida. Algumas bibliotecas de UI, especialmente frameworks móveis mais antigos, incluem código que desabilita eventos de mouse ou teclado em dispositivos nos quais o toque é detectado. Verifique a documentação e o código-fonte da biblioteca em busca desse tipo de comportamento e confirme se ele foi sobrescrito ou desativado.
\n
6. Re-testar após interações dinâmicas: Execute ações que disparem mudanças significativas no DOM — abrir modais, navegar por rotas de aplicações de página única, enviar formulários — e repita o teste de multimodalidade após cada transição. Às vezes, as restrições são introduzidas apenas em estados específicos da aplicação.
\n

\n\n

Como Corrigir

\n

Detectar toque para desabilitar navegação por teclado — Incorreto

\n

<!-- JavaScript detecta toque e remove todos os valores de tabindex,\n     quebrando a navegação por teclado para usuários que alternam modos de entrada -->\n<script>\n  window.addEventListener('touchstart', function() {\n    document.querySelectorAll('a, button, input, [tabindex]').forEach(function(el) {\n      el.setAttribute('tabindex', '-1');\n    });\n  }, { once: true });\n</script>

\n

Detectar toque para desabilitar navegação por teclado — Correto

\n

<!-- Não restrinja a acessibilidade por teclado com base na detecção de toque.\n     Permita que ambas as modalidades de entrada funcionem simultaneamente.\n     Se você precisar gerenciar estilos de foco por estética, use a\n     pseudo-classe CSS :focus-visible em vez de remover tabindex. -->\n<style>\n  /* Mostre anéis de foco apenas para navegação por teclado, não para cliques de mouse,\n     sem remover completamente o acesso por teclado */\n  :focus:not(:focus-visible) {\n    outline: none;\n  }\n  :focus-visible {\n    outline: 3px solid #005fcc;\n    outline-offset: 2px;\n  }\n</style>\n<!-- Nenhuma detecção de modalidade em JavaScript é necessária -->

\n\n

Evento de ponteiro usado para suprimir eventos de teclado — Incorreto

\n

<!-- Um controle deslizante personalizado que, ao receber entrada por ponteiro,\n     para de responder às teclas de seta do teclado, prendendo o usuário\n     em uma interação apenas por ponteiro -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var pointerUsed = false;\n  slider.addEventListener('pointerdown', function() {\n    pointerUsed = true;\n  });\n  slider.addEventListener('keydown', function(e) {\n    if (pointerUsed) return; // teclado desabilitado após interação por ponteiro\n    if (e.key === 'ArrowRight') { /* incrementa */ }\n    if (e.key === 'ArrowLeft') { /* decrementa */ }\n  });\n</script>

\n

Evento de ponteiro usado para suprimir eventos de teclado — Correto

\n

<!-- Tanto interações por ponteiro quanto por teclado são tratadas de forma independente.\n     Nenhuma flag é definida que impeça uma modalidade de funcionar após\n     a outra ter sido usada. -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var value = 50;\n\n  function updateSlider(newValue) {\n    value = Math.max(0, Math.min(100, newValue));\n    slider.setAttribute('aria-valuenow', value);\n  }\n\n  // Manipulador de ponteiro — sempre ativo\n  slider.addEventListener('pointermove', function(e) {\n    if (e.buttons === 1) {\n      // calcula novo valor a partir da posição do ponteiro\n    }\n  });\n\n  // Manipulador de teclado — sempre ativo, não é desabilitado pelo uso do ponteiro\n  slider.addEventListener('keydown', function(e) {\n    if (e.key === 'ArrowRight') updateSlider(value + 1);\n    if (e.key === 'ArrowLeft') updateSlider(value - 1);\n  });\n</script>

\n\n

Framework móvel desabilitando automaticamente eventos de mouse — Incorreto

\n\n

(Content truncated due to token limit — please retry this article.)