WCAG 2.5.3: Rótulo no Nome

O que esta regra significa

\n

WCAG 2.5.3 — Label in Name — aplica-se a qualquer componente de interface de usuário que tenha um rótulo de texto visível. O critério exige que o nome acessível desse componente corresponda exatamente ao texto do rótulo visível ou, no mínimo, contenha o texto do rótulo visível como uma substring. Isso evita uma situação em que a pessoa vê um rótulo na tela, mas sua tecnologia assistiva ou software de reconhecimento de voz reconhece um nome completamente diferente nos bastidores.

\n

O nome acessível é o nome exposto à árvore de acessibilidade e usado por leitores de tela, softwares de controle por voz e outras tecnologias assistivas. Ele pode vir de diversas fontes, incluindo o conteúdo de texto visível do elemento, um atributo aria-label, uma referência aria-labelledby, um atributo title ou um elemento <label> associado. Quando uma pessoa desenvolvedora substitui o nome acessível por algo que não inclui o texto do rótulo visível, ocorre uma incompatibilidade e o critério falha.

\n

Elementos afetados incluem qualquer componente interativo que exiba texto e também tenha um nome acessível: botões, links, campos de formulário com rótulos visíveis, itens de menu, abas, caixas de seleção, botões de opção e widgets ARIA personalizados. Elementos não interativos, como parágrafos ou títulos, não são cobertos por este critério.

\n

O que conta como aprovação: O nome acessível contém o texto do rótulo visível como uma substring contínua, ignorando espaços em branco no início e no fim. A correspondência não diferencia maiúsculas de minúsculas. Por exemplo, se um botão exibe "Search Products", um nome acessível "Search Products Now" é aprovado porque contém "Search Products". Um nome acessível "Find Products" falha porque não contém o texto visível.

\n

O que conta como falha: O nome acessível é totalmente diferente do rótulo visível, ou o nome acessível omite uma parte significativa do rótulo visível. Um botão que visualmente exibe "Buy Now" mas tem aria-label='Purchase item' falha neste critério. Da mesma forma, um link que exibe "Contact Us" mas está envolvido em um elemento com aria-label='Reach our team' também falha.

\n

Exceções oficiais definidas na WCAG: O critério não se aplica a componentes em que o rótulo é puramente simbólico ou pictográfico, sem equivalente em texto (por exemplo, um botão apenas com ícone, sem texto visível). Também não se aplica quando o texto faz parte de um elemento puramente decorativo que não carrega significado semântico. Notação matemática e cenários específicos de idioma em que a representação em texto não pode ser mapeada para uma palavra falada também são excluídos. Além disso, componentes em que o nome acessível é intencionalmente expandido com contexto adicional — desde que o texto visível ainda esteja presente dentro do nome acessível — estão conformes.

\n\n

Por que isso é importante

\n

Este critério protege principalmente pessoas que dependem de software de reconhecimento de voz, como Dragon NaturallySpeaking (agora Dragon Professional), Windows Speech Recognition ou Voice Control da Apple. Essas pessoas navegam e ativam elementos da interface falando o rótulo que veem na tela. Quando o nome acessível não corresponde ao rótulo visível, o software não consegue encontrar o elemento de destino quando a pessoa fala seu nome, tornando o controle efetivamente inalcançável sem mouse ou teclado. Para pessoas com deficiências motoras — incluindo aquelas com lesão por esforço repetitivo, distrofia muscular, paralisia cerebral ou lesões na medula espinhal — a entrada por voz é frequentemente seu meio principal ou único de operar um computador. Uma incompatibilidade em um único botão pode bloquear o acesso a todo um fluxo de trabalho.

\n

Pessoas que usam leitores de tela também são afetadas. Quando um leitor de tela anuncia um nome acessível que difere do que é visível na tela, isso cria desorientação cognitiva. Uma pessoa com visão que também usa um leitor de tela — por exemplo, alguém com baixa visão que usa feedback visual e auditivo simultaneamente — pode ouvir uma coisa sendo anunciada enquanto lê algo diferente na tela, quebrando seu modelo mental da interface.

\n

Pessoas com deficiências cognitivas se beneficiam da consistência entre o que leem e o que é falado ou anunciado. Mudanças inesperadas de nome aumentam a carga cognitiva e podem causar confusão ou erros, particularmente para pessoas com dificuldades de memória ou que estão aprendendo a usar um sistema pela primeira vez.

\n

Um cenário concreto do mundo real: Considere uma página de checkout de e-commerce com um botão que exibe visualmente o texto "Place Order". Uma pessoa desenvolvedora adiciona aria-label='Submit purchase form' para fornecer o que considera um nome mais descritivo. Uma cliente usando Dragon NaturallySpeaking diz "Click Place Order" — o Dragon analisa a árvore de acessibilidade, não encontra nenhum elemento chamado "Place Order" e não consegue ativar o botão. A cliente não consegue concluir a compra sem mudar para o controle por mouse, o que ela pode não conseguir fazer. Ela abandona a transação. Isso não é um caso hipotético de borda; é um padrão de falha comum encontrado em auditorias automatizadas em sites de varejo e bancos.

\n

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. O relatório WebAIM Million de 2023 constatou que incompatibilidades de rótulo com WCAG 2.5.3 apareceram em uma proporção significativa das páginas auditadas, muitas vezes introduzidas por ARIA bem intencionado, mas mal aplicado. Além da acessibilidade, a rotulagem consistente melhora o SEO porque rastreadores de mecanismos de busca que indexam o texto de links e botões para classificação de relevância recebem sinais mais significativos quando os nomes acessíveis se alinham com o texto visível.

\n\n

Regras relacionadas do Axe-core

\n

\n
• label-content-name-mismatch: Esta é a principal regra automatizada associada à WCAG 2.5.3. A regra verifica elementos interativos — como botões, links e papéis ARIA como role='button', role='link', role='menuitem' e role='tab' — que têm tanto um rótulo de texto visível quanto um nome acessível. Ela sinaliza qualquer elemento em que o nome acessível não contenha o texto visível como uma substring (sem diferenciar maiúsculas de minúsculas). A regra tem como alvo específico elementos em que o nome acessível é substituído por aria-label ou aria-labelledby de uma forma que diverge do texto exibido na tela. O Axe relata essas ocorrências como violações com nível de impacto "serious" porque bloqueiam diretamente pessoas que usam entrada por voz de ativar controles.
\n
• Limitações da detecção automatizada: Ferramentas automatizadas como axe-core podem detectar de forma confiável incompatibilidades quando o texto visível é renderizado como nós de texto simples dentro do elemento e o nome acessível vem de um atributo estático aria-label ou aria-labelledby. No entanto, testes manuais são necessários quando: (1) o texto visível é renderizado por meio de pseudo-elementos CSS ::before ou ::after, já que eles podem ou não ser incluídos na árvore de acessibilidade dependendo da versão do navegador e da tecnologia assistiva; (2) o rótulo é inserido dinamicamente via JavaScript após o carregamento da página; (3) o texto visível inclui ícones ou texto baseado em imagem em que o componente textual precisa ser inferido; (4) o nome acessível computado do elemento envolve cadeias complexas de aria-labelledby que concatenam vários elementos. Nesses casos, uma pessoa testadora usando um leitor de tela deve verificar o que é realmente anunciado em comparação com o que é visível.
\n

\n\n

Como testar

\n

\n
1. Varredura automatizada com axe DevTools ou Lighthouse: Instale a extensão de navegador axe DevTools (Chrome ou Firefox) ou execute uma auditoria de acessibilidade do Lighthouse no Chrome DevTools. Dispare a varredura na página totalmente renderizada — certifique-se de que conteúdo dinâmico, modais e menus expandidos estejam abertos se contiverem elementos interativos. No painel de resultados do axe, filtre pelo ID de regra label-content-name-mismatch. Cada elemento sinalizado exibirá seu nome acessível computado ao lado do texto visível, tornando a incompatibilidade imediatamente aparente. Anote o seletor do elemento e inspecione o DOM para identificar a origem da substituição do nome acessível. O Lighthouse exibirá as mesmas falhas na categoria "Accessibility" com referência à WCAG 2.5.3.
\n
2. Inspeção manual com DevTools do navegador: Abra o painel de Acessibilidade do navegador (Chrome DevTools → Elements → guia Accessibility, ou Firefox DevTools → guia Accessibility). Selecione cada elemento interativo que tenha texto visível. Verifique a seção "Computed Properties" no campo Name do elemento. Compare esse valor com o rótulo visível. Se o nome computado não contiver o texto do rótulo visível como substring, o elemento falha em 2.5.3.
\n
3. Teste com leitor de tela usando NVDA + Firefox: Abra o Firefox com o NVDA em execução. Navegue até cada elemento interativo usando a tecla Tab. Ouça o que o NVDA anuncia como nome do elemento. Observe qualquer discrepância entre o nome anunciado e o texto exibido na tela. Use a Lista de Elementos do NVDA (Insert+F7) para navegar por todos os links e botões e comparar em massa os nomes anunciados com os rótulos visuais.
\n
4. Teste com leitor de tela usando JAWS + Chrome: Abra o Chrome com o JAWS em execução. Percorra todos os controles interativos com a tecla Tab. O JAWS anunciará o nome acessível seguido do papel. Quando o nome anunciado não incluir o texto visível, registre o elemento. Além disso, use o "Browse Mode" do JAWS e o visualizador virtual para ver o nome acessível computado de cada controle.
\n
5. Teste com leitor de tela usando VoiceOver + Safari (macOS/iOS): Ative o VoiceOver (Command+F5 no macOS). Use Tab ou VO+Seta para a direita para navegar pelos elementos interativos. O VoiceOver anuncia o nome acessível de cada controle. No iOS, deslize para a direita com um dedo para percorrer os elementos e ouvir discrepâncias entre nome e rótulo.
\n
6. Teste de reconhecimento de voz com Voice Control (macOS/iOS) ou Dragon: Ative o Voice Control do macOS (System Settings → Accessibility → Voice Control). Diga "Show names" para exibir rótulos de todos os elementos interativos. Verifique se os rótulos exibidos pelo Voice Control correspondem ao texto visível na tela. Tente ativar controles falando o texto do rótulo visível — qualquer controle que não responda ao seu nome visível é uma falha de 2.5.3. Repita com Dragon NaturallySpeaking no Windows, se disponível, usando o comando "Click [label]".
\n

\n\n

Como corrigir

\n\n

Botão com aria-label que substitui o texto — Incorreto

\n

<!-- FAIL: aria-label substitui completamente o texto visível \"Search\"\n     por \"Execute query\", quebrando a entrada por voz -->\n<button aria-label='Execute query'>\n  Search\n</button>

\n\n

Botão com aria-label que substitui o texto — Correto

\n

<!-- PASS: Remova completamente o aria-label incompatível.\n     O texto visível do botão \"Search\" torna-se automaticamente seu nome acessível.\n     Pessoas que usam voz podem dizer \"Click Search\" para ativá-lo. -->\n<button>\n  Search\n</button>\n\n<!-- PASS (alternativa): Se for necessário contexto adicional,\n     garanta que o nome acessível CONTENHA o texto visível. -->\n<button aria-label='Search products'>\n  Search\n</button>

\n\n

Link com aria-labelledby apontando para texto não relacionado — Incorreto

\n

<!-- FAIL: aria-labelledby faz referência a um heading \"Our Services\"\n     mas o link exibe visualmente \"Learn more\",\n     então o nome acessível é \"Our Services\" em vez de \"Learn more\" -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' aria-labelledby='services-heading'>Learn more</a>\n</p>

\n\n

Link com aria-labelledby apontando para texto não relacionado — Correto

\n

<!-- PASS: Use aria-labelledby para concatenar o próprio texto do link com o heading.\n     O nome acessível torna-se \"Learn more Our Services\",\n     que contém o rótulo visível \"Learn more\". -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' id='learn-link' aria-labelledby='learn-link services-heading'>\n    Learn more\n  </a>\n</p>\n\n<!-- PASS (alternativa): Torne o texto visível do link autoexplicativo\n     para que nenhuma substituição seja necessária. -->\n<a href='/services'>Learn more about our services</a>

\n\n

Botão de ícone em que aria-label conflita com o texto visível — Incorreto

\n

<!-- FAIL: O botão mostra um ícone de carrinho E o texto \"Cart\".\n     O aria-label 'View shopping basket' não contém \"Cart\",\n     então pessoas que usam voz e dizem \"Click Cart\" não obtêm resposta. -->\n<button aria-label='View shopping basket'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Botão de ícone em que aria-label conflita com o texto visível — Correto

\n

<!-- PASS: O aria-label contém o texto visível \"Cart\" como substring.\n     Pessoas que usam voz podem dizer \"Click Cart\" ou \"Click View Cart\" e ambos funcionam. -->\n<button aria-label='View Cart'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>\n\n<!-- PASS (preferido): Remova o aria-label e oculte o ícone da árvore.\n     O conteúdo de texto do botão \"Cart\" torna-se diretamente o nome acessível. -->\n<button>\n  <svg aria-hidden='true' focusable='false'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Campo de formulário com rótulo visível mas aria-label incompatível — Incorreto

\n\n

(Content truncated due to token limit — please retry this article.)