WCAG 2.4.5: Múltiplas Formas

O que Esta Regra Significa

WCAG 2.4.5 — Múltiplas Formas é um critério de sucesso de Nível AA sob o princípio Operável. Ele exige que qualquer página da web que faça parte de um conjunto maior de páginas da web possa ser alcançada por pelo menos dois mecanismos de navegação distintos. Em outras palavras, uma pessoa usuária nunca deve ser obrigada a depender de uma única rota para encontrar uma página.

Mecanismos de navegação comuns que satisfazem esse critério incluem: uma função de busca em todo o site, um mapa do site (seja como uma página independente ou uma estrutura embutida), um índice ou sumário, um menu de navegação ou barra lateral consistentes, trilhas de navegação (breadcrumbs) e links entre páginas relacionadas. Qualquer dois desses — ou outros mecanismos equivalentes — usados em conjunto satisfazem a exigência.

O critério se aplica especificamente a conjuntos de páginas da web. Uma página da web isolada que não pertence a um site ou aplicação maior está isenta. Além disso, páginas que são o resultado de ou uma etapa em um processo — como uma página de confirmação de checkout, uma tela de sucesso de envio de formulário ou uma etapa de assistente (wizard) — também estão explicitamente isentas. Isso porque tais páginas são inerentemente sequenciais e seria inadequado ou prejudicial permitir o acesso direto a elas fora de ordem.

Uma aprovação exige que pelo menos dois mecanismos de navegação independentes estejam presentes, funcionais e acessíveis em todo o site. Uma falha ocorre quando existe apenas um mecanismo — por exemplo, um site que fornece apenas um menu de navegação superior, sem busca, sem mapa do site e sem outro recurso de navegação. Também falha se o mecanismo secundário não funcionar ou for inacessível (por exemplo, uma caixa de busca que não retorna resultados, ou um mapa do site que está oculto de tecnologias assistivas).

Importante: este critério não exige nenhuma combinação específica de mecanismos. A flexibilidade é intencional: pessoas usuárias diferentes têm estratégias fundamentalmente diferentes para encontrar conteúdo, e o padrão reconhece essa diversidade ao exigir redundância em vez de prescrever uma solução específica.

Por Que Isso Importa

A navegação é a base de qualquer experiência na web, e barreiras à navegação afetam desproporcionalmente pessoas com deficiência. Quando existe apenas um caminho de navegação, pessoas que não conseguem usar esse caminho ficam, na prática, impedidas de acessar o conteúdo.

Para pessoas com deficiências motoras — incluindo aquelas que usam acesso por varredura (switch), dispositivos de rastreamento ocular, softwares de controle por voz ou navegação apenas por teclado — menus hierárquicos complexos podem ser exaustivos ou impossíveis de percorrer de forma eficiente. Uma busca no site permite que elas saltem diretamente para o conteúdo sem navegar por vários níveis de menus. Por outro lado, pessoas com certas deficiências cognitivas ou de memória podem achar campos de busca em aberto confusos ou difíceis de usar de forma eficaz; para elas, um mapa do site claramente estruturado ou uma árvore de categorias navegável é muito mais útil.

Para pessoas cegas que dependem de leitores de tela, um menu de navegação denso pode se tornar um obstáculo repetitivo em cada visita à página, mesmo com links de pular para o conteúdo. Um atalho de mapa do site ou de busca reduz significativamente essa carga cognitiva e física. Para pessoas com baixa visão que usam ampliação de tela, menus de navegação amplos podem ficar visíveis apenas parcialmente em níveis altos de zoom, tornando uma busca baseada em texto ou um mapa do site um recurso de fallback crítico.

Para pessoas com deficiências cognitivas, como dislexia ou transtornos de atenção, a capacidade de buscar usando termos aproximados ou parciais — em vez de precisar lembrar ou reconhecer a hierarquia exata do menu — pode ser a diferença entre encontrar conteúdo de forma independente e desistir completamente.

