WCAG 3.2.4: Identificação Consistente

O que esta regra significa

O Critério de Sucesso 3.2.4 das WCAG — Identificação consistente — estabelece que componentes que têm a mesma funcionalidade dentro de um conjunto de páginas da web devem ser identificados de forma consistente. Isso significa que sempre que um elemento interativo ou imagem desempenhar a mesma função, ele deve ter o mesmo nome ou rótulo acessível toda vez que aparecer no site.

O termo "identificado" neste contexto se refere a como um componente é apresentado às tecnologias assistivas e às pessoas usuárias. Isso inclui o texto do rótulo visível, o atributo aria-label ou aria-labelledby, o texto alt em uma imagem, o atributo title ou o nome acessível calculado pela árvore de acessibilidade do navegador. Se um botão de busca aparece em todas as páginas de um site, ele deve ser sempre chamado de "Search" — não "Search" na página inicial, "Find" na página de listagem de produtos e "Go" na página de checkout.

Este critério se aplica a um conjunto de páginas da web, que as WCAG definem como uma coleção de páginas que compartilham um propósito comum e são produzidas pelo mesmo autor. Isso abrange um site inteiro, um aplicativo web ou um formulário de múltiplas etapas que se estende por várias URLs. Componentes que são apenas visualmente semelhantes, mas servem a funções diferentes, não precisam compartilhar o mesmo nome — a exigência está especificamente vinculada à funcionalidade idêntica.

O que conta como aprovação: Um ícone de navegação que abre um menu hambúrguer é rotulado de forma consistente como "Open navigation menu" (ou equivalente) em todas as páginas. Um ícone de carrinho de compras tem sempre o texto alternativo ou nome acessível "Shopping cart". Um botão de logout é sempre rotulado "Log out". Variação na redação para a mesma função constitui falha.

O que conta como falha: Um botão de envio rotulado "Submit" no formulário de registro, mas rotulado "Send" no formulário de contato quando ambos os botões têm o mesmo propósito funcional de transmitir dados inseridos pela pessoa usuária. Um botão de ícone mostrando uma lupa rotulado "Search" na maioria das páginas, mas "Ara" em uma única subpágina traduzida sem uma estratégia de idioma consistente.

Exceção oficial: As WCAG observam explicitamente que é aceitável ter dois componentes com o mesmo nome acessível se eles desempenham funções diferentes — nesse caso, a própria função diferente os desambigua. O critério só é acionado quando a função é idêntica, mas a nomeação é inconsistente.

Por que isso é importante

Identificação inconsistente cria um ônus desproporcional para pessoas usuárias que dependem de estratégias de navegação não visuais ou baseadas em padrões. Os grupos mais severamente afetados incluem pessoas que usam leitores de tela, pessoas com deficiências cognitivas e pessoas com deficiências motoras que dependem de softwares de controle por voz.

Pessoas que usam leitores de tela constroem um modelo mental de um site ouvindo os nomes dos elementos enquanto navegam com a tecla Tab ou por marcos. Quando um botão que desempenhava a mesma função na página anterior agora tem um nome diferente, a pessoa precisa parar, investigar e se reorientar — uma experiência demorada e frustrante. 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. Mesmo uma fração dessa população interagindo com um site rotulado de forma inconsistente encontrará barreiras significativas.

Pessoas com deficiências cognitivas, incluindo aquelas com dislexia, transtornos de atenção ou comprometimentos de memória, dependem fortemente de nomes previsíveis para reduzir a carga cognitiva. Encontrar um ícone ou controle familiar com um nome diferente força o reaprendizado e causa ansiedade. Rotulagem consistente reduz o esforço necessário para construir memória de procedimento ao usar um site regularmente.

Pessoas que usam controle por voz (usando ferramentas como Dragon NaturallySpeaking ou Voice Control da Apple) falam o nome de um controle para ativá-lo. Se o nome acessível de um botão for diferente do que elas esperam com base na experiência anterior com o site, o comando falado falhará silenciosamente — o software simplesmente não encontrará uma correspondência. Isso torna a interface efetivamente inutilizável naquele momento.

Um cenário concreto do mundo real: Considere uma plataforma de e-commerce turca que vende roupas. Na página de grade de produtos, cada item tem um botão com um ícone de coração cujo nome acessível é "Add to favourites". Na página de detalhes do produto, o nome acessível do mesmo ícone de coração é "Kaydet" (turco para "Salvar"). Uma pessoa usuária de leitor de tela que aprendeu a ativar o botão de coração pelo nome na página de grade agora não consegue encontrar o controle equivalente na página de detalhes sem uma exploração exaustiva. Ela pode abandonar o site completamente.

Além da acessibilidade, a rotulagem consistente beneficia o SEO. Mecanismos de busca analisam nomes acessíveis e texto de links para entender o conteúdo da página. Rotulagem inconsistente para links funcionalmente idênticos (por exemplo, "Read more", "Continue reading", "Learn more" todos apontando para páginas de detalhes de artigos) dilui sinais de palavras-chave e torna mais difícil para os rastreadores entenderem a estrutura do site.

Regras relacionadas do Axe-core

O critério 3.2.4 das WCAG exige testes manuais porque ferramentas automatizadas não conseguem determinar a intenção semântica entre páginas ou saber que dois componentes com nomes diferentes desempenham a mesma função. Nenhuma regra do axe-core mapeia diretamente para esse critério. Eis por que a automação é insuficiente e o que as pessoas testadoras devem fazer em vez disso:

• Teste manual necessário — consistência entre páginas: O axe-core avalia uma única página isoladamente. Ele não tem mecanismo para comparar o nome acessível de um botão "Search" na página inicial com um botão "Find" em uma página de produto, porque não mantém um inventário entre páginas de nomes de componentes. Uma pessoa testadora deve catalogar elementos funcionais repetidos e verificar se seus nomes são uniformes em todas as páginas em que aparecem.
• Teste manual necessário — consistência de texto alternativo de ícones e imagens: Ferramentas automatizadas podem detectar texto alternativo ausente (por meio da regra image-alt), mas não conseguem determinar se duas imagens que servem ao mesmo propósito têm o mesmo texto alternativo em páginas diferentes. Por exemplo, um ícone de impressora em uma página de recibos e o mesmo ícone de impressora em uma página de fatura podem ter texto alternativo — mas se um diz "Print" e o outro diz "Print this page", uma pessoa precisa julgar se isso constitui uma inconsistência sob o critério 3.2.4.
• Teste manual necessário — consistência de rótulos ARIA: O axe-core verifica se rótulos ARIA estão presentes e não vazios, mas não audita se os valores de aria-label para o mesmo tipo de componente são consistentes em todo o conjunto de páginas. Uma pessoa testadora deve inspecionar a árvore de acessibilidade em várias páginas e comparar nomes de controles funcionalmente idênticos.
• Teste manual necessário — rótulos de controles de formulário: Regras automatizadas como label verificam se campos de entrada estão associados a rótulos, mas não verificam se um campo "Username" na página de login também é rotulado "Username" (em vez de "Email" ou "User ID") na página de recuperação de conta quando ambos os campos aceitam o mesmo tipo de entrada e têm o mesmo papel funcional.

Como testar

1. Pré-varredura automatizada: Execute o axe DevTools ou o Lighthouse em cada página para identificar quaisquer violações relacionadas, como nomes acessíveis ausentes (image-alt, button-name, link-name). Resolva essas primeiro — não é possível avaliar a consistência de nomes se eles estiverem ausentes. Anote os nomes acessíveis relatados para componentes repetidos nos resultados da varredura.
2. Crie um inventário de componentes: Liste manualmente todos os componentes funcionais que se repetem entre páginas — menus de navegação, campos de busca, botões de envio, botões de ícone, links de trilha de navegação (breadcrumbs), links de redes sociais, botões de impressão/compartilhamento e controles de paginação. Registre o nome acessível de cada instância usando o painel de Acessibilidade do navegador (Chrome DevTools > Elements > Accessibility, ou Firefox Accessibility Inspector).
3. Compare nomes entre páginas: Para cada tipo de componente no inventário, verifique se todas as instâncias têm o mesmo nome acessível. Sinalize qualquer discrepância. Preste atenção especial a componentes que aparecem em cabeçalhos, rodapés e barras laterais, pois estes são os mais propensos a serem rotulados de forma inconsistente entre templates.
4. Teste com leitor de tela usando NVDA + Firefox: Navegue até a página inicial e use a lista de elementos do NVDA (Insert + F7) para abrir a lista de botões e links. Anote os nomes de controles repetidos. Em seguida, navegue para três ou quatro outras páginas representativas e repita. Ouça qualquer variação de nome em controles funcionalmente idênticos.
5. Teste com leitor de tela usando VoiceOver + Safari (macOS/iOS): Use o Rotor (VO + U) para abrir a lista de botões ou links em cada página. Compare os nomes de elementos repetidos. No iOS, deslize pelos elementos interativos em páginas equivalentes e anote quaisquer diferenças de nome.
6. Teste com leitor de tela usando JAWS + Chrome: Use o cursor virtual do JAWS e a lista de campos de formulário (Insert + F5) e de links (Insert + F7) em várias páginas. Confirme que controles idênticos compartilham nomes idênticos em todo o site.
7. Teste de controle por voz: Usando o Windows Voice Access ou o Dragon NaturallySpeaking, fale o nome de um controle repetido em uma página (por exemplo, "Click Search"). Navegue para outra página e fale o mesmo comando. Se falhar, os nomes são inconsistentes do ponto de vista funcional.

Como corrigir

Botão de busca com rótulos inconsistentes — Incorreto

<!-- Homepage -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Product listing page -->
<button type='submit' aria-label='Find products'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Blog page -->
<button type='submit' aria-label='Go'>
  <svg aria-hidden='true'>...</svg>
</button>

Botão de busca com rótulos inconsistentes — Correto

<!-- Homepage, product listing page, and blog page all use the same label -->
<!-- Consistent aria-label across all pages ensures assistive technologies
     always announce the same name for this functionally identical button -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

Imagem de ícone usada para a mesma ação com textos alternativos diferentes — Incorreto

<!-- Order history page -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print order' />
</a>

<!-- Invoice page -->
<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print this document' />
</a>

<!-- Receipt page -->
<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Yazdir' />
</a>

Imagem de ícone usada para a mesma ação com textos alternativos diferentes — Correto

<!-- All print links across the site share the same alt text.
     The destination URL differentiates which document is printed;
     the control's accessible name remains consistent. -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Print' />
</a>

Botão de fechar navegação nomeado de forma inconsistente — Incorreto

<!-- Mobile menu on homepage -->
<button aria-label='Close menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Mobile menu on product page (different developer implemented it) -->
<button aria-label='Dismiss navigation' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Botão de fechar navegação nomeado de forma inconsistente — Correto

<!-- A shared component/template ensures the label is identical everywhere.
     Using a single reusable component or design token for the label
     eliminates the risk of developer-introduced inconsistencies. -->
<button aria-label='Close navigation menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Links de compartilhamento em redes sociais com nomes variados — Incorreto

<!-- Article page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

<!-- Video page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Tweet this'>
  <svg aria-hidden='true'>...</svg>
</a>

Links de compartilhamento em redes sociais com nomes variados — Correto

<!-- Both pages use the same accessible name for the functionally
     identical sharing action. The URL parameter carries the context;
     the control name stays uniform. -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

Erros comuns

• Usar valores de aria-label diferentes em templates diferentes para o mesmo componente: Quando desenvolvedores diferentes constroem templates de página de forma independente, sem uma biblioteca de componentes compartilhada, botões de ícone como fechar, buscar e carrinho frequentemente recebem rótulos ad hoc. Estabeleça um token de sistema de design ou componente compartilhado para cada elemento interativo repetido, de modo que o nome acessível seja definido uma vez e reutilizado em todos os lugares.
• Traduzir nomes acessíveis de forma inconsistente em páginas multilíngues: Um site pode rotular corretamente um botão de busca como "Search" em inglês, mas usar um equivalente turco inconsistente — às vezes "Ara", às vezes "Arama Yap" — dependendo de qual template de página foi localizado primeiro. Mantenha uma única chave de tradução por rótulo de componente e aplique-a em todos os arquivos de idioma.
• Anexar sufixos específicos de contexto a controles que, de outra forma, são idênticos: Rotular botões como "Add to cart — Blue T-Shirt", "Add to cart — Red Dress" etc. quando a função principal (adicionar ao carrinho) é a mesma não é automaticamente uma falha do critério 3.2.4 — as WCAG permitem desambiguação — mas fazer isso de forma inconsistente (às vezes com sufixo, às vezes sem) cria confusão. Escolha um padrão e aplique-o de forma uniforme.
• Confiar no rótulo de texto visível para garantir consistência enquanto aria-label difere: Quando um botão visualmente mostra "Search", mas um template adiciona aria-label='Search the site' e outro não tem aria-label (de modo que o nome acessível é derivado apenas do texto visível), leitores de tela anunciarão nomes diferentes, mesmo que o botão pareça o mesmo. Audite o cálculo completo do nome acessível, não apenas o rótulo visível.
• Permitir que editores de CMS alterem livremente o texto de botões sem governança de acessibilidade: Sistemas de gerenciamento de conteúdo que expõem rótulos de botões como campos editáveis permitem que editores renomeiem "Submit" para "Send" ou "Gönder" com base em preferência pessoal. Restrinja a edição de rótulos para componentes funcionais de interface ou adicione validação que avise editores quando um rótulo proposto divergir do padrão estabelecido.
• Deixar de auditar widgets de terceiros ou componentes incorporados: Widgets de chat, banners de consentimento de cookies e iframes de pagamento injetados por terceiros frequentemente contêm botões rotulados de forma diferente das convenções do site hospedeiro. Revise e, quando possível, configure os nomes acessíveis de terceiros para se alinharem às suas convenções de nomenclatura, ou documente a divergência como uma exceção conhecida.
• Usar texto de tooltip (atributo title) como o único nome acessível em algumas instâncias, mas aria-label em outras: O atributo title não é anunciado de forma confiável por todas as tecnologias assistivas e é considerado uma fonte fraca de nome acessível. Se algumas instâncias de um componente repetido usam title e outras usam aria-label, os nomes calculados podem diferir devido a diferenças de tratamento entre navegadores e leitores de tela.
• Presumir que controles de paginação estão isentos porque seus números diferem: Controles "Next page" e "Previous page", mesmo quando incluem um número de página em seu rótulo (por exemplo, "Go to page 3"), devem aplicar um padrão consistente. Misturar "Next" em algumas páginas com "Next page" ou "İleri" em outras para o mesmo controle de paginação falha no critério 3.2.4.
• Não testar componentes de cabeçalho e rodapé em cada template de página distinto: Sites frequentemente têm vários templates de página (página inicial, página de categoria, página de artigo, checkout). Componentes de cabeçalho e rodapé podem ser renderizados de forma ligeiramente diferente entre templates. Pessoas testadoras que verificam apenas um ou dois templates podem perder inconsistências introduzidas por substituições específicas de template.
• Confundir 3.2.4 com 3.2.3 (Navegação consistente): Equipes às vezes acreditam que, se a ordem de navegação é consistente (3.2.3), a nomeação também deve ser — mas estes são requisitos separados. Uma barra de navegação na mesma localização em todas as páginas (conformidade com 3.2.3) ainda pode falhar no critério 3.2.4 se seus links forem rotulados de forma diferente entre páginas. Trate ambos os critérios explicitamente no seu processo de QA.

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 para uma ampla gama de serviços digitais públicos e privados. A Circular exige conformidade com padrões de acessibilidade reconhecidos internacionalmente — na prática, alinhando-se às WCAG 2.2 Nível AA — e vincula essa conformidade ao Logotipo de Acessibilidade (Erişilebilirlik Logosu) emitido pelo Ministério da Família e Serviços Sociais (Aile ve Sosyal Hizmetler Bakanlığı).

O critério 3.2.4 das WCAG, Identificação consistente, é um critério de Nível AA, o que significa que é um requisito obrigatório — não uma recomendação consultiva — para organizações que buscam obter ou manter o Erişilebilirlik Logosu. A falta de implementação de identificação consistente em um serviço digital impedirá a conformidade total com o nível AA e, consequentemente, a elegibilidade para o logotipo.

A Circular abrange explicitamente os seguintes tipos de entidades, todas as quais devem tratar do critério 3.2.4 das WCAG em suas interfaces web e móveis: instituições públicas e órgãos governamentais; bancos e prestadores de serviços financeiros; hospitais e plataformas de saúde; operadoras de telecomunicações com 200.000 ou mais assinantes; plataformas de e-commerce; agências de viagem e serviços de reserva; empresas privadas de transporte; e escolas privadas autorizadas pelo Ministério da Educação Nacional (Milli Eğitim Bakanlığı).

Para essas organizações, a implicação prática é significativa. Grandes sites institucionais — como o portal de internet banking de um banco, o sistema de agendamento de consultas de um hospital ou o sistema de informações estudantis de uma universidade — normalmente abrangem centenas de páginas e são construídos por várias equipes de desenvolvimento ao longo de muitos anos. Rotulagem inconsistente de controles repetidos (botões de ação de conta, barras de busca, ícones de navegação) nessas páginas é um modo de falha comum e facilmente negligenciado. Programas de conformidade devem incluir auditorias de consistência entre páginas como uma fase de teste dedicada, não apenas varreduras automatizadas de páginas individuais.

Organizações turcas que buscam o Erişilebilirlik Logosu devem integrar verificações do critério 3.2.4 das WCAG na governança de seus sistemas de design, fluxos de trabalho de gerenciamento de conteúdo e pipelines de QA. Especificamente, cada componente reutilizável de interface deve ter seu nome acessível definido como uma constante não editável no nível do sistema de design, com chaves de tradução gerenciadas centralmente para garantir que o turco e quaisquer outras variantes de idioma permaneçam consistentes em todas as páginas e templates em que o componente aparece.