WCAG 2.4.11: Foco Não Obstruído (Mínimo)

O Que Esta Regra Significa

WCAG 2.4.11 Focus Not Obscured (Minimum) é um critério de Nível AA introduzido no WCAG 2.2 que aborda um problema de acessibilidade comum, porém grave: quando um elemento em foco fica completamente escondido atrás de outra camada de conteúdo na página. O critério estabelece que, quando qualquer componente da interface do usuário recebe foco por teclado, esse componente não pode ficar totalmente oculto por conteúdo criado pelo autor.

A palavra-chave aqui é totalmente. WCAG 2.4.11 define o patamar mínimo — exige apenas que alguma parte do elemento em foco permaneça visível. Se uma barra de navegação fixa sobrepõe a metade superior de um botão em foco, mas a metade inferior ainda está visível, isso tecnicamente atende ao 2.4.11. O critério complementar mais rigoroso, WCAG 2.4.12 Focus Not Obscured (Enhanced) no Nível AAA, vai além ao exigir que o componente em foco não seja obscurecido por conteúdo criado pelo autor de forma alguma — nem mesmo parcialmente.

Os tipos de conteúdo criado pelo autor mais comumente responsáveis por esse problema incluem cabeçalhos e rodapés fixos ou “sticky”, banners de consentimento de cookies, widgets de suporte por chat, notificações “toast”, sobreposições modais, botões de ação flutuantes e barras de navegação inferiores em layouts responsivos para dispositivos móveis. Esses elementos são renderizados usando propriedades CSS como position: fixed, position: sticky ou valores altos de z-index, o que faz com que flutuem acima do fluxo normal do documento e potencialmente cubram elementos interativos que recebem foco.

Um pass significa que, quando uma pessoa usuária de teclado percorre os elementos interativos com a tecla Tab, pelo menos parte do indicador visual de cada elemento em foco está visível na tela o tempo todo — mesmo que um elemento de UI “sticky” sobreponha parte dele. Um fail ocorre quando um elemento em foco fica completamente escondido sob uma camada criada pelo autor, o que significa que a pessoa usuária não tem qualquer pista visual sobre onde o foco está no momento. Conteúdo renderizado pelo navegador, como a própria barra de ferramentas do navegador, não conta como conteúdo criado pelo autor e, portanto, está excluído do escopo deste critério. Da mesma forma, conteúdo que a própria pessoa usuária reposicionou (como um painel arrastável pelo usuário) também é excluído.

Este critério se aplica a todos os elementos HTML interativos que são focáveis por teclado por padrão ou tornados focáveis via tabindex, incluindo <a>, <button>, <input>, <select>, <textarea> e elementos com tabindex='0' ou valores positivos de tabindex.

Por Que Isso Importa

A navegação por teclado é fundamental para a acessibilidade de vários grupos de pessoas usuárias. Pessoas com deficiências motoras que não podem usar mouse dependem totalmente de teclados, dispositivos de varredura ou controladores de sopro e sucção para se mover por uma página web. Pessoas cegas usam leitores de tela em combinação com teclados. Pessoas com baixa visão que usam navegação por teclado sem leitor de tela dependem fortemente do indicador de foco visível para entender onde estão. Quando esse elemento em foco fica escondido atrás de um cabeçalho “sticky” ou de um widget flutuante, essas pessoas ficam efetivamente perdidas — precisam pressionar Tab repetidamente, adivinhar sua posição ou abandonar completamente a tarefa.

Considere um cenário concreto do mundo real: uma pessoa usuária de cadeira de rodas com mobilidade limitada nas mãos está preenchendo um formulário de reserva de voo no site de uma companhia aérea turca. Ela usa a tecla Tab para percorrer os campos do formulário. A página tem um banner de consentimento de cookies “sticky” na parte inferior da área visível. Quando a pessoa avança com Tab até a caixa de seleção final de confirmação, essa caixa é renderizada completamente sob o banner de cookies. A pessoa não tem qualquer indicação visual de que a caixa de seleção está em foco. Ela não consegue saber se o pressionamento da tecla Tab funcionou, se precisa pressionar Tab novamente ou se a caixa de seleção é sequer obrigatória. Essa confusão pode levar ao abandono do formulário, a envios perdidos ou a pressionamentos repetidos de teclas que causam ações indesejadas.

