WCAG 1.4.13: Conteúdo ao passar o cursor ou ao focar

O que Esta Regra Significa

A WCAG 1.4.13 aborda um padrão de interação comum na web: conteúdo que se torna visível quando a pessoa usuária passa o ponteiro sobre um elemento ou move o foco do teclado para ele. Isso inclui tooltips, submenus, dicas em dropdowns personalizados, popovers de seletores de data e qualquer outro overlay que apareça em resposta a eventos de hover ou foco. O critério se aplica sempre que esse conteúdo não for controlado de forma nativa pelo navegador (por exemplo, o tooltip nativo do atributo title é isento) e estabelece três requisitos centrais que devem ser atendidos simultaneamente.

Descartável (Dismissible): A pessoa usuária deve conseguir descartar o conteúdo adicional sem mover o foco do ponteiro ou o foco do teclado. O mecanismo padrão para isso é pressionar a tecla Escape. Isso evita que o overlay oculte outro conteúdo da página de uma forma que a pessoa usuária não consiga resolver — algo particularmente crítico para quem ampliou a tela e não pode simplesmente olhar para outra área.

Interagível ao passar o mouse (Hoverable): Se o conteúdo adicional apareceu porque a pessoa usuária passou o ponteiro sobre um elemento disparador, ela deve conseguir mover o ponteiro para o conteúdo recém-aparecido sem que ele desapareça. Se um tooltip some no momento em que o cursor sai do elemento disparador, as pessoas não conseguem ler conteúdo extenso, copiar texto dele ou ativar links ou controles dentro dele.

Persistente: O conteúdo adicional deve permanecer visível até que o hover ou o foco que o disparou seja removido, a pessoa usuária o descarte (por exemplo, via Escape) ou a informação deixe de ser válida. O conteúdo não deve desaparecer com um temporizador ou após um atraso arbitrário enquanto o ponteiro ou o foco ainda estiver no disparador ou no próprio overlay.

Para passar, é necessário que as três condições sejam satisfeitas. Há falha se qualquer condição estiver ausente — por exemplo, um tooltip que desaparece quando o ponteiro se move do disparador em direção ao tooltip (não interagível ao passar o mouse), ou um que se fecha automaticamente após três segundos (não persistente), ou um que não pode ser fechado sem mover o foco (não descartável). A única exceção oficial prevista pela WCAG é quando a apresentação visual do conteúdo adicional é inteiramente controlada pelo user agent — tooltips nativos do navegador produzidos apenas pelo atributo title se enquadram nessa categoria e são isentos, embora tenham suas próprias limitações de acessibilidade.

Por Que Isso Importa

Esse critério beneficia principalmente pessoas que têm dificuldade em controlar interações padrão de mouse ou teclado, pessoas que dependem de ampliação de tela e pessoas que processam informações mais lentamente. Entender quem é afetado ajuda as equipes a priorizar a correção de forma adequada.

Pessoas com baixa visão frequentemente usam softwares de ampliação de tela como ZoomText ou o ampliador embutido no sistema operacional, o que significa que veem apenas uma pequena parte da tela em níveis altos de zoom. Quando um tooltip aparece, ele pode estar parcialmente fora da tela, e a pessoa precisa “arrastar” a visualização até ele. Se o tooltip desaparecer no momento em que o ponteiro sai do disparador, a pessoa não consegue se deslocar para lê-lo. Segundo a Organização Mundial da Saúde, aproximadamente 2,2 bilhões de pessoas no mundo vivem com algum tipo de deficiência visual, e uma parte significativa das que usam computador depende de ampliação em vez de leitor de tela.

Pessoas com deficiências motoras — incluindo pessoas com doença de Parkinson, tremores ou controle motor fino limitado — podem usar dispositivos apontadores alternativos, ponteiros de cabeça ou sistemas de rastreamento ocular. O controle preciso do ponteiro é difícil para essas pessoas, o que significa que mover-se de um elemento disparador pequeno para um tooltip pequeno sem acidentalmente sair de ambos pode ser quase impossível se a área de hover não for tolerante. O requisito de ser interagível ao passar o mouse aborda diretamente esse ponto.