Um cenário concreto do mundo real: imagine uma pessoa com artrite reumatoide visitando uma plataforma de e-commerce turca usando apenas navegação por teclado. O mega-menu do site exige interações precisas de foco do mouse para revelar subcategorias, e o comportamento de foco pelo teclado é pouco confiável. Se o site também oferece uma barra de busca e um mapa do site, essa pessoa ainda consegue localizar a página de produto de que precisa. Sem essas alternativas, o site é praticamente inutilizável para ela — o que representa uma cliente perdida e um potencial passivo jurídico.

Além da acessibilidade, múltiplos mecanismos de navegação oferecem benefícios mensuráveis de SEO e usabilidade. Mapas do site melhoram a rastreabilidade por robôs de mecanismos de busca. A funcionalidade de busca interna aumenta o engajamento e reduz as taxas de rejeição. Trilhas de navegação (breadcrumbs) melhoram as taxas de clique em páginas de resultados de busca quando implementadas com dados estruturados. Esses benefícios significam que satisfazer o critério 2.4.5 não é apenas um exercício de conformidade — é uma prática sólida de design de sites.

Regras Relacionadas do Axe-core

WCAG 2.4.5 exige testes manuais porque nenhuma ferramenta automatizada consegue determinar de forma confiável se um site oferece variedade de navegação suficiente. Varreduras automatizadas podem verificar se elementos específicos existem e estão sintaticamente corretos, mas não podem avaliar a arquitetura de navegação em todo o site nem determinar se uma determinada combinação de mecanismos é realmente adequada. As considerações a seguir orientam a avaliação manual:

• Presença de busca no site (verificação manual): Ferramentas automatizadas não podem confirmar se um campo de busca é funcional, retorna resultados significativos ou é acessível em todo o site. Uma pessoa testadora deve verificar manualmente se existe um mecanismo de busca, se é alcançável via teclado e se produz resultados relevantes para consultas representativas.
• Presença de um mapa do site ou mecanismo de navegação alternativo (verificação manual): Ferramentas não podem determinar se existe uma página de mapa do site, se ela está vinculada a partir de todas as páginas ou se cobre de forma abrangente o conteúdo do site. Uma pessoa revisora deve confirmar que pelo menos um mecanismo adicional além da navegação principal está disponível e acessível.
• Consistência da navegação (relaciona-se a 2.4.3 e 3.2.3, verificação manual): Ferramentas automatizadas podem sinalizar ordenações inconsistentes de componentes entre páginas, mas não podem julgar se a estratégia geral de navegação permanece coerente e suficiente para pessoas com deficiência. É necessária revisão manual em vários tipos de páginas representativas.
• Acessibilidade dos mecanismos secundários (verificação manual): Mesmo que exista um mapa do site ou busca, uma varredura automatizada pode não detectar casos em que esses mecanismos são inacessíveis pelo teclado, têm rotulagem deficiente para leitores de tela ou estão visualmente ocultos de forma que afete a usabilidade. Testes manuais com teclado e leitor de tela devem confirmar que cada mecanismo funciona de ponta a ponta.

Como Testar