O impacto vai além das pessoas com deficiência. Usuárias e usuários avançados que preferem navegação por teclado pela rapidez — desenvolvedores, profissionais de digitação de dados e pessoas altamente proficientes — também se beneficiam de uma visibilidade clara do foco. De acordo com a Organização Mundial da Saúde, aproximadamente 1,3 bilhão de pessoas no mundo vivem com algum tipo de deficiência, e uma parte significativa delas depende de tecnologias assistivas ou da navegação por teclado. Na Turquia especificamente, o Instituto de Estatística Turco (TÜİK) informa que cerca de 12,7% da população tem algum tipo de deficiência, o que se traduz em aproximadamente 10 milhões de pessoas que podem se beneficiar diretamente de uma melhor gestão de foco em plataformas digitais.

Do ponto de vista de negócios, indicadores de foco obscurecidos aumentam as taxas de abandono de tarefas, reduzem conversões e expõem organizações a riscos legais e regulatórios. Sites que não atendem a este critério também provavelmente falharão em auditorias de acessibilidade exigidas pela legislação turca, colocando em risco sua capacidade de obter ou manter o Erişilebilirlik Logosu (Logotipo de Acessibilidade) oficial.

Regras Relacionadas do Axe-core

WCAG 2.4.11 é classificado como exigindo testes manuais no axe-core. Não há uma regra automatizada do axe-core que detecte diretamente essa violação. Entender por que ferramentas automatizadas não conseguem sinalizar esse problema de forma confiável ajuda as equipes a construir processos melhores de teste manual.

• Teste Manual Necessário — Foco Obscurecido por Posicionamento Fixo: Ferramentas automatizadas não conseguem detectar se um elemento em foco está visualmente obscurecido porque isso exige renderizar a página, calcular os retângulos delimitadores de todos os elementos fixos ou “sticky” em tempo de execução e compará-los com o retângulo delimitador do elemento atualmente em foco no momento em que recebe foco. As dimensões da viewport, a posição de rolagem e o estado dinâmico da página (como se um banner de cookies já foi dispensado) afetam o resultado. Nenhuma análise estática ou inspeção do DOM consegue replicar de forma confiável esse cálculo visual em todos os estados possíveis. O axe-core marca esse critério como manual porque exige uma pessoa testadora — ou uma ferramenta sofisticada de regressão visual — para realmente percorrer a página com Tab e observar se componentes em foco desaparecem atrás de camadas sobrepostas.
• Teste Manual Necessário — Conteúdo de Sobreposição Dinâmica: Muitos elementos que obscurecem são injetados dinamicamente via JavaScript após o carregamento inicial da página — widgets de chat de terceiros, banners de conformidade com GDPR, pop-ins promocionais e menus de navegação flutuantes. Varredores automatizados que analisam o snapshot inicial do DOM podem não capturar esses elementos, ou podem capturá-los em um estado recolhido ou oculto que não reflete a experiência real da pessoa usuária. Testes manuais por uma pessoa usuária de teclado que interage com a página em seu estado totalmente renderizado e dinâmico são a única forma confiável de detectar esses cenários.

Como Testar