Pessoas com deficiências cognitivas podem ler devagar ou precisar reler o conteúdo. Um tooltip que se fecha automaticamente após alguns segundos não dá tempo suficiente para que essas pessoas absorvam a informação, e um tooltip que não pode ser descartado sem mover o foco pode prender a atenção em um estado de interação confuso.

Considere um cenário concreto: um site de banco exibe detalhes da taxa de juros da conta dentro de um tooltip que aparece quando a pessoa usuária passa o mouse sobre um pequeno ícone de informação. Uma pessoa com baixa visão, com zoom em 400%, vê apenas parte da página de cada vez. Ela passa o mouse sobre o ícone, o tooltip aparece, e ela começa a mover o ponteiro em direção ao tooltip para ler as letras miúdas — mas o tooltip some imediatamente porque está vinculado apenas ao estado de hover do elemento pai. A pessoa não consegue acessar as informações obrigatórias de divulgação. Isso não é apenas um inconveniente de usabilidade; em setores regulados pode constituir uma barreira legal de acessibilidade.

Além do impacto específico para pessoas com deficiência, a implementação correta desse critério também melhora a usabilidade geral para todas as pessoas em dispositivos híbridos de toque e teclado, reduz solicitações de suporte causadas por elementos de interface que “somem” e sinaliza qualidade de interface para pessoas usuárias e auditoras.

Regras Relacionadas do Axe-core

A WCAG 1.4.13 exige testes manuais. Ferramentas automatizadas não conseguem detectar violações de forma confiável porque o critério envolve comportamentos baseados em tempo e movimento do ponteiro que uma análise estática do DOM não consegue avaliar. Nenhuma regra isolada do axe-core mapeia diretamente para esse critério, mas as considerações a seguir explicam por que a automação é insuficiente e o que observar durante a revisão manual.

• Teste manual obrigatório — comportamento de hover: Scanners automatizados inspecionam o DOM e o CSSOM em um ponto no tempo; eles não conseguem simular o movimento de um ponteiro de um elemento disparador em direção a um tooltip recém-renderizado e observar se o tooltip persiste. Uma ferramenta poderia teoricamente detectar que uma pseudo-classe CSS :hover oculta um elemento filho quando o pai perde o hover, mas não consegue distinguir entre descarte intencional e falha no requisito de ser interagível ao passar o mouse sem simular trajetórias do ponteiro.
• Teste manual obrigatório — descarte via Escape: Detectar se pressionar Escape fecha um overlay exige simulação de eventos JavaScript que vai além do conjunto atual de regras do axe-core. O axe pode sinalizar ausência de roles ARIA em popups ou ausência de atributos aria-expanded, mas não consegue verificar se um listener de keydown para Escape está ligado a uma função de fechar e realmente oculta o elemento.
• Teste manual obrigatório — persistência / auto-descarte: Um tooltip que se oculta via uma chamada setTimeout após três segundos parecerá totalmente válido em uma varredura estática feita dentro desse intervalo. Só uma pessoa testadora que observe o overlay ao longo do tempo — ou revise o código JavaScript — pode identificar um temporizador de auto-descarte como violação.
• Regras complementares do axe para executar junto com as verificações manuais: Embora não testem diretamente a 1.4.13, executar regras como aria-tooltip-name (garantindo que tooltips tenham nomes acessíveis), color-contrast (garantindo que o texto do tooltip seja legível) e focus-visible (garantindo que disparadores focados sejam visualmente identificáveis) pode revelar problemas relacionados que ampliam o impacto de falhas na 1.4.13.

Como Testar

