WCAG 3.2.6: Ajuda consistente

O Que Esta Regra Significa

O Critério de Sucesso 3.2.6 Ajuda Consistente (nível AA, introduzido no WCAG 2.2) estabelece: “Se uma página da Web contiver qualquer um dos seguintes mecanismos de ajuda, e esses mecanismos forem repetidos em várias páginas da Web, eles devem ocorrer na mesma ordem relativa em relação ao restante do conteúdo da página, a menos que uma alteração seja iniciada pelo usuário.” Os mecanismos de ajuda abrangidos por este critério são: detalhes de contato humano (como número de telefone, endereço de e-mail ou horário de atendimento), um mecanismo de contato humano (como um widget de chat ao vivo ou um formulário de contato), uma opção de autoatendimento (como uma página de perguntas frequentes, um centro de ajuda ou uma base de conhecimento) e um mecanismo de contato totalmente automatizado (como um chatbot ou assistente virtual).

O requisito principal é a consistência da ordem relativa, não a colocação idêntica em pixels. Se um botão de chat ao vivo aparece no canto inferior direito da página inicial, ele deve aparecer na mesma posição inferior direita em todas as outras páginas em que for exibido. Se um link “Ajuda” for o terceiro item na barra de navegação superior em uma página, ele deve permanecer o terceiro item — ou pelo menos manter a mesma relação relativa com o conteúdo ao redor — em todas as outras páginas em que essa barra de navegação aparecer.

Uma página atende a este critério quando: (a) não existe nenhum mecanismo de ajuda no site, ou (b) existe um mecanismo de ajuda em apenas uma página, ou (c) sempre que um mecanismo de ajuda é repetido em várias páginas, ele aparece na mesma ordem relativa dentro do layout da página. Uma página falha quando um mecanismo de ajuda presente em várias páginas muda sua posição na ordem da página de uma página para outra sem que o usuário tenha iniciado essa mudança — por exemplo, um widget de chat que flutua no canto inferior direito na página de listagem de produtos, mas se move para o canto inferior esquerdo na página de checkout.

O critério inclui uma exceção explícita: a ordem pode mudar se a mudança for iniciada pelo usuário. Por exemplo, se uma pessoa arrasta e reposiciona um widget de ajuda flutuante, ou se uma preferência do usuário alterna o painel de ajuda de um lado para o outro, esse reposicionamento é iniciado pelo usuário e não constitui falha. Essa exceção reflete a mesma lógica de ação iniciada pelo usuário encontrada no SC 3.2.2 (Na Entrada).

É importante observar que este critério não exige que todas as páginas tenham um mecanismo de ajuda, nem exige que o mecanismo de ajuda seja eficaz ou fácil de usar. Ele apenas regula a consistência posicional quando o mecanismo está presente em várias páginas.

Por Que Isso Importa

A colocação consistente da ajuda é projetada principalmente para beneficiar pessoas com deficiências cognitivas, incluindo pessoas com comprometimentos de memória, dificuldades de atenção, dificuldades de aprendizagem como dislexia e condições como TDAH ou demência em estágio inicial. Para essas pessoas, localizar um elemento de interface familiar exige esforço cognitivo deliberado. Quando um botão de ajuda ou link de contato aparece em um local diferente em cada página, elas precisam despender esse esforço repetidamente, aumentando a carga cognitiva e o risco de frustração, desorientação ou abandono da tarefa.

Pessoas que são novas na web ou têm letramento digital limitado — uma população significativa na Turquia e globalmente — também dependem fortemente de uma colocação previsível. De acordo com a Organização Mundial da Saúde, mais de 1,3 bilhão de pessoas no mundo vivem com algum tipo de deficiência, e condições cognitivas e neurológicas representam uma parcela substancial dessa população. Projetar para consistência posicional, portanto, atende a um público amplo, muito além das pessoas com deficiências clinicamente diagnosticadas.

Considere um cenário concreto: uma usuária com doença de Alzheimer em estágio inicial está tentando concluir uma reserva de voo online. Ela se lembra de que o site da companhia aérea tem uma opção de chat ao vivo que pode usar quando ficar confusa. Na página de resultados de busca, o ícone de chat aparece no canto inferior direito. Mas, quando ela vai para a página de seleção de assentos, o widget de chat foi realocado para o canto superior direito dentro de uma gaveta de ajuda recolhível. Ela não consegue encontrá-lo, fica sobrecarregada e abandona completamente a reserva. Isso é uma falha direta e evitável do SC 3.2.6.

Para pessoas com deficiência motora que navegam com acesso por varredura, software de rastreamento ocular ou ponteiros de cabeça, reposicionar um mecanismo de ajuda significa reexaminar e mirar novamente uma nova área da tela — um processo trabalhoso e demorado que a colocação consistente elimina.

Pessoas que usam leitores de tela e que memorizaram a ordem de tabulação ou a estrutura de títulos de um site para chegar rapidamente à seção de ajuda são igualmente afetadas quando a ordem no DOM desse mecanismo muda de página para página, mesmo que a posição visual pareça semelhante.

Além da acessibilidade, há um claro benefício de usabilidade e de negócios: pessoas que conseguem encontrar ajuda rapidamente têm menos probabilidade de abandonar uma transação, reduzindo taxas de desistência e custos de suporte. Padrões de interface consistentes também reforçam a confiança na marca e a percepção de profissionalismo.

Regras Relacionadas do Axe-core

O WCAG 3.2.6 é classificado como exigindo apenas testes manuais e não possui uma regra automatizada correspondente no axe-core que possa sinalizar violações de forma programática. Isso é intencional, e entender o motivo ajuda quem testa a compreender a natureza deste critério.

• Inspeção manual obrigatória — nenhuma regra do axe disponível: Ferramentas automatizadas como axe-core, Lighthouse ou IBM Equal Access Checker analisam uma única página isoladamente. Elas não têm entendimento inerente do que é um “mecanismo de ajuda”, nenhuma capacidade de comparar a posição relativa no DOM de um elemento em vários carregamentos de página ou URLs, e nenhuma forma de determinar se um determinado elemento desempenha a função de fornecer ajuda. Um widget de chat, por exemplo, pode ser implementado como uma simples <div>, um componente de shadow DOM, um <iframe> ou um script injetado de terceiros — nenhum dos quais pode ser identificado de forma confiável como um “mecanismo de ajuda” por um motor de regras sem julgamento humano. O axe-core precisaria de consciência de estado entre páginas e reconhecimento de intenção semântica para sinalizar isso, capacidades que estão fora do escopo de uma análise estática de página única. É por isso que o próprio WCAG 2.2 rotula o 3.2.6 como um critério que exige avaliação humana por meio de auditorias manuais estruturadas e comparação entre páginas.

Como Testar

1. Inventariar mecanismos de ajuda: Antes de testar páginas individuais, crie uma lista de todos os mecanismos de ajuda presentes no site — widgets de chat ao vivo, números de telefone de contato, links de e-mail, links de FAQ, iniciadores de chatbot, formulários de contato e links para o centro de ajuda. Anote em quais páginas cada mecanismo aparece. Se um mecanismo aparecer em apenas uma página, ele está fora do escopo deste critério.
2. Executar uma varredura automatizada para contexto de base: Use o axe DevTools (extensão de navegador) ou o Lighthouse em páginas representativas para capturar instantâneos da ordem do DOM e identificar a posição estrutural de elementos relacionados à ajuda. Embora nenhuma regra do axe direcione diretamente o SC 3.2.6, a ordem do DOM relatada por essas ferramentas pode ser comparada manualmente entre páginas. Exporte ou faça capturas de tela da árvore de acessibilidade de cada página que contenha um mecanismo de ajuda.
3. Comparar posições relativas entre páginas: Abra duas ou mais páginas que compartilhem o mesmo mecanismo de ajuda lado a lado (ou sequencialmente). Para cada mecanismo, identifique sua posição em relação às regiões de marco ao redor (<header>, <main>, <footer>, <nav>). Registre se o mecanismo aparece na mesma região de marco e na mesma ordem relativa (antes ou depois de elementos adjacentes) em todas as páginas. Uma mudança de posição constitui uma possível falha.
4. Testar com navegação por teclado (todos os navegadores): Percorra cada página que contenha um mecanismo de ajuda usando a tecla Tab. Conte o número de paradas de tabulação necessárias para chegar ao mecanismo de ajuda a partir do início da página. Compare essa contagem entre páginas. Uma diferença significativa — por exemplo, alcançável em 5 tabs na página inicial, mas em 47 tabs na página de checkout — indica uma mudança na ordem do DOM, mesmo que a posição visual pareça semelhante.
5. Testar com NVDA + Firefox: Abra a Lista de Elementos do NVDA (tecla NVDA + F7) e mude para a visualização de Links ou Botões. Localize o mecanismo de ajuda na lista. Observe sua posição em relação a outros elementos listados. Repita em cada página em que o mecanismo aparece e compare as posições.
6. Testar com VoiceOver + Safari (macOS/iOS): Use o rotor do VoiceOver (VO + U) para abrir a lista de Links ou Controles de Formulário. Navegue até o mecanismo de ajuda e observe sua posição na lista. Compare entre páginas.
7. Testar com JAWS + Chrome: Use a Lista de Links do JAWS (Insert + F7) para localizar o mecanismo de ajuda. Observe sua posição ordinal e os elementos adjacentes. Repita em várias páginas.
8. Verificar exceções iniciadas pelo usuário: Se o site permitir que as pessoas reposicionem ou ocultem mecanismos de ajuda (por exemplo, um widget de chat arrastável), verifique se o reposicionamento é acionado por uma ação explícita da pessoa usuária e se a preferência persiste de forma lógica. Documente isso como uma exceção válida sob o critério.
9. Revisar em viewports móveis: Layouts responsivos às vezes reordenam elementos do DOM em diferentes breakpoints. Teste em viewports de desktop e mobile (larguras de 375px e 1440px, no mínimo) para confirmar que o mecanismo de ajuda mantém uma colocação relativa consistente em todos os tamanhos de tela comuns.

Como Corrigir

Widget de chat flutuante — Incorreto

<!-- Page A (homepage): chat button in bottom-right -->
<div class='chat-widget' style='position:fixed; bottom:20px; right:20px;'>
  <button>Chat with Us</button>
</div>

<!-- Page B (checkout): chat button moved to bottom-left -->
<div class='chat-widget' style='position:fixed; bottom:20px; left:20px;'>
  <button>Chat with Us</button>
</div>
<!-- FAIL: The widget changes its fixed position between pages,
     breaking consistent help placement. -->

Widget de chat flutuante — Correto

<!-- Both Page A and Page B: chat button consistently in bottom-right -->
<div class='chat-widget chat-widget--bottom-right'>
  <button type='button' aria-label='Open live chat support'>
    Chat with Us
  </button>
</div>
<!-- PASS: The widget appears in the same corner on every page.
     Use a CSS class defined in a shared stylesheet rather than
     inline styles, so the position is controlled centrally and
     applied consistently across all templates. -->

Link de ajuda na navegação — Incorreto

<!-- Page A: Help is the 4th nav item -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>

<!-- Page B (product detail): Help link removed from nav,
     placed in a footer section instead -->
<footer>
  <a href='/help'>Help Center</a>
</footer>
<!-- FAIL: The Help link has moved from the main navigation
     to the footer, changing its relative order significantly. -->

Link de ajuda na navegação — Correto

<!-- Both Page A and Page B share the same navigation template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>
<!-- PASS: The Help link is the 4th item in the main nav
     on every page where the nav is present. Using a shared
     navigation component or server-side include ensures
     this is maintained automatically. -->

Exibição condicional de ajuda — Incorreto

<!-- On logged-out pages: phone number in header -->
<header>
  <p>Need help? Call <a href='tel:+908501234567'>0850 123 45 67</a></p>
</header>

<!-- On logged-in pages: phone number removed from header,
     only available deep inside an account dropdown menu -->
<header>
  <nav aria-label='Account menu'>
    <details>
      <summary>My Account</summary>
      <ul>
        <li><a href='/orders'>Orders</a></li>
        <li><a href='/contact'>Contact: 0850 123 45 67</a></li>
      </ul>
    </details>
  </nav>
</header>
<!-- FAIL: The contact number changes its relative position
     dramatically depending on authentication state,
     making it unpredictable for returning users. -->

Exibição condicional de ajuda — Correto

<!-- Both logged-out and logged-in pages: phone in the same header position -->
<header>
  <div class='header-support'>
    <a href='tel:+908501234567' aria-label='Call support: 0850 123 45 67'>
      <svg aria-hidden='true' focusable='false'><!-- phone icon --></svg>
      0850 123 45 67
    </a>
  </div>
  <nav aria-label='Account menu'>
    <!-- account links here -->
  </nav>
</header>
<!-- PASS: The contact mechanism is always in the same position
     within the header regardless of authentication state.
     Additional account-specific links can appear elsewhere
     without moving the help mechanism. -->

Erros Comuns

• Colocar o widget de chat em cantos diferentes em diferentes templates de página: Equipes de desenvolvimento frequentemente aplicam posicionamento fixo para widgets de chat por template, em vez de usar uma folha de estilos global, fazendo com que o widget apareça no canto inferior direito em páginas de marketing e no canto inferior esquerdo em páginas de aplicativo. Use um único componente incluído globalmente com uma classe de posição fixa.
• Remover o link de ajuda da navegação em páginas de checkout para reduzir a desordem: Alguns padrões de UX intencionalmente removem a navegação em páginas de checkout para otimizar conversão. Se um mecanismo de ajuda fizer parte dessa navegação, removê-lo desse template de página quebra a consistência. Em vez disso, mantenha o link de ajuda em um cabeçalho mínimo mesmo em fluxos de checkout simplificados.
• Injetar mecanismos de ajuda por meio de scripts de terceiros que carregam com posições imprevisíveis no DOM: Muitos SDKs de chat ao vivo injetam seu widget no DOM de forma assíncrona, e seu ponto de inserção pode variar com base na ordem de carregamento dos scripts. Isso pode fazer com que o widget apareça em uma posição diferente na árvore de acessibilidade entre páginas. Configure widgets de terceiros para sempre serem anexados a um elemento âncora fixo e conhecido no DOM.
• Usar a propriedade order do CSS ou reordenação com flexbox/grid para mover visualmente o elemento de ajuda sem alterar a ordem no DOM, e depois mudar esse CSS por página: Embora a posição visual possa parecer consistente, substituições de CSS por página que alteram a ordem visual de um mecanismo de ajuda ainda mudam a ordem perceptível para a pessoa usuária e podem confundir pessoas que usam leitores de tela, cuja ordem de leitura segue o DOM.
• Confiar em ferramentas de testes A/B que trocam a posição do elemento de ajuda entre variantes de teste: Se pessoas na variante A veem o botão de ajuda na barra superior e pessoas na variante B o veem no rodapé, essas pessoas experimentarão colocação de ajuda inconsistente entre páginas dentro de sua sessão, à medida que o framework de A/B aplica variantes diferentes em páginas diferentes. Garanta que testes A/B que afetem a colocação de mecanismos de ajuda apliquem a mesma variante de forma consistente em todas as páginas de uma sessão.
• Tratar estados autenticado e não autenticado como “sites” diferentes e aplicar layouts de ajuda diferentes: Pessoas que fazem login no meio da sessão de repente encontrarão o mecanismo de ajuda em um novo local. A mudança de estado de autenticação não é iniciada pelo usuário no contexto da colocação da ajuda, portanto isso ainda falha no SC 3.2.6. Aplique um layout de ajuda consistente em todos os estados de autenticação.
• Incorporar o número de telefone de ajuda apenas em texto denso de rodapé em algumas páginas e em uma barra de cabeçalho dedicada em outras: Mesmo que o número de telefone esteja tecnicamente presente em todas as páginas, uma mudança significativa em sua posição relativa (de primeiro elemento interativo no cabeçalho para enterrado no rodapé após centenas de links) é uma falha de ordem consistente.
• Presumir que, porque um ícone de ajuda está sempre visualmente “no canto”, o critério é atendido: O critério mede a ordem relativa no conteúdo da página, não apenas coordenadas de pixel absolutas. Um ícone de chat que está sempre visualmente no canto inferior direito, mas aparece em pontos muito diferentes na ordem do DOM em páginas diferentes (por exemplo, imediatamente após a tag <body> em uma página e logo antes da tag de fechamento </body> em outra) ainda pode falhar para pessoas que usam teclado e leitores de tela.
• Esquecer de auditar breakpoints responsivos: Um mecanismo de ajuda que é consistente em larguras de desktop pode ser ocultado ou movido para um menu hambúrguer em viewports estreitos, resultando em uma posição diferente no mobile. Se pessoas em dispositivos móveis experimentarem uma posição relativa diferente da de pessoas em desktop, isso deve ser avaliado em relação ao critério — especialmente se o mobile for o principal meio de acesso do público-alvo.
• Não documentar locais de mecanismos de ajuda em sistemas de design: Sem um padrão documentado de onde mecanismos de ajuda devem aparecer, desenvolvedores e designers individuais tomarão decisões independentes que produzem inconsistências ao longo do tempo. Adicione regras de colocação de mecanismos de ajuda explicitamente à documentação do seu sistema de design ou biblioteca de componentes.

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 uma estrutura nacional abrangente para acessibilidade digital. A circular determina a conformidade com o WCAG 2.2 nível AA como padrão básico de acessibilidade para uma ampla gama de serviços digitais que operam na Turquia. O WCAG 3.2.6 Ajuda Consistente, como critério de nível AA introduzido no WCAG 2.2, está diretamente dentro do escopo dessa obrigação legal.

Os tipos de entidades abrangidos pela Circular Presidencial 2025/10 incluem: instituições e órgãos públicos em níveis de governo central e local; bancos e prestadores de serviços financeiros regulados pela Agência de Regulação e Supervisão Bancária (BDDK); plataformas de e-commerce e marketplaces online; hospitais e prestadores de serviços de saúde que oferecem serviços digitais voltados a pacientes; empresas de telecomunicações com 200.000 ou mais assinantes; agências de viagem com sistemas de reserva online; empresas privadas de transporte que operam serviços regulares; e escolas e instituições de ensino privadas autorizadas pelo Ministério da Educação Nacional (MoNE). Para todas essas entidades, o conjunto completo de critérios do WCAG 2.2 nível AA — incluindo o SC 3.2.6 — é o padrão aplicável.

A conformidade com o WCAG 3.2.6 também é pré-requisito para obtenção do Erişilebilirlik Logosu (Logotipo de Acessibilidade) emitido pelo Ministério da Família e Serviços Sociais da Turquia (Aile ve Sosyal Hizmetler Bakanlığı). Esse logotipo serve como marca oficial de conformidade em acessibilidade e é cada vez mais reconhecido por consumidores turcos e responsáveis por compras públicas como um sinal de qualidade. Organizações que buscam o logotipo devem demonstrar conformidade total com o WCAG 2.2 nível AA em suas propriedades digitais, o que significa que colocação inconsistente de ajuda — mesmo que aparentemente menor — pode desqualificar uma candidatura.

Do ponto de vista prático de conformidade, o SC 3.2.6 é particularmente relevante para provedores turcos de e-commerce e serviços financeiros, cujos sites e aplicativos web móveis normalmente apresentam widgets de chat ao vivo, links de contato via WhatsApp e seções de FAQ como principais canais de suporte ao cliente. Garantir que esses mecanismos de ajuda apareçam em posições consistentes em páginas de listagem de produtos, páginas de carrinho, fluxos de checkout e seções de gerenciamento de conta é tanto uma obrigação legal sob a Circular quanto uma boa prática de UX para atender à diversa base de usuários de internet da Turquia — que inclui uma grande população de pessoas usuárias de primeira viagem e com baixo letramento digital, que mais se beneficiam de padrões de interface previsíveis.

Organizações sujeitas à Circular que ainda não auditaram a colocação de seus mecanismos de ajuda devem priorizar uma auditoria de consistência entre páginas como parte de seu roteiro de conformidade com o WCAG 2.2. Como esse critério exige testes manuais, ele deve ser incluído tanto em auditorias iniciais de conformidade quanto em ciclos contínuos de garantia de qualidade, especialmente após grandes reformulações ou mudanças de template que possam, inadvertidamente, alterar a posição de elementos de ajuda.