1. Execute primeiro uma varredura automatizada de acessibilidade. Use axe DevTools (extensão de navegador), Lighthouse no Chrome DevTools ou uma varredura axe-core integrada ao CI para identificar quaisquer problemas detectáveis automaticamente na página. Embora o 2.4.11 em si exija verificação manual, uma varredura automatizada pode revelar problemas relacionados, como indicadores de foco ausentes (2.4.7) ou empilhamento de z-index incorreto que sugira elementos sobrepostos. Anote todos os elementos sinalizados como potencialmente problemáticos antes de iniciar o teste manual.
2. Identifique todos os elementos fixos e “sticky” na página. Abra o DevTools do navegador e inspecione o CSS da página. Procure elementos usando position: fixed ou position: sticky. Verifique também elementos com valores altos de z-index (por exemplo, 100 ou mais). Documente cada um desses elementos — cabeçalhos, rodapés, banners, widgets de chat, avisos de cookies — pois são os candidatos mais prováveis a obscurecer componentes em foco. Redimensione a janela do navegador para simular diferentes tamanhos de viewport, incluindo larguras de tablet e mobile, já que elementos fixos/“sticky” frequentemente se comportam de forma diferente em cada breakpoint.
3. Realize um percurso completo de tabulação por teclado. Clique fora de qualquer elemento interativo para garantir que o foco comece do topo da página e, em seguida, pressione Tab repetidamente para percorrer todos os elementos focáveis. Observe cuidadosamente cada elemento quando receber foco. Preste atenção especial aos elementos que aparecem perto da parte superior ou inferior da viewport, onde cabeçalhos ou rodapés fixos têm maior probabilidade de sobrepor. Se em algum momento o anel de foco visível ou o elemento destacado desaparecer completamente atrás de uma camada fixa, isso é uma falha do 2.4.11. Use Shift+Tab para percorrer no sentido inverso também, já que a posição de rolagem e o layout podem ser diferentes.
4. Teste com NVDA e Firefox. Abra o NVDA (leitor de tela gratuito e de código aberto para Windows) e inicie o Firefox. Ative o modo de navegação do NVDA e use Tab para percorrer a página. Embora o NVDA anuncie cada elemento em foco de forma audível, observe também a tela visualmente. Anote qualquer elemento em que o NVDA anuncie o foco, mas nenhum indicador visual de foco seja visível devido a conteúdo que o obscurece. Essa combinação é amplamente usada na Turquia e globalmente e representa um emparelhamento fundamental de tecnologia assistiva.
5. Teste com VoiceOver e Safari no macOS/iOS. Ative o VoiceOver (Command+F5 no Mac) e use Tab ou os gestos de navegação do VoiceOver para percorrer os elementos focáveis. No iOS, use gestos de deslizar. Verifique se os elementos em foco estão visualmente presentes e não escondidos sob camadas de UI fixas, especialmente em dispositivos móveis, onde barras de navegação e banners de cookies podem ocupar uma proporção maior da viewport.
6. Teste com JAWS e Chrome. Abra o JAWS (Job Access With Speech) e use o Chrome. Percorra todos os elementos interativos com Tab e monitore qualquer momento em que o cursor do JAWS se mova para um elemento que esteja visualmente escondido sob uma camada fixa. O JAWS é amplamente usado em ambientes corporativos e governamentais, tornando essa combinação particularmente importante para testar sites do setor público e corporativos.
7. Teste após interações do usuário que alteram o layout. Feche banners de cookies, abra e feche menus de navegação, dispare notificações “toast” e abra widgets de chat. Após cada mudança de estado, realize uma nova tabulação com Tab para garantir que o novo layout não introduza novos casos de foco obscurecido. Conteúdo dinâmico é uma fonte comum de falhas do 2.4.11 que só aparecem após a interação da pessoa usuária.
8. Teste em múltiplas posições de rolagem. Role até o meio ou o final de uma página longa e, em seguida, percorra com Tab os elementos nessa região. Cabeçalhos fixos podem não obscurecer elementos perto do topo da página, mas podem cobrir elementos que aparecem na borda superior da viewport à medida que a pessoa usuária rola para baixo. Confirme que nenhuma combinação de posição de rolagem e elemento em foco resulta em ocultação visual completa.

Como Corrigir

Cabeçalho “Sticky” Sobrepondo Links em Foco — Incorreto

<!-- Sticky header with no scroll offset accommodation -->
<header style='position: fixed; top: 0; left: 0; width: 100%; height: 60px; z-index: 1000; background: white;'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- No scroll-margin-top set; focused link at top of main scrolls under the header -->
  <a href='/section-one'>Go to Section One</a>
  <a href='/section-two'>Go to Section Two</a>
</main>

Cabeçalho “Sticky” Sobrepondo Links em Foco — Correto

<!-- Fixed header with scroll-margin-top applied to all focusable elements -->
<header class='site-header'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top ensures the browser scrolls the element into view
       with enough clearance so the fixed header does not cover it -->
  <a href='/section-one' class='content-link'>Go to Section One</a>
  <a href='/section-two' class='content-link'>Go to Section Two</a>
</main>

<!-- In your stylesheet: -->
<!-- .site-header { position: fixed; top: 0; height: 60px; z-index: 1000; } -->
<!-- * { scroll-margin-top: 70px; } -->
<!-- The 70px (header height + 10px buffer) keeps focused elements
     visible below the fixed header when the browser auto-scrolls. -->

Banner de Cookies Cobrindo Campo de Formulário em Foco na Parte Inferior — Incorreto

<!-- Cookie banner fixed at bottom with no accommodation for form fields above it -->
<div id='cookie-banner' class='cookie-overlay'>
  <p>We use cookies. <button>Accept</button></p>