1. Varredura automatizada básica: Execute o axe DevTools ou o Lighthouse na página que contém conteúdo disparado por hover/foco. Observe quaisquer problemas sinalizados com roles de tooltip, contraste ou visibilidade de foco — isso não confirma conformidade com a 1.4.13, mas estabelece uma linha de base. Registre quais elementos disparam conteúdo em overlay para que você possa focar neles nas etapas manuais.
2. Identifique todo conteúdo disparado por hover/foco: Role pela página e passe sistematicamente o mouse sobre cada elemento interativo — botões de ícone, links com descrições extras, dicas em campos de formulário, itens de navegação, cabeçalhos de tabelas de dados e pontos de dados em gráficos. Liste cada elemento que faz conteúdo adicional aparecer.
3. Teste o requisito de ser interagível ao passar o mouse: Para cada disparador identificado, passe o mouse sobre ele para revelar o overlay e, em seguida, mova lentamente o ponteiro do elemento disparador para o próprio conteúdo do overlay. O overlay deve permanecer visível durante todo esse movimento. Se ele desaparecer antes que o ponteiro o alcance, o critério falha.
4. Teste o requisito de ser descartável: Enquanto um overlay estiver visível (disparado por hover ou foco de teclado), pressione a tecla Escape. O overlay deve se fechar. Se não se fechar, o critério falha. Faça esse teste com o ponteiro ainda sobre o disparador e também com o ponteiro sobre o overlay.
5. Teste o requisito de persistência: Dispare um overlay e deixe o ponteiro parado sobre o disparador ou sobre o overlay por pelo menos 10–15 segundos. O overlay deve permanecer visível durante todo esse período. Se ele desaparecer, expirar ou sumir sem ação da pessoa usuária, o critério falha.
6. Teste apenas com teclado: Navegue pela página usando apenas o teclado (Tab, Shift+Tab, etc.). Quando o foco chegar a um disparador que revela conteúdo adicional, verifique: (a) se o conteúdo aparece, (b) se pressionar Escape o fecha e (c) se o conteúdo não desaparece sozinho enquanto o foco permanece no disparador. Use NVDA com Firefox, JAWS com Chrome e VoiceOver com Safari para confirmar que leitores de tela também expõem o conteúdo corretamente.
7. Teste com ampliação de tela: Defina o zoom do navegador para 400% ou ative a ampliação em nível de sistema operacional. Repita os testes de hover. Confirme que uma pessoa que precisa “arrastar” a viewport para alcançar o tooltip consegue fazer isso sem que o tooltip desapareça.
8. Revise o código-fonte JavaScript: Procure na base de código por handlers de eventos setTimeout, mouseleave, mouseout e blur associados à lógica de ocultar overlays. Confirme que a lógica de ocultar não é disparada enquanto o ponteiro estiver sobre o overlay ou enquanto o disparador mantiver o foco, e que nenhum temporizador de auto-descarte está configurado.

Como Corrigir

Tooltip apenas com CSS que desaparece em mouseleave — Incorreto

<!-- Tooltip mostrado apenas via CSS :hover no elemento pai; desaparece assim que
     o ponteiro sai do disparador em direção ao texto do tooltip -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip'>This is the tooltip content.</span>
</span>

<!-- CSS (ilustrativo) -->
<!--
.tooltip { display: none; }
.tip-wrapper:hover .tooltip { display: block; }
-->

Tooltip apenas com CSS que desaparece em mouseleave — Correto

<!-- Correto: o tooltip também é mostrado quando o ponteiro está sobre o próprio tooltip,
     e o espaço entre o disparador e o tooltip é coberto para que o movimento do ponteiro
     não descarte o overlay acidentalmente. -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip' role='tooltip' id='tip1'>This is the tooltip content.</span>
</span>

<!-- CSS (ilustrativo) -->
<!--
.tooltip { display: none; position: absolute; }
.tip-wrapper:hover .tooltip,
.tooltip:hover { display: block; }
/* Use padding ou um pseudo-elemento transparente como ponte entre disparador e tooltip */
-->

Tooltip em JavaScript sem descarte pela tecla Escape — Incorreto

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
// Apenas mouseenter/mouseleave — sem teclado ou tratamento de Escape
document.querySelector('button').addEventListener('mouseenter', () => {
  document.getElementById('tip2').removeAttribute('hidden');
});
document.querySelector('button').addEventListener('mouseleave', () => {
  document.getElementById('tip2').setAttribute('hidden', '');
});
</script>

Tooltip em JavaScript sem descarte pela tecla Escape — Correto

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
const btn = document.querySelector('button');
const tip = document.getElementById('tip2');

function showTip() { tip.removeAttribute('hidden'); }
function hideTip() { tip.setAttribute('hidden', ''); }