1. Varredura automatizada — estabelecer uma linha de base: Execute o axe DevTools ou o Lighthouse em páginas representativas do site. Embora nenhuma das ferramentas sinalize diretamente violações de 2.4.5, use a auditoria para identificar quaisquer componentes de navegação (menus, campos de busca, breadcrumbs) com problemas de acessibilidade subjacentes, como rótulos ausentes, papéis ARIA incorretos ou problemas de gerenciamento de foco. Corrija esses problemas primeiro, pois um mecanismo de navegação quebrado não pode contar como um “caminho” válido sob 2.4.5.
2. Catalogar mecanismos de navegação: Revise manualmente o site e liste todos os mecanismos distintos que uma pessoa usuária poderia usar para chegar a uma determinada página: menus de navegação superiores, links no rodapé, busca no site, páginas de mapa do site, breadcrumbs, links de conteúdo relacionado, índices de categorias e assim por diante. Confirme que pelo menos dois desses mecanismos estão presentes, funcionais e disponíveis em todas as páginas que não fazem parte de um processo sequencial.
3. Teste de navegação apenas por teclado: Usando apenas as teclas Tab, Enter, setas e Escape (sem mouse), tente chegar a uma página específica que não seja a página inicial por meio de dois mecanismos diferentes. Por exemplo, use a barra de busca para encontrar uma página de produto e, em seguida, use o mapa do site ou o menu de navegação para chegar à mesma página. Confirme que ambos os caminhos são totalmente operáveis sem mouse.
4. Teste com leitor de tela usando NVDA + Firefox: Abra o NVDA, inicie o Firefox e navegue até a página inicial. Use o modo de navegação do NVDA (F6 para marcos, H para títulos) para localizar o marco de busca e quaisquer links de mapa do site ou navegação. Confirme que ambos os mecanismos são anunciados corretamente, que campos de formulário têm rótulos acessíveis e que as páginas de resultados ou de destino carregam e são legíveis.
5. Teste com leitor de tela usando VoiceOver + Safari (macOS/iOS): Ative o VoiceOver (Cmd+F5) e use o Rotor (VO+U) para inspecionar os controles de formulário e links da página. Confirme que o campo de busca está listado e rotulado e que links de navegação que levam a um mapa do site ou índice alternativo estão presentes e operáveis.
6. Teste com leitor de tela usando JAWS + Chrome: Use as teclas de navegação do JAWS (F para ir para formulários, Insert+F7 para a lista de links) para verificar se o campo de busca e quaisquer links para o mapa do site são descobríveis e utilizáveis tanto pelo teclado quanto pelo cursor virtual.
7. Verificação da isenção para processos sequenciais: Identifique quaisquer páginas que sejam etapas em um processo (checkout, formulários em múltiplas etapas, fluxos de login). Confirme que essas páginas não precisam satisfazer o requisito de múltiplas formas. Documente isso na sua auditoria de acessibilidade para evitar falsos negativos.
8. Verificação funcional dos resultados de busca: Realize várias buscas representativas (nomes de produtos, títulos de artigos, tópicos de suporte). Confirme que os resultados aparecem, são relevantes e que a página de resultados é acessível e navegável por teclado e leitor de tela.

Como Corrigir

Busca no site ausente — Incorreto

<!-- Site only has a navigation menu; no search or sitemap provided -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>
<!-- No search, no sitemap link, no other navigation mechanism -->

Busca no site ausente — Correto

<!-- Navigation menu retained, and a site search is added as a second mechanism -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>

<!-- Second navigation mechanism: accessible site search -->
<form role='search' action='/arama' method='get'>
  <label for='site-search'>Sitede Ara</label>
  <input
    type='search'
    id='site-search'
    name='q'
    placeholder='Ürün veya konu arayın...'
    aria-label='Site genelinde arama'
  />
  <button type='submit'>Ara</button>
</form>

Mapa do site inacessível — Incorreto

<!-- Sitemap link is present but visually hidden and unreachable by keyboard -->
<footer>
  <a href='/site-haritasi' style='display:none;'>Site Haritası</a>
</footer>
<!-- display:none removes the element from both visual display AND
     the accessibility tree, so screen reader users cannot reach it.
     This sitemap cannot count as a valid second navigation mechanism. -->

Mapa do site inacessível — Correto

<!-- Sitemap link is visible and accessible to all users -->
<footer>
  <nav aria-label='Footer navigation'>
    <ul>
      <li><a href='/site-haritasi'>Site Haritası</a></li>
      <li><a href='/gizlilik'>Gizlilik Politikası</a></li>
      <li><a href='/iletisim'>İletişim</a></li>
    </ul>
  </nav>
