Critérios de Sucesso WCAG · Level AAA
WCAG 2.4.8: Localização
A WCAG 2.4.8 exige que os usuários possam determinar onde estão dentro de um conjunto de páginas da web — por exemplo, por meio de trilhas de navegação (breadcrumbs), mapas do site ou links de navegação destacados. Isso ajuda pessoas com deficiências cognitivas, usuários de leitores de tela e qualquer pessoa que navegue em sites complexos a se orientar e percorrer o conteúdo com confiança.
O Que Esta Regra Significa
WCAG 2.4.8 Localização é um critério de Nível AAA sob o princípio Operável. Ele afirma: "Informações sobre a localização do usuário dentro de um conjunto de páginas da Web estão disponíveis." Em termos práticos, isso significa que seu site deve fornecer sinais claros e persistentes que indiquem aos usuários exatamente onde eles estão dentro da estrutura mais ampla do site em qualquer momento.
Este critério se aplica sempre que um site consiste em múltiplas páginas organizadas em uma hierarquia ou sequência significativa — por exemplo, um site de e-commerce com categorias, subcategorias e páginas de produto, ou um portal governamental com departamentos e subseções. Se um usuário chega a uma página, ele deve ser capaz de responder à pergunta "Onde estou neste site?" sem precisar adivinhar ou depender apenas da memória.
Técnicas aceitáveis para satisfazer este critério incluem, mas não se limitam a:
- Trilhas de navegação (breadcrumbs) — um recurso de navegação que mostra o caminho da página inicial do site até a página atual (por exemplo, Home > Products > Laptops > 15-inch Models).
- Mapas do site — uma página ou painel dedicado que exibe a estrutura geral do site e destaca ou marca a localização atual.
- Links de navegação destacados ou visualmente distintos — menus de navegação que marcam claramente a seção ou página ativa, muitas vezes complementados com o atributo
aria-currentpara usuários de tecnologias assistivas. - Etapas numeradas em um processo de múltiplas etapas — indicadores como "Step 2 of 5" em um checkout ou assistente de formulário que comunicam a posição sequencial.
Uma página atende a este critério se pelo menos um mecanismo confiável estiver disponível para informar o usuário sobre sua localização atual dentro da estrutura do site. Uma página falha se nenhum mecanismo desse tipo existir — por exemplo, se a barra de navegação não tiver indicação visual ou programática da página atual, não houver trilha de navegação e nenhum indicador de etapa for exibido.
É importante observar que a WCAG 2.4.8 não exige uma técnica específica; ela requer que algum indicador de localização eficaz esteja presente. No entanto, para que o indicador seja realmente acessível, ele também deve ser perceptível por tecnologias assistivas, como leitores de tela, e não apenas visualmente aparente para usuários videntes. Isso significa que indicadores puramente visuais (como um link em negrito sem alteração no rótulo acessível) podem ser insuficientes por si só se não forem expostos programaticamente.
Não há exceções oficiais definidas pela WCAG para este critério além do entendimento geral de que ele se aplica a conjuntos de páginas relacionadas. Uma única página da web independente que não faça parte de um conjunto maior não precisaria satisfazer este critério, pois não há "localização dentro de um conjunto" a ser comunicada.
Por Que Isso Importa
Saber onde você está dentro de um ambiente digital é uma necessidade básica de orientação que a maioria dos usuários considera garantida — até que as pistas estejam ausentes. A WCAG 2.4.8 aborda uma barreira real e generalizada vivenciada por vários grupos distintos de usuários.
Usuários com deficiências cognitivas estão entre os mais significativamente afetados. Condições como transtorno de déficit de atenção, comprometimentos de memória e lesões cerebrais adquiridas podem dificultar o acompanhamento do próprio caminho em um site complexo. Sem uma trilha de navegação ou sinal semelhante, um usuário pode ficar desorientado, sem saber como retornar a uma categoria pai ou incapaz de entender como a página atual se relaciona com o conteúdo que já viu. De acordo com a Organização Mundial da Saúde, mais de um bilhão de pessoas em todo o mundo vivem com algum tipo de deficiência, e os comprometimentos cognitivos representam uma parcela significativa e frequentemente subatendida dessa população.
Usuários de leitores de tela — que geralmente são cegos ou têm baixa visão — dependem fortemente da estrutura programática para entender o contexto da página. Um usuário vidente pode olhar rapidamente para um link de navegação destacado ou um item de trilha de navegação em negrito para se orientar instantaneamente. Um usuário de leitor de tela, em contraste, deve interpretar a página por meio de saída de áudio sequencial. Sem um atributo aria-current="page" no link de navegação ativo ou uma trilha de navegação devidamente estruturada com rótulos acessíveis, ele não recebe um sinal de orientação equivalente e pode precisar navegar extensivamente apenas para determinar onde está.
Usuários com deficiências motoras que navegam via teclado, acesso por interruptor ou dispositivos de rastreamento ocular se beneficiam de indicadores de localização porque eles reduzem a necessidade de navegação redundante e trabalhosa. Se um usuário já sabe que está na seção "Support" de um site corporativo, não precisa reexaminar toda a estrutura de navegação cada vez que carrega uma nova página.
Considere um cenário concreto: uma pessoa com demência em estágio inicial está navegando no portal online de um banco turco para encontrar informações sobre taxas de hipoteca. Ela clica em várias páginas e fica em dúvida se ainda está na seção de banco pessoal ou se entrou na área de banco empresarial. Sem uma trilha de navegação ou um item de navegação destacado que marque claramente sua seção atual, ela pode fechar o navegador frustrada ou cometer um erro custoso — como solicitar o produto errado. Uma trilha de navegação simples e bem implementada (por exemplo, Ana Sayfa > Bireysel Bankacılık > Krediler > Konut Kredisi) resolveria imediatamente essa confusão.
Além da acessibilidade, indicadores de localização proporcionam benefícios mensuráveis de usabilidade e SEO. Dados estruturados de breadcrumb (usando Schema.org BreadcrumbList) podem aparecer diretamente nos resultados de pesquisa do Google como rich snippets, melhorando as taxas de clique. Uma estrutura de site clara também reduz as taxas de rejeição, já que usuários que entendem onde estão têm mais probabilidade de explorar conteúdo relacionado em vez de abandonar o site.
Regras Relacionadas do Axe-core
WCAG 2.4.8 requer testes manuais porque ferramentas automatizadas não podem determinar de forma confiável se um mecanismo de localização está presente, é significativo e acessível em todos os contextos. Nenhuma regra do axe-core mapeia diretamente para este critério. Eis por que a automação é insuficiente e o que a avaliação manual deve cobrir:
- Presença de um mecanismo de localização (manual) — Um scanner automatizado pode detectar se existe um elemento de trilha de navegação no DOM, mas não pode determinar se essa trilha reflete com precisão a arquitetura de informação real do site, se está presente em todas as páginas dentro de um conjunto ou se é o tipo correto de indicador de localização para o modelo de navegação do site. Uma ferramenta pode encontrar um elemento
<nav aria-label="breadcrumb">e não relatar problema algum, mesmo que a trilha apareça apenas em algumas páginas ou contenha informações de hierarquia incorretas. - Precisão e completude (manual) — Ferramentas automatizadas não podem verificar se as informações de localização são precisas. Uma trilha de navegação que sempre mostra "Home > Current Page" independentemente da hierarquia real passaria em uma varredura automatizada, mas falharia neste critério, porque não representa de forma verdadeira a localização do usuário dentro do conjunto de páginas.
- Exposição programática (parcialmente automatizada) — Embora o axe-core possa sinalizar a ausência de atributos
aria-currentem links de navegação em algumas configurações, ele não pode determinar de forma conclusiva se a ausência dearia-currenté uma violação de 2.4.8 sem entender a estrutura geral do site e o papel de cada elemento de navegação. - Consistência em todo o conjunto de páginas (manual) — Um mecanismo de localização deve estar disponível em todo o conjunto relevante de páginas, não apenas em páginas selecionadas. Varreduras automatizadas normalmente avaliam uma página por vez e não conseguem verificar se um mecanismo está presente de forma consistente em todo um site ou seção.
Como Testar
- Identifique o conjunto de páginas: Determine se a página em teste pertence a um conjunto de páginas relacionadas com uma hierarquia definida (por exemplo, uma estrutura de navegação multinível, um assistente passo a passo ou uma biblioteca de conteúdo categorizada). Se a página for um documento independente, este critério pode não se aplicar.
- Execute uma varredura automatizada como linha de base: Use o axe DevTools (extensão de navegador) ou o Lighthouse no Chrome DevTools para executar uma auditoria de acessibilidade. Embora nenhuma das ferramentas audite diretamente 2.4.8, verifique problemas relacionados, como ausência de atributos
aria-currentem links de navegação, marcos<nav>sem rótulo e ausência de estrutura de trilha de navegação. Esses achados apoiam — mas não substituem — a revisão manual. - Inspecione visualmente em busca de um mecanismo de localização: Procure uma trilha de navegação, um link ativo destacado ou visualmente distinto na navegação, um contador de etapas ou um link para o mapa do site. Verifique se o mecanismo reflete com precisão a posição da página atual na hierarquia do site.
- Teste com um leitor de tela — NVDA + Firefox: Abra o NVDA, navegue até a página e pressione
Dpara percorrer os marcos. Localize o(s) marco(s) de navegação e ouça qualquer indicação da página ou seção atual. Verifique se o item de navegação ativo é anunciado de forma diferente (por exemplo, "current page" ou similar, normalmente transmitido viaaria-current="page"). Percorra a trilha de navegação, se presente, e verifique se cada nível é anunciado com seu texto de link e se a localização atual é claramente identificada. - Teste com VoiceOver + Safari (macOS/iOS): Ative o VoiceOver (
Command + F5), navegue até a trilha de navegação ou navegação principal usandoVO + Upara abrir o Rotor e selecione "Links" ou "Landmarks". Ouça como o item de navegação ativo ou o item atual da trilha é anunciado. Verifique se a localização atual é distinguível dos outros itens de navegação. - Teste com JAWS + Chrome: Use
Insert + F7para abrir a Lista de Links eInsert + F6para abrir a Lista de Títulos. Navegue até a área da trilha de navegação ou navegação e confirme se a página ou seção atual é identificável programaticamente. Verifique searia-currenté lido em voz alta (o JAWS anuncia isso como "current" para o elemento relevante). - Teste em várias páginas do conjunto: Navegue por pelo menos três a cinco páginas dentro da mesma seção ou hierarquia e confirme se o mecanismo de localização é atualizado corretamente em cada página e se está presente de forma consistente em todo o conjunto.
- Inspecione o DOM: Use as DevTools do navegador para verificar se os links da trilha de navegação têm nomes acessíveis descritivos, se o item atual usa
aria-current="page"(para a página atual) ouaria-current="true"(para a etapa atual em um processo) e se a trilha está envolvida em um elemento<nav>com um rótulo acessível, comoaria-label="Breadcrumb".
Como Corrigir
Navegação por Breadcrumb Ausente — Incorreto
<!-- No breadcrumb or location indicator present.
Users have no way to determine their location in the site hierarchy. -->
<nav aria-label='Main navigation'>
<ul>
<li><a href='/'>Home</a></li>
<li><a href='/products'>Products</a></li>
<li><a href='/products/laptops'>Laptops</a></li>
</ul>
</nav>
<h1>15-inch Laptops</h1>
Navegação por Breadcrumb Ausente — Correto
<!-- A breadcrumb nav is added above the main content.
aria-label distinguishes it from main navigation.
aria-current="page" marks the current location for screen readers.
The list structure communicates hierarchy. -->
<nav aria-label='Breadcrumb'>
<ol>
<li><a href='/'>Home</a></li>
<li><a href='/products'>Products</a></li>
<li><a href='/products/laptops'>Laptops</a></li>
<li><a href='/products/laptops/15-inch' aria-current='page'>15-inch Laptops</a></li>
</ol>
</nav>
<nav aria-label='Main navigation'>
<ul>
<li><a href='/'>Home</a></li>
<li><a href='/products'>Products</a></li>
<li><a href='/products/laptops'>Laptops</a></li>
</ul>
</nav>
<h1>15-inch Laptops</h1>
Link de Navegação Ativo Sem Indicador Programático — Incorreto
<!-- The active link is styled differently in CSS, but there is no
programmatic signal. Screen reader users cannot distinguish it
from the other navigation links. -->
<nav aria-label='Site navigation'>
<ul>
<li><a href='/about'>About</a></li>
<li><a href='/services' class='active'>Services</a></li>
<li><a href='/contact'>Contact</a></li>
</ul>
</nav>
Link de Navegação Ativo Sem Indicador Programático — Correto
<!-- aria-current="page" is added to the active link.
Screen readers will announce this link as "current" or "current page"
depending on the assistive technology, giving users a clear
programmatic location signal in addition to the visual styling. -->
<nav aria-label='Site navigation'>
<ul>
<li><a href='/about'>About</a></li>
<li><a href='/services' class='active' aria-current='page'>Services</a></li>
<li><a href='/contact'>Contact</a></li>
</ul>
</nav>
Formulário de Múltiplas Etapas Sem Indicador de Etapa — Incorreto
<!-- A multi-step checkout form with no indication of current step.
Users cannot determine how far they are through the process
or how many steps remain. -->
<form>
<h1>Shipping Information</h1>
<!-- form fields -->
<button type='submit'>Next</button>
</form>
Formulário de Múltiplas Etapas Sem Indicador de Etapa — Correto
<!-- A progress indicator communicates the user's position in the sequence.
aria-label on the nav provides context.
aria-current="step" marks the active step for assistive technologies.
The visible text "Step 2 of 4" is also available for all users. -->
<nav aria-label='Checkout progress'>
<ol>
<li><a href='/checkout/cart'>Cart</a></li>
<li aria-current='step'><strong>Shipping</strong></li>
<li>Payment</li>
<li>Confirmation</li>
</ol>
</nav>
<form>
<h1>Shipping Information <span>(Step 2 of 4)</span></h1>
<!-- form fields -->
<button type='submit'>Next: Payment</button>
</form>
Erros Comuns
- Fornecer uma trilha de navegação apenas na página inicial ou apenas em páginas finais (folhas): A trilha deve estar presente de forma consistente em todas as páginas dentro do conjunto. Exibi-la apenas em páginas de detalhes de produto, mas não em páginas de categoria, cria lacunas nas informações de orientação.
- Usar um link ativo estilizado visualmente sem adicionar
aria-current="page": Um link de navegação ativo em negrito ou sublinhado comunica localização visualmente, mas usuários de leitores de tela não recebem benefício algum, a menos quearia-current="page"também esteja presente nesse elemento. - Envolver a trilha de navegação em um
<div>em vez de um elemento<nav>: Usar um contêiner não semântico significa que a trilha não é exposta como um marco de navegação, tornando mais difícil para usuários de leitores de tela encontrá-la e interpretá-la. - Omitir
aria-labeldo<nav>da trilha quando também existe um marco de navegação principal: Dois marcos<nav>sem rótulo na mesma página criam ambiguidade. Leitores de tela podem anunciar ambos simplesmente como "navigation", deixando os usuários incapazes de distingui-los. - Usar
aria-current="true"em um link de página em vez dearia-current="page": O valorpageé o valor semanticamente correto para identificar a página atual em um contexto de navegação. Usartrueé menos descritivo e pode ser anunciado de forma diferente ou menos clara por tecnologias assistivas. - Confiar apenas no título da página para indicar localização: Um elemento
<title>descritivo (por exemplo, "Laptops — 15-inch Models | Acme Store") é útil e exigido pela WCAG 2.4.2, mas não satisfaz sozinho a 2.4.8, que requer um mecanismo que transmita a posição dentro da estrutura do conjunto de páginas, não apenas o nome da página atual. - Construir trilhas de navegação que refletem a estrutura de URL em vez da hierarquia de navegação: URLs e estruturas de navegação nem sempre se alinham. Trilhas de navegação devem refletir a arquitetura lógica da informação que um usuário entenderia, não o caminho de URL subjacente, que pode ser técnico ou opaco.
- Exibir a trilha de navegação como texto simples sem links para níveis ancestrais: Se apenas a página atual for exibida ou se os níveis ancestrais não forem vinculados, a trilha perde sua utilidade como indicador de localização e como auxílio de navegação. Itens ancestrais devem ser links para permitir que os usuários subam na hierarquia.
- Marcar o item atual da trilha apenas com uma mudança visual de separador em vez de
aria-current: Mudar a cor ou remover o sublinhado do último item da trilha não comunica aos leitores de tela que ele representa a página atual.aria-current="page"deve ser explicitamente adicionado. - Esquecer de atualizar o indicador de localização em aplicações de página única (SPAs) após a navegação no lado do cliente: Em SPAs construídas com frameworks como React ou Vue, transições de página ocorrem sem recarregamento completo do navegador. Se a trilha de navegação ou o indicador de navegação ativa não for atualizado programaticamente na mudança de rota, ele exibirá informações de localização desatualizadas, o que é pior do que não ter indicador algum.
Relação com os Regulamentos 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 web e móvel para uma ampla gama de organizações que operam na Turquia. A circular determina a conformidade com padrões de acessibilidade reconhecidos internacionalmente — adotando efetivamente o framework WCAG — e se aplica a um conjunto definido de tipos de entidades, incluindo instituições e agências públicas, plataformas de e-commerce, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde, empresas de telecomunicações com 200,000 ou mais assinantes, agências de viagem licenciadas, empresas de transporte privadas e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE).
WCAG 2.4.8 Localização é classificado como um critério de Nível AAA, o que significa que não está entre os critérios legalmente exigidos como base na circular, que faz referência à conformidade de Nível A e Nível AA como limite mínimo. No entanto, a distinção é importante de várias maneiras para as organizações abrangidas pela regulamentação.
Primeiro, certos serviços especializados — particularmente aqueles que atendem usuários com desafios cognitivos ou de navegação significativos, como portais de saúde para pacientes idosos ou plataformas educacionais para estudantes com dificuldades de aprendizagem — podem ser esperados a ir além da base AA para realmente atender ao espírito das obrigações de acessibilidade sob a lei turca e legislação relacionada, como a Lei sobre Pessoas com Deficiência nº 5378. Implementar 2.4.8 nesses contextos demonstra um compromisso substantivo, e não meramente processual, com a inclusão.
Segundo, instituições públicas turcas e entidades privadas reguladas estão cada vez mais sujeitas a mecanismos de auditoria e reclamação. Demonstrar conformidade em nível AAA — incluindo WCAG 2.4.8 — fornece um registro defensável de implementação de melhores práticas e reduz o risco regulatório no caso de uma reclamação formal de acessibilidade.
Terceiro, para plataformas de e-commerce e bancos em particular, indicadores de localização como trilhas de navegação têm valor comercial direto além de sua função de acessibilidade. O processo de solicitação de hipoteca online de um banco turco que inclui indicadores claros de etapa e navegação por breadcrumb não apenas atenderá usuários com deficiências cognitivas de forma mais eficaz, mas também reduzirá taxas de abandono e apoiará a conversão — alinhando o investimento em acessibilidade com resultados de negócios mensuráveis.
Organizações que utilizam o SDK de overlay Accsible podem aproveitar seus recursos integrados de aprimoramento de breadcrumb e injeção de aria-current para aproximar sites existentes da conformidade com 2.4.8 sem exigir uma refatoração completa da base de código. No entanto, para uma conformidade completa e robusta — especialmente para entidades abrangidas pela Circular Presidencial 2025/10 — a implementação no lado do servidor ou em tempo de build de marcação semântica de breadcrumb e indicadores de navegação continua sendo a abordagem recomendada, já que soluções de overlay complementam, mas não substituem, a marcação acessível fundamental.