</div>

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <!-- This checkbox renders in the viewport area covered by the cookie banner -->
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Banner de Cookies Cobrindo Campo de Formulário em Foco na Parte Inferior — Correto

<!-- Cookie banner pushes page content up instead of overlapping it -->
<div id='cookie-banner' class='cookie-banner-flow'>
  <p>We use cookies. <button id='accept-cookies'>Accept</button></p>
</div>

<!-- In your stylesheet: -->
<!-- .cookie-banner-flow { position: static; } instead of position: fixed -->
<!-- Alternatively, if fixed positioning is required for design reasons,
     add scroll-margin-bottom to all focusable elements equal to the
     banner height, or apply padding-bottom to <body> equal to
     the banner height so content is never hidden beneath it. -->

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Widget de Chat de Terceiros Sobrepondo Botão em Foco — Incorreto

<!-- Third-party chat widget injected in bottom-right corner
     with a high z-index, obscuring the focused Submit button -->
<div id='chat-widget' class='chat-fixed'>
  <!-- Injected by third-party script, covers 120x120px in bottom-right -->
</div>

<section class='cta-section'>
  <!-- Button positioned in the bottom-right area of the layout;
       when focused, it is completely hidden beneath the chat widget -->
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

Widget de Chat de Terceiros Sobrepondo Botão em Foco — Correto

<!-- Approach 1: Reposition the chat widget to avoid overlapping focusable content -->
<div id='chat-widget' class='chat-fixed-adjusted'>
  <!-- Widget repositioned to bottom-left, away from the CTA button -->
</div>

<!-- Approach 2: Ensure the button has scroll-margin that keeps it
     clear of the widget when focused -->
<section class='cta-section'>
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

<!-- Approach 3: Use JavaScript to detect focus events on elements
     near the widget's bounding box and temporarily collapse or
     move the widget so the focused element is visible. -->
<script>
  // Example: collapse widget when nearby element gains focus
  document.querySelectorAll('.cta-button').forEach(function(btn) {
    btn.addEventListener('focus', function() {
      var widget = document.getElementById('chat-widget');
      if (widget) widget.setAttribute('aria-hidden', 'false');
      // Additional logic to reposition or minimize widget
    });
  });
</script>

Erros Comuns

• Aplicar position: fixed a cabeçalhos e rodapés sem adicionar scroll-margin-top ou scroll-margin-bottom a elementos focáveis. A rolagem nativa de foco do navegador não leva em conta elementos fixos sobrepostos, então itens em foco rolam até o topo ou a base da viewport e acabam escondidos atrás da camada fixa. Uma regra CSS global como * { scroll-margin-top: [header-height]px; } resolve isso de forma eficiente.
• Definir body { padding-top: 60px; } para compensar um cabeçalho fixo, mas esquecer de adicionar scroll-margin-top equivalente para o foco de teclado. O padding garante que o conteúdo não fique inicialmente oculto, mas quando o foco de teclado aciona a rolagem automática do navegador, o alvo da rolagem ainda pode escorregar para trás do cabeçalho. Ambas as abordagens devem ser usadas em conjunto.
• Usar z-index: 9999 em banners promocionais ou widgets de chat sem auditar quais elementos focáveis ficam dentro de sua área. Um z-index alto garante que a sobreposição seja renderizada acima de tudo, incluindo botões e links em foco, tornando-se a causa raiz mais comum de falhas do 2.4.11.
• Dispensar banners de cookies via JavaScript sem removê-los imediatamente do layout. Se o elemento DOM do banner permanecer com visibility: hidden ou opacity: 0, mas ainda ocupar espaço ou tiver um z-index diferente de zero, ele pode continuar a obscurecer visualmente elementos em foco em certos cenários de renderização do navegador.
• Incorporar widgets de terceiros (chat ao vivo, sobreposições de acessibilidade, gerenciadores de GDPR) sem verificar seu impacto na visibilidade do foco de teclado. Scripts de terceiros frequentemente injetam elementos com posição fixa e valores de z-index muito altos. As equipes devem testar essas integrações explicitamente como parte do processo de QA de acessibilidade.
• Deixar de testar o 2.4.11 após mudanças de breakpoint responsivo. Uma barra de navegação “sticky” com 60px de altura no desktop pode se expandir para 120px no tablet quando um menu hambúrguer é aberto, de repente obscurecendo uma área muito maior e criando novas falhas em breakpoints que passavam no desktop.
• Aplicar scroll-margin-top apenas a alvos de âncora (<h2>, <section>) mas não a elementos interativos como <input>, <button> e <a>. O deslocamento de rolagem de âncora é comumente tratado, mas a rolagem automática de foco de teclado para elementos que não são âncoras é igualmente afetada e deve ser coberta pela mesma regra CSS.
• Presumir que, porque um elemento em foco é anunciado por um leitor de tela, ele também está visível visualmente. Leitores de tela acessam a árvore de acessibilidade, não a renderização visual. Um elemento pode estar completamente escondido atrás de uma sobreposição fixa e ainda ser anunciado corretamente pelo NVDA ou JAWS. São dois problemas distintos — o 2.4.11 trata especificamente da visibilidade do foco visual para pessoas usuárias videntes de teclado.
• Negligenciar testar obscurecimento de foco após mudanças de rota em aplicações de página única (SPA). Em apps React, Vue ou Angular, transições de rota frequentemente re-renderizam cabeçalhos fixos com estado atualizado, e a gestão de foco durante a navegação pode colocar o foco em elementos que são imediatamente obscurecidos por um cabeçalho “sticky” remontado antes que a pessoa usuária veja a nova página.
• Confiar apenas em ferramentas de teste automatizado e concluir que não existem problemas de 2.4.11 porque nenhuma regra automatizada sinalizou a página. Como o axe-core não tem uma regra automatizada para esse critério, um relatório automatizado limpo não significa que a página passa. A tabulação manual por teclado em todos os tamanhos de viewport e estados de página é obrigatória.