// Mostrar em hover e foco
btn.addEventListener('mouseenter', showTip);
btn.addEventListener('focus', showTip);

// Ocultar apenas quando o ponteiro sair DO DISPARADOR E DO TOOLTIP
btn.addEventListener('mouseleave', (e) => {
  // Pequeno atraso permite que o ponteiro alcance o tooltip
  setTimeout(() => {
    if (!tip.matches(':hover') && !btn.matches(':hover')) hideTip();
  }, 100);
});
tip.addEventListener('mouseleave', () => {
  if (!btn.matches(':hover')) hideTip();
});

// Ocultar em blur (teclado)
btn.addEventListener('blur', hideTip);

// Descartável via tecla Escape — exigido pela 1.4.13
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape' && !tip.hidden) hideTip();
});
</script>

Tooltip com auto-descarte usando setTimeout — Incorreto

<button id='info-btn'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
document.getElementById('info-btn').addEventListener('mouseenter', () => {
  const t = document.getElementById('tip3');
  t.removeAttribute('hidden');
  // Violação: auto-descarta após 3 segundos, independentemente do estado da pessoa usuária
  setTimeout(() => t.setAttribute('hidden', ''), 3000);
});
</script>

Tooltip com auto-descarte usando setTimeout — Correto

<button id='info-btn' aria-describedby='tip3'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
const btn2 = document.getElementById('info-btn');
const tip3 = document.getElementById('tip3');

// Sem setTimeout — o tooltip persiste até a pessoa remover o hover/foco ou pressionar Escape
function show() { tip3.removeAttribute('hidden'); }
function hide() {
  setTimeout(() => {
    if (!tip3.matches(':hover') && !btn2.matches(':hover') && document.activeElement !== btn2) {
      tip3.setAttribute('hidden', '');
    }
  }, 100);
}

btn2.addEventListener('mouseenter', show);
btn2.addEventListener('focus', show);
btn2.addEventListener('mouseleave', hide);
btn2.addEventListener('blur', hide);
tip3.addEventListener('mouseleave', hide);
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') tip3.setAttribute('hidden', '');
});
</script>

Erros Comuns