</footer>
<!-- The sitemap page itself should list all major sections and pages
     of the site using <nav>, <ul>, and <a> elements. -->

Formulário de busca sem rótulo acessível — Incorreto

<!-- Search input has no label; screen readers announce only 'edit text' -->
<form action='/search'>
  <input type='text' name='q' placeholder='Search...' />
  <button type='submit'><img src='search-icon.png' /></button>
</form>

Formulário de busca sem rótulo acessível — Correto

<!-- role='search' identifies the landmark; label associates text with input;
     submit button has an accessible name via aria-label -->
<form role='search' action='/arama' method='get'>
  <label for='global-search'>Arama</label>
  <input
    type='search'
    id='global-search'
    name='q'
    autocomplete='off'
  />
  <button type='submit' aria-label='Aramayı başlat'>
    <img src='search-icon.png' alt='' aria-hidden='true' />
  </button>
</form>

Erros Comuns

• Contar um sitemap XML como mecanismo de navegação voltado para a pessoa usuária: Um sitemap XML enviado a mecanismos de busca (por exemplo, /sitemap.xml) é um arquivo legível por máquina e não pode ser usado por visitantes comuns. Somente uma página de sitemap em HTML, navegável por pessoas, conta como um segundo mecanismo de navegação válido.
• Fornecer um formulário de busca que é puramente decorativo ou está quebrado: Um campo de busca que sempre retorna resultados vazios, gera erros ao enviar ou redireciona para uma página 404 não satisfaz o critério 2.4.5. O mecanismo deve ser genuinamente funcional para que o critério seja atendido.
• Ocultar o link do mapa do site atrás de JavaScript que falha ou está desativado: Se o único link para um mapa do site estiver dentro de um modal injetado dinamicamente ou de um menu suspenso dependente de JavaScript que falha em certos ambientes, pessoas que não conseguem executar esse JavaScript (incluindo algumas configurações de tecnologia assistiva) perdem o acesso a esse mecanismo de navegação.
• Aplicar display:none ou visibility:hidden a um mecanismo de navegação em viewports móveis: Ocultar completamente uma barra de busca ou link para o mapa do site no layout móvel remove esse mecanismo para pessoas usuárias em dispositivos móveis, o que é uma falha — mesmo que o layout de desktop seja aprovado. Recolher o mecanismo atrás de um botão de alternância acessível é aceitável; removê-lo do DOM ou da árvore de acessibilidade não é.
• Tratar breadcrumbs como um segundo mecanismo independente sem qualquer suporte adicional: Breadcrumbs mostram apenas o caminho até a página atual e não são, por si só, suficientes para ajudar uma pessoa a descobrir e navegar até páginas arbitrárias em um site. Eles podem complementar outros mecanismos, mas normalmente não podem servir como um dos dois mecanismos exigidos sozinhos.
• Isentar páginas do requisito de forma incorreta: A isenção para processos sequenciais se aplica apenas a páginas que são literalmente etapas dentro de um processo (por exemplo, etapa 2 de 4 em um checkout). Páginas de categoria, páginas de detalhes de produto e posts de blog não estão isentos, mesmo que a pessoa tenha chegado até eles por meio de um funil.
• Usar um campo de busca com type='text' em vez de type='search' e omitir role='search' no formulário: Embora não seja uma violação direta de 2.4.5, isso significa que pessoas usuárias de leitores de tela que navegam por marcos não conseguem encontrar a região de busca. O mecanismo tecnicamente existe, mas é, na prática, mais difícil de descobrir, o que prejudica a intenção do critério.
• Fornecer dois mecanismos que são efetivamente idênticos: Um menu de navegação superior e um menu de navegação no rodapé contendo exatamente os mesmos links na mesma estrutura não constituem dois mecanismos de navegação significativamente diferentes. A intenção é que pessoas com necessidades diferentes possam encontrar estratégias alternativas — não que a mesma estratégia apareça duas vezes na página.
• Excluir certos tipos de página do sistema de navegação: Algumas configurações de CMS colocam posts de blog, páginas jurídicas ou páginas de conta de usuário fora do mapa principal do site ou do índice de busca. Se as pessoas não conseguem encontrar essas páginas por pelo menos dois mecanismos, essas páginas falham em 2.4.5, independentemente de quão bem o restante do site esteja estruturado.
• Deixar de testar os mecanismos com tecnologia assistiva: Como 2.4.5 exige testes manuais, equipes que dependem apenas de ferramentas automatizadas deixarão de perceber falhas causadas por armadilhas de teclado em formulários de busca, campos sem rótulo ou mapas do site que estão presentes no DOM, mas são inalcançáveis por navegação de marcos em leitores de tela.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial nº 2025/10 da Turquia, publicada no Diário Oficial (Resmî Gazete) nº 32933 em 21 de junho de 2025, estabelece obrigações vinculantes de acessibilidade na web para uma ampla gama de entidades dos setores público e privado. A Circular exige conformidade com padrões de acessibilidade internacionalmente reconhecidos, alinhando os requisitos legais turcos com WCAG 2.1 e WCAG 2.2 Nível AA como expectativa básica.

WCAG 2.4.5 — Múltiplas Formas é um critério de Nível AA, o que significa que se enquadra diretamente no nível de conformidade exigido pela Circular. Entidades sujeitas à regulamentação devem garantir que todas as páginas da web pertencentes a um conjunto ofereçam pelo menos dois mecanismos de navegação, conforme descrito neste critério. Deixar de satisfazer esse requisito é uma não conformidade direta com o mandato regulatório.

As entidades abrangidas pela Circular Presidencial 2025/10 incluem: instituições públicas e órgãos governamentais em todos os níveis; bancos e instituições financeiras; hospitais e prestadores de serviços de saúde; plataformas de comércio eletrônico; operadoras de telecomunicações com 200,000 ou mais assinantes; agências de viagem; empresas de transporte privado; e escolas particulares que operam sob autorização do Ministério da Educação Nacional (Millî Eğitim Bakanlığı, MEB). Espera-se que cada um desses tipos de entidade mantenha navegação acessível, com múltiplos caminhos, em suas propriedades na web.

Além dos requisitos obrigatórios de conformidade, o Ministério da Família e Serviços Sociais (Aile ve Sosyal Hizmetler Bakanlığı) concede o Erişilebilirlik Logosu (Logotipo de Acessibilidade) a organizações que demonstram práticas sólidas de acessibilidade. Obter esse logotipo exige conformidade completa de Nível AA, incluindo o cumprimento de 2.4.5. Para empresas que atuam no competitivo mercado digital da Turquia — particularmente plataformas de e-commerce, bancos e prestadores de serviços de saúde — o Logotipo de Acessibilidade funciona tanto como um sinal de confiança para pessoas usuárias com deficiência quanto como evidência de boa-fé regulatória.

Na prática, sites turcos que atendem populações de usuários diversas se beneficiam significativamente da implementação de múltiplos mecanismos de navegação. A Turquia tem uma grande população de pessoas idosas usuárias de internet e pessoas em regiões com menor letramento digital, ambas beneficiadas pela redundância que 2.4.5 exige. Uma busca no site com suporte ao idioma turco (incluindo o tratamento correto de caracteres específicos do turco, como ı, İ, ş, ğ, ü, ö, ç), combinada com um mapa do site em HTML claramente estruturado, representa uma implementação acessível e em conformidade com a regulamentação que atende bem a esse público. Organizações que buscam obter ou manter o Erişilebilirlik Logosu devem tratar a conformidade com 2.4.5 não como um aprimoramento opcional, mas como um requisito fundamental de seu programa de acessibilidade.