Relação com os Regulamentos de Acessibilidade da Turquia

WCAG 2.4.11 Focus Not Obscured (Minimum) é diretamente relevante para o emergente arcabouço legal 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 alinhados ao WCAG 2.2. Essa circular representa uma expansão significativa do compromisso da Turquia com a inclusão digital e impõe obrigações executáveis a uma ampla gama de entidades que operam no mercado digital turco.

A circular abrange um escopo amplo de organizações, incluindo instituições públicas e órgãos governamentais, plataformas de e-commerce, bancos e prestadores de serviços financeiros, hospitais e organizações de saúde, empresas de telecomunicações com mais de 200.000 assinantes, agências de viagem, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE). Todas essas entidades devem garantir que suas interfaces digitais — sites, aplicativos móveis e ferramentas baseadas na web — estejam em conformidade com o Nível AA do WCAG 2.2.

Como o WCAG 2.4.11 é um critério de Nível AA no WCAG 2.2, a conformidade com essa regra não é opcional para as entidades abrangidas. Organizações que buscam obter ou manter o Erişilebilirlik Logosu (Logotipo de Acessibilidade) oficial, emitido pelo Ministério da Família e Serviços Sociais (Aile ve Sosyal Hizmetler Bakanlığı), devem atender à conformidade de Nível AA. O Logotipo de Acessibilidade serve como um sinal público de compromisso com a inclusão digital e é cada vez mais esperado por consumidores turcos e órgãos de compras governamentais.

Na prática, isso significa que sites de instituições públicas turcas com cabeçalhos de navegação “sticky”, sites de e-commerce com banners promocionais persistentes, portais bancários com widgets de ajuda flutuantes e sistemas de agendamento de saúde com sobreposições de consentimento de cookies devem ser todos testados e corrigidos quanto ao obscurecimento de foco sob o 2.4.11. Falhas nesse critério são particularmente prováveis em interfaces complexas e carregadas de marketing — exatamente o tipo de site operado pelas grandes entidades comerciais abrangidas pela circular.

Organizações que operam sob a circular devem incorporar testes do 2.4.11 em seus ciclos regulares de auditoria de acessibilidade. Dado que esse critério exige testes manuais, confiar apenas em varreduras automatizadas não satisfará as obrigações de diligência. Entidades turcas que buscam conformidade plena são aconselhadas a realizar testes manuais de tabulação por teclado em todos os tamanhos de viewport e estados dinâmicos de página como parte de sua documentação de conformidade, e a tratar quaisquer problemas de obscurecimento de foco identificados como parte de seu roadmap de correção antes da solicitação ou renovação do logotipo de acessibilidade.