• Usar apenas CSS :hover sem cobrir o espaço entre o disparador e o tooltip: Quando há até mesmo um espaço de 1–2 px entre o elemento disparador e o contêiner do tooltip, mover o ponteiro entre eles faz o estado de hover cair, ocultando o tooltip antes que a pessoa usuária o alcance. Use um pseudo-elemento transparente ou padding sobreposto para cobrir esse espaço.
• Vincular a lógica de ocultar ao mouseleave do disparador sem verificar se o ponteiro se moveu para o tooltip: O tooltip desaparece no instante em que o cursor sai do disparador, mesmo que o destino seja o próprio tooltip. Sempre verifique tip.matches(':hover') antes de ocultar, ou use um pequeno atraso (debounce).
• Esquecer de ligar eventos de focus e blur junto com mouseenter e mouseleave: Pessoas que usam apenas teclado e navegam com Tab até o disparador nunca verão o tooltip se apenas eventos de mouse forem tratados, tornando a informação associada completamente inacessível sem mouse.
• Não adicionar um listener para a tecla Escape, presumindo que clicar fora é suficiente: Pessoas que usam apenas teclado e pessoas que usam ampliação de tela não conseguem “clicar fora” de um overlay com facilidade. Escape é o mecanismo esperado e exigido de descarte para esse critério.
• Colocar o listener de Escape apenas no elemento disparador em vez de no document: Se a pessoa mover o foco para o tooltip ou para outro elemento, um listener limitado ao disparador não será acionado. O handler de Escape deve estar no document ou em um ancestral compartilhado que sempre receba eventos de teclado quando o overlay estiver aberto.
• Usar setTimeout para fechar tooltips automaticamente após uma duração fixa: Qualquer descarte baseado em temporizador que ocorra enquanto o ponteiro ainda estiver sobre o disparador ou o tooltip, ou enquanto o disparador ainda tiver foco de teclado, é uma violação direta do requisito de persistência. Remova todos os temporizadores de auto-descarte de overlays disparados por hover/foco.
• Disparar a visibilidade do tooltip exclusivamente por meio de substituição do atributo title com estilização personalizada: Desenvolvedores que removem o tooltip nativo de title e o substituem por uma versão personalizada devem implementar por conta própria todos os três requisitos da 1.4.13. A isenção para tooltips nativos do navegador não se estende a reproduções personalizadas em JavaScript do mesmo padrão.
• Não testar com ampliação de tela em zoom de 400%: Um tooltip que parece acessível em zoom normal pode estar parcialmente fora da tela em níveis altos de zoom, exigindo que a pessoa “arraste” a visualização — e, se ele se fechar antes que ela consiga alcançá-lo, o teste que passou em 100% de zoom falha em condições reais de uso.
• Aplicar pointer-events: none ao contêiner do tooltip: Essa propriedade CSS impede que o ponteiro seja considerado “sobre” o tooltip, tornando impossível satisfazer o requisito de ser interagível ao passar o mouse, independentemente de qualquer outra lógica. Tooltips com os quais as pessoas possam precisar interagir ou simplesmente manter o hover para que permaneçam visíveis nunca devem ter pointer-events: none.
• Tratar apenas o ARIA role='tooltip' como suficiente para conformidade: Adicionar role='tooltip' e aria-describedby é importante para acessibilidade com leitores de tela, mas aborda outra camada do problema. Esses atributos ARIA não tornam automaticamente o conteúdo descartável, interagível ao passar o mouse ou persistente — o comportamento de interação ainda precisa ser implementado explicitamente.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial de número 32933 em 21 de junho de 2025, estabelece um mandato formal de acessibilidade que incorpora os padrões WCAG por referência. A circular exige que as entidades abrangidas implementem medidas de acessibilidade na web alinhadas com diretrizes reconhecidas internacionalmente, e a conformidade em Nível AA — que inclui a WCAG 1.4.13 — é fortemente incentivada e exigida para entidades que buscam o Selo de Acessibilidade (Erişilebilirlik Logosu) emitido pelo Ministério da Família e Serviços Sociais (Aile ve Sosyal Hizmetler Bakanlığı).

A circular abrange uma ampla gama de tipos de entidades que operam na Turquia. Instituições públicas e órgãos governamentais em todos os níveis administrativos são obrigados a tornar seus serviços digitais acessíveis. No setor privado, a obrigação se estende a plataformas de e-commerce, bancos e prestadores de serviços financeiros, hospitais e instituições privadas de saúde, operadoras de telecomunicações com 200.000 ou mais assinantes, agências de viagem, empresas privadas de transporte e escolas privadas que operam sob autorização do Ministério da Educação Nacional (Millî Eğitim Bakanlığı).

A WCAG 1.4.13 é particularmente relevante em contextos digitais turcos em que padrões de tooltip e popover são amplamente usados em portais de governo eletrônico (como integrações com o e-Devlet), interfaces bancárias e de fintech que exibem informações de tarifas ou taxas em tooltips e sistemas de agendamento de saúde que apresentam instruções adicionais por meio de overlays disparados por hover. Uma plataforma bancária que falhe na 1.4.13 pode impedir que clientes com baixa visão leiam divulgações de juros fornecidas via tooltip — um cenário que traz implicações tanto de acessibilidade quanto de proteção financeira da pessoa consumidora.

Para entidades que buscam o Erişilebilirlik Logosu, uma auditoria de acessibilidade incluirá testes manuais de comportamentos de hover e foco justamente porque ferramentas automatizadas não conseguem detectar essas violações. Organizações que usam um SDK de overlay de acessibilidade como o Accsible devem garantir que quaisquer tooltips injetados por widgets, popovers de tours guiados ou painéis de ajuda contextual introduzidos pelo próprio SDK cumpram integralmente os três requisitos da 1.4.13 — descartáveis via Escape, interagíveis ao passar o mouse sem descarte e persistentes até ação da pessoa usuária. Deixar de fazer isso introduziria novas barreiras por meio da própria ferramenta destinada a melhorar a acessibilidade, minando tanto a conformidade regulatória quanto a confiança das pessoas usuárias.