WCAG 2.4.3: Ordem de Foco

O Que Esta Regra Significa

WCAG 2.4.3 Ordem de Foco é um critério de sucesso de Nível A sob o princípio Operável. Ele afirma: "Se uma página da Web puder ser navegada sequencialmente e as sequências de navegação afetarem o significado ou a operação, os componentes focalizáveis recebem foco em uma ordem que preserva o significado e a operabilidade."

Em termos práticos, isso significa que, quando uma pessoa usuária pressiona a tecla Tab para percorrer elementos interativos em uma página — links, botões, campos de formulário, widgets personalizados e qualquer outro componente focalizável — a sequência em que esses elementos recebem foco deve fazer sentido lógico. As pessoas usuárias não devem se ver pulando inesperadamente do meio de um formulário para um link no rodapé, depois de volta para um botão em um modal e, em seguida, para um item do menu de navegação.

O critério se aplica à navegação sequencial por teclado, que é a principal forma de pessoas que usam apenas teclado e pessoas que usam leitores de tela percorrerem uma página. A ordem do DOM é a fonte padrão da ordem de foco nos navegadores: os elementos aparecem na sequência de tabulação na ordem em que aparecem no Document Object Model (DOM), a menos que CSS ou JavaScript alterem deliberadamente essa ordem. Problemas surgem quando o layout visual diverge da ordem do DOM (por exemplo, por meio de reordenação com CSS Flexbox ou Grid) ou quando valores de tabindex impõem uma sequência artificial.

O que conta como aprovação: A ordem de foco deve ser lógica e significativa — não necessariamente idêntica à ordem visual de leitura, mas coerente o suficiente para que as pessoas usuárias possam entender e operar a página. Um diálogo modal que move o foco para si quando é aberto, mantém o foco preso dentro de si enquanto está aberto e devolve o foco ao elemento acionador quando é fechado atende a esse critério. Um formulário em várias etapas em que o Tab avança por cada campo na ordem em que uma pessoa usuária os preencheria (de cima para baixo, da esquerda para a direita em idiomas escritos da esquerda para a direita) também atende.

O que conta como reprovação: O foco saltar do campo "Nome de usuário" de um formulário de login para um banner promocional completamente não relacionado antes de chegar ao campo "Senha" reprova. Uma aplicação de página única que abre um diálogo, mas deixa o foco na página de fundo reprova. Usar valores inteiros positivos de tabindex (por exemplo, tabindex='2', tabindex='5') que forçam uma sequência de tabulação ilógica na página reprova.

Exceções oficiais: As WCAG observam explicitamente que a ordem de foco não precisa corresponder à ordem visual de leitura, desde que preserve o significado e a operabilidade. Também há uma permissão para casos em que as sequências de navegação não afetam o significado ou a operação — por exemplo, uma página com apenas um elemento focalizável não tem sequência a ser avaliada. Além disso, quando há várias ordenações válidas que preservam o significado, qualquer uma dessas ordenações é aceitável.

Mecanismos-chave de HTML e JavaScript que afetam a ordem de foco incluem: a ordem natural do DOM dos elementos interativos, o atributo tabindex (particularmente valores inteiros positivos), propriedades CSS que reordenam o layout visual sem alterar o DOM (como order em Flexbox/Grid, position: absolute e float), gerenciamento de foco acionado por JavaScript (chamando .focus() em elementos) e padrões de diálogo ARIA que exigem gerenciamento explícito de foco.

Por Que Isso Importa

A ordem de foco não é um detalhe técnico menor — é a espinha dorsal de navegação da web para uma parcela significativa de pessoas usuárias. Vários grupos distintos de pessoas com deficiência dependem de uma sequência lógica de foco para usar produtos digitais de forma eficaz.

Pessoas com deficiência motora que não podem usar um mouse dependem inteiramente do teclado (ou dispositivos equivalentes ao teclado, como dispositivos de sopro e sucção, ponteiros de cabeça ou sistemas de rastreamento ocular) para navegar. Para essas pessoas, uma ordem de foco embaralhada não é apenas inconveniente — pode tornar uma página completamente inutilizável. Se a tecla Tab levar uma pessoa usuária para a parte errada da página, ela pode não ter uma forma eficiente de alcançar o controle de que precisa, e não pode simplesmente mover a mão para clicar em outro lugar.

Pessoas cegas e pessoas com baixa visão que usam leitores de tela como NVDA, JAWS ou VoiceOver ouvem os elementos sendo anunciados à medida que o foco chega neles. Uma ordem de foco lógica significa que o fluxo de áudio que recebem reflete o fluxo pretendido da interface. Quando o foco salta de forma errática, as pessoas usuárias perdem seu modelo mental de onde estão na página. De acordo com a Organização Mundial da Saúde, aproximadamente 2,2 bilhões de pessoas no mundo têm algum tipo de deficiência visual e, para muitas das que usam leitores de tela, a ordem de foco é sua principal forma de experimentar a estrutura da página.

Pessoas com deficiências cognitivas também se beneficiam de sequências de foco previsíveis. Um salto de foco inesperado no meio de um formulário pode causar confusão, forçar as pessoas usuárias a reiniciar fluxos de trabalho ou levá-las a perder campos obrigatórios. Pessoas com dificuldades de atenção ou desafios de memória de curto prazo precisam de navegação consistente e previsível para ganhar confiança no uso de um site.

Um cenário concreto do mundo real: Imagine uma página de checkout de comércio eletrônico turca. O design visual usa CSS Grid para colocar o resumo do pedido à esquerda e o formulário de pagamento à direita. No entanto, no DOM, o formulário de pagamento vem primeiro e o resumo do pedido vem em segundo. O layout visual parece correto para pessoas videntes que usam mouse, mas uma pessoa usuária de teclado que pressiona Tab cairá nos campos do formulário de pagamento antes de ter a chance de revisar o resumo do pedido. Ela pode, sem saber, confirmar um pedido errado. Pior ainda, se um botão "Confirmar compra" receber foco antes de um campo "Aplicar cupom" devido a má gestão de tabindex positivo, uma pessoa usuária pode enviar uma compra que pretendia descontar. Este é um impacto financeiro direto e real de uma ordem de foco quebrada.

Além da acessibilidade, uma ordem de foco lógica melhora a experiência para usuárias e usuários avançados que preferem navegação por teclado pela rapidez. Ela também apoia indiretamente o SEO: um DOM bem estruturado que produz uma ordem de foco natural tende a refletir marcação semântica significativa, que os mecanismos de busca usam para entender a hierarquia e a importância do conteúdo.

Regras Relacionadas do Axe-core

WCAG 2.4.3 exige testes manuais para uma avaliação definitiva. Ferramentas automatizadas como axe-core não podem determinar algoritmicamente se uma determinada sequência de foco "preserva o significado e a operabilidade" — esse julgamento exige uma pessoa que entenda o propósito da página e as relações de conteúdo. No entanto, axe-core e ferramentas relacionadas podem sinalizar certos padrões que são fortes indicadores de problemas de ordem de foco:

• tabindex (valores positivos) — sinal heurístico: Algumas ferramentas de lint e auditoria emitem avisos quando elementos possuem valores inteiros positivos de tabindex (qualquer valor maior que 0). Valores positivos de tabindex substituem a ordem natural do DOM e colocam esses elementos no início da sequência de tabulação, o que quase sempre cria uma ordem de foco ilógica e imprevisível. Embora o conjunto de regras principal do axe-core não inclua uma regra automatizada dedicada de "ordem de foco" (porque a correção lógica da sequência não pode ser computada), ferramentas como axe DevTools Pro e auditorias manuais verificam especificamente o uso de tabindex positivo como indicador indireto.
• scrollable-region-focusable: O axe-core inclui uma regra que sinaliza regiões roláveis que não são focalizáveis pelo teclado. Embora não seja diretamente uma regra de ordem de foco, uma região rolável que não pode receber foco quebra a sequência de navegação geral, fazendo com que pessoas que usam teclado pulem conteúdo com o qual precisam interagir.
• Inspeção manual para conteúdo reordenado por CSS: Ferramentas automatizadas não conseguem detectar quando o order do CSS Flexbox ou o posicionamento em Grid criam uma incompatibilidade entre a ordem visual e a ordem do DOM. Uma pessoa testadora precisa comparar visualmente o layout na tela com a sequência de foco observada durante a navegação por teclado. Esta é a fonte mais comum de falhas em 2.4.3 em designs responsivos modernos e é totalmente invisível para scanners automatizados.
• Inspeção manual para gerenciamento de foco em JavaScript em conteúdo dinâmico: Aplicações de página única, implementações de rolagem infinita, modais e menus expansíveis exigem JavaScript para mover o foco adequadamente à medida que o conteúdo muda. Ferramentas automatizadas executam um instantâneo estático do DOM e não podem simular a sequência de interações de usuário necessárias para acionar esses cenários de gerenciamento de foco. Apenas testes manuais com teclado podem verificar se o foco se move para um modal recém-aberto, retorna ao acionador correto ao fechar e não deixa a pessoa usuária presa em uma camada de fundo inacessível.

Como Testar

1. Varredura automatizada como ponto de partida: Execute o axe DevTools (extensão de navegador) ou o Google Lighthouse na página. Procure quaisquer avisos sobre valores positivos de tabindex e regiões roláveis sinalizadas. Observe que um resultado automatizado limpo não significa que 2.4.3 foi atendido — testes manuais são sempre necessários. Registre quaisquer problemas sinalizados para investigação posterior.
2. Desconecte o mouse e navegue apenas com Tab: Começando pela barra de endereços do navegador ou pelo topo da página, pressione Tab repetidamente para percorrer todos os elementos focalizáveis. Observe a sequência com atenção. Pergunte a si mesmo: o foco se move em uma ordem que corresponde ao fluxo lógico de leitura e interação da página? O foco alguma vez salta para uma área inesperada? Alguma vez fica preso (incapaz de avançar ou retroceder) exceto dentro de um diálogo intencional?
3. Teste componentes dinâmicos: Ative quaisquer modais, diálogos, menus suspensos, acordeões, painéis de abas, seletores de data ou outros widgets interativos usando o teclado. Verifique se o foco se move para o conteúdo recém-revelado imediatamente após a ativação. Depois de fechar um diálogo, confirme se o foco retorna ao elemento que acionou o diálogo — não para o topo da página ou algum local arbitrário.
4. Teste com NVDA + Firefox: Abra o NVDA, inicie o Firefox e navegue até a página. Use Tab para percorrer elementos interativos e ouça os anúncios. Verifique se a sequência anunciada faz sentido contextual. Use o Modo de Navegação do NVDA (setas) para ler o conteúdo estático e confirme se a ordem de leitura se alinha com a ordem de foco dos elementos interativos dentro desse conteúdo.
5. Teste com VoiceOver + Safari (macOS/iOS): Ative o VoiceOver e use Tab (desktop) ou gestos de deslizar (iOS) para percorrer elementos focalizáveis. Confirme se a sequência de foco é lógica. No iOS, teste se modais e sobreposições prendem o foco corretamente e o devolvem ao serem dispensados.
6. Teste com JAWS + Chrome: Use a navegação por Tab do JAWS e confirme se a sequência de foco anunciada é coerente. Use o cursor virtual do JAWS para cruzar a ordem de leitura com a ordem de foco interativo e identificar quaisquer discrepâncias.
7. Inspecione o DOM versus o layout visual: Abra as DevTools do navegador e examine a estrutura do DOM. Compare a ordem dos elementos interativos no DOM com sua posição visual na tela. Se propriedades CSS como order, position: absolute ou float estiverem criando diferenças significativas, siga manualmente a sequência de tabulação para determinar se o significado ou a operabilidade são afetados.
8. Verifique valores de tabindex no DOM: No console do navegador, execute document.querySelectorAll('[tabindex]') para listar todos os elementos com atributos tabindex explícitos. Investigue qualquer elemento com valor inteiro positivo e avalie se sua posição na sequência de tabulação modificada é lógica.

Como Corrigir

Valores positivos de tabindex criando ordem ilógica — Incorreto

<!-- Valores positivos de tabindex forçam uma sequência de tabulação artificial -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email' tabindex='3'>

  <label for='name'>Full Name</label>
  <input type='text' id='name' tabindex='1'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone' tabindex='2'>

  <button type='submit' tabindex='4'>Submit</button>
</form>
<!-- Ordem de tabulação: Full Name → Phone → Email → Submit
     Ordem visual/lógica: Email → Full Name → Phone → Submit
     Essa incompatibilidade quebra a ordem de foco. -->

Valores positivos de tabindex criando ordem ilógica — Correto

<!-- Remova todos os valores positivos de tabindex; confie na ordem do DOM.
     Reorganize o DOM para corresponder à sequência lógica. -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email'>

  <label for='name'>Full Name</label>
  <input type='text' id='name'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone'>

  <button type='submit'>Submit</button>
</form>
<!-- A ordem de tabulação agora segue a ordem do DOM: Email → Full Name → Phone → Submit
     Corresponde à ordem lógica e visual. Nenhum tabindex é necessário. -->

Reordenação visual por CSS em desacordo com a ordem do DOM — Incorreto

<!-- O DOM tem a barra lateral primeiro, o conteúdo principal em segundo.
     O CSS usa flexbox order para invertê-los visualmente.
     Pessoas que usam teclado percorrem links da barra lateral antes dos links do conteúdo principal,
     o que não corresponde ao que uma pessoa vidente vê primeiro. -->
<style>
  .layout { display: flex; }
  .sidebar { order: 2; } /* Mostrada visualmente à direita */
  .main    { order: 1; } /* Mostrada visualmente à esquerda */
</style>

<div class='layout'>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
</div>
<!-- Ordem de foco: About → Contact → Read Article
     Ordem visual: Read Article → About → Contact
     A incompatibilidade quebra 2.4.3 -->

Reordenação visual por CSS em desacordo com a ordem do DOM — Correto

<!-- Correção: reordenar o DOM para corresponder à ordem visual e lógica pretendida.
     Remover as substituições de 'order' no CSS que causaram a incompatibilidade. -->
<style>
  .layout { display: flex; }
  /* Sem substituições de 'order' — a ordem do DOM determina a ordem visual e de tabulação */
</style>

<div class='layout'>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
</div>
<!-- Ordem do DOM, ordem visual e ordem de foco agora coincidem. -->

Diálogo modal sem gerenciar foco — Incorreto

<!-- O botão abre um modal, mas o foco permanece na página de fundo.
     Pessoas que usam teclado não conseguem interagir com o diálogo. -->
<button id='open-modal' onclick='document.getElementById("dialog").style.display="block"'>
  Open Settings
</button>

<div id='dialog' style='display:none;'>
  <h2>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>
<!-- Quando o diálogo abre, o foco permanece em #open-modal no fundo.
     Tab continua nos elementos da página de fundo, não nos elementos do diálogo. -->

Diálogo modal sem gerenciar foco — Correto

<!-- O foco é movido para o diálogo ao abrir e devolvido ao acionador ao fechar.
     role='dialog' e aria-modal='true' informam aos leitores de tela o contexto. -->
<button id='open-modal'>Open Settings</button>

<div id='dialog'
     role='dialog'
     aria-modal='true'
     aria-labelledby='dialog-title'
     style='display:none;'>
  <h2 id='dialog-title'>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>

<script>
  const openBtn = document.getElementById('open-modal');
  const dialog  = document.getElementById('dialog');
  const closeBtn = document.getElementById('close-modal');

  openBtn.addEventListener('click', () => {
    dialog.style.display = 'block';
    // Move o foco para o primeiro elemento focalizável no diálogo
    document.getElementById('theme').focus();
  });

  closeBtn.addEventListener('click', () => {
    dialog.style.display = 'none';
    // Devolve o foco ao elemento que acionou o diálogo
    openBtn.focus();
  });
</script>
<!-- A ordem de foco agora é lógica: acionador → conteúdo do diálogo → de volta ao acionador. -->

Erros Comuns

• Usar valores inteiros positivos de tabindex (por exemplo, tabindex='1', tabindex='5') para "controlar" a ordem de foco em vez de corrigir a estrutura do DOM. Valores positivos de tabindex colocam elementos à frente de todos os elementos naturalmente focalizáveis na página, criando uma sequência global de tabulação caótica, extremamente difícil de manter e que quase sempre introduz erros.
• Aplicar order em Flexbox ou CSS Grid para reordenar conteúdo visualmente sem reordenar o DOM e depois deixar de testar a navegação por teclado. O layout visual parece correto para pessoas videntes, mas a sequência de tabulação segue a ordem do DOM, não a ordem visual — uma discrepância invisível, porém séria, para pessoas que usam teclado.
• Abrir um modal ou diálogo sem mover o foco para dentro dele programaticamente usando o método .focus() do JavaScript. Pessoas que usam leitores de tela e teclado permanecem presas no conteúdo de fundo, muitas vezes incapazes de encontrar ou interagir com o diálogo.
• Não devolver o foco ao elemento acionador após fechar um modal, gaveta ou menu suspenso. Devolver o foco ao topo da página ou deixá-lo em um elemento agora oculto força as pessoas usuárias a renavegar desde o início, perdendo seu lugar em uma página potencialmente longa.
• Inserir conteúdo carregado dinamicamente (por exemplo, uma mensagem de erro inline, uma notificação toast ou uma seção carregada sob demanda) no DOM após elementos focalizáveis que o precedem visualmente, de modo que pessoas que usam teclado encontrem o novo conteúdo fora de sequência ou nem o encontrem.
• Usar tabindex='-1' para remover elementos da sequência de tabulação sem fornecer um meio alternativo de acesso por teclado. Embora tabindex='-1' em si seja uma ferramenta válida (torna um elemento focalizável programaticamente, mas o remove da ordem natural de tabulação), aplicá-lo de forma incorreta a controles de que as pessoas realmente precisam efetivamente esconde esses controles de quem usa teclado.
• Criar transições de rotas em aplicações de página única que redefinem o foco para o corpo do documento ou para a interface do navegador em vez de mover o foco para o novo título da página ou para um marco de pular navegação. As pessoas usuárias são então forçadas a percorrer toda a navegação com Tab em cada mudança de rota.
• Implementar widgets personalizados de carrossel ou slider em que a navegação por setas não é implementada e Tab move o foco por cada slide oculto, forçando as pessoas usuárias a percorrer dezenas de elementos fora da tela antes de alcançar o conteúdo subsequente da página.
• Colocar um link de pular navegação "invisível" no DOM que está sempre com display:none (em vez de visualmente oculto com uma técnica .sr-only / clip). Um link com display:none é removido inteiramente da ordem de tabulação, não oferecendo benefício algum, enquanto um link de pular navegação implementado corretamente recebe foco ao pressionar Tab e se torna visível, apoiando diretamente o fluxo lógico de foco para o conteúdo principal.
• Aninhar elementos interativos dentro de outros elementos interativos (por exemplo, um <button> dentro de uma tag <a>), o que produz comportamento de tabulação inconsistente entre navegadores e pode fazer com que o foco caia no mesmo controle lógico várias vezes ou o ignore completamente.

Relação com os Regulamentos de Acessibilidade da Turquia

WCAG 2.4.3 Ordem de Foco é diretamente relevante para a legislação de acessibilidade histórica da Turquia: a Circular Presidencial 2025/10, publicada no Diário Oficial nº 32933 em 21 de junho de 2025. Essa circular estabelece padrões obrigatórios de acessibilidade na web para uma ampla gama de entidades públicas e privadas que operam na Turquia, exigindo conformidade com diretrizes reconhecidas internacionalmente — incluindo todos os critérios de sucesso de Nível A das WCAG 2.x, entre os quais está o 2.4.3.

A circular abrange um amplo conjunto de tipos de entidades. Instituições públicas — incluindo ministérios, prefeituras, universidades públicas e agências governamentais — devem alcançar conformidade total em até um ano a partir da data de publicação da circular. Entidades do setor privado em categorias cobertas devem atingir o mesmo padrão de conformidade em até dois anos. As categorias cobertas do setor privado incluem plataformas de comércio eletrônico, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde privados, 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 todas essas organizações, uma ordem de foco quebrada ou ilógica não é apenas uma deficiência de usabilidade — é uma não conformidade regulatória que pode expor a entidade a consequências legais e administrativas sob as disposições de fiscalização da circular. Considere o portal de internet banking de um banco turco em que a ordem de foco na tela de transferência de fundos salta do campo de valor para o botão de confirmação, ignorando o campo de IBAN do beneficiário. Uma pessoa usuária que utiliza apenas teclado — talvez uma cliente com deficiência motora — pode, inadvertidamente, iniciar uma transferência sem preencher corretamente todos os campos obrigatórios. Esse cenário representa simultaneamente uma falha em WCAG 2.4.3, uma violação dos requisitos da circular e um potencial dano financeiro grave para a pessoa usuária.

Da mesma forma, um site de comércio eletrônico coberto pela circular que usa reordenação com CSS Grid para exibir uma página de produto visualmente atraente, mas cuja sequência de tabulação salta das imagens do produto para links do rodapé antes de chegar ao botão "Add to Cart", estaria em violação direta de 2.4.3 e, portanto, em não conformidade com a circular. Os prazos de um e dois anos significam que as organizações devem tratar a correção da ordem de foco como prioridade em seus roteiros de acessibilidade — não como uma melhoria adiada. Dado que problemas de ordem de foco muitas vezes decorrem de decisões arquiteturais sobre a estrutura do DOM e padrões de interação em JavaScript, abordá-los cedo no processo de desenvolvimento é substancialmente menos custoso do que corrigi-los após o lançamento.

O SDK de overlay da Accsible apoia as organizações em sua jornada rumo à conformidade, fornecendo aprimoramentos configuráveis de gerenciamento de foco, mas é importante observar que soluções de overlay funcionam melhor em conjunto — e não em substituição — a uma estrutura HTML semântica adequada e a um gerenciamento responsável de foco no próprio código da aplicação. Alcançar uma conformidade sustentável e auditável com a Circular Presidencial 2025/10 exige que o produto subjacente atenda ao 2.4.3 por meio de práticas corretas de desenvolvimento.