WCAG 2.4.4: Finalidade do link (no contexto)

O que Esta Regra Significa

WCAG 2.4.4 — Finalidade do Link (No Contexto) — é um critério de sucesso de Nível A sob o princípio Operável. Ele estabelece que a finalidade de cada link deve ser determinável apenas a partir do texto do link, ou a partir do texto do link combinado com seu contexto de link determinado programaticamente. Se nenhum dos dois for suficiente, o link falha neste critério.

A expressão "contexto de link determinado programaticamente" é cuidadosamente definida pelas WCAG. Ela se refere a informações que podem ser derivadas da mesma frase, parágrafo, item de lista ou célula de tabela que o link, ou do cabeçalho que precede uma seção que contém o link. Também inclui contexto exposto por meio de relacionamentos ARIA, como aria-labelledby ou aria-describedby. Criticamente, esse contexto deve estar disponível de forma programática — o que significa que tecnologias assistivas podem lê-lo automaticamente — e não apenas ser sugerido visualmente para usuários videntes.

Em termos práticos, os seguintes elementos e atributos HTML são diretamente afetados por este critério: elementos âncora <a href>, elementos <area> em mapas de imagem, elementos <button> que disparam navegação, elementos estilizados ou programados para se comportar como links usando papéis ARIA como role='link', e elementos SVG <a>. O nome acessível do link — calculado a partir de seu texto interno, aria-label, aria-labelledby ou de um atributo alt em uma imagem filha — é o principal veículo para comunicar a finalidade.

O que conta como aprovação: Um link é aprovado se a pessoa usuária consegue determinar seu destino ou função sem contexto adicional (por exemplo, "Baixar o Relatório Anual 2024 em PDF"), ou se o contexto programático ao redor torna a finalidade clara (por exemplo, um link "Leia mais" dentro de um <li> que começa com o título do artigo). O texto do link não precisa ser globalmente único em toda a página; ele só precisa ser inequívoco dentro de seu contexto.

O que conta como reprovação: Textos genéricos de link como "clique aqui", "leia mais", "aqui", "mais" ou "link" reprovam quando o contexto programático ao redor não desambigua o destino. Um link de imagem com um atributo alt ausente ou vazio também reprova porque o nome acessível está totalmente ausente.

Exceção oficial: As WCAG reconhecem uma exceção. Quando a finalidade do link é intencionalmente ambígua — significando que tornar a finalidade conhecida antecipadamente destruiria sua utilidade ou a do conteúdo ao redor — o critério não se aplica. Essa exceção é extremamente estreita e raramente aplicável em cenários do mundo real.

Por Que Isso Importa

Aproximadamente 2,2 bilhões de pessoas no mundo têm algum tipo de deficiência visual, de acordo com a Organização Mundial da Saúde. Entre elas, pessoas cegas que dependem de leitores de tela são as mais afetadas por textos de link ambíguos. Softwares de leitor de tela como NVDA, JAWS e VoiceOver permitem que usuários naveguem por uma página gerando uma lista de todos os links extraídos de seu contexto. Quando essa lista contém dezenas de entradas que todas dizem "leia mais" ou "clique aqui", pessoas cegas não conseguem determinar qual link leva aonde sem voltar a cada um e ler o conteúdo ao redor — um processo demorado e desorientador.

Pessoas com deficiência motora que navegam usando apenas teclado, controles por varredura ou dispositivos de rastreamento ocular também se beneficiam substancialmente. Essas pessoas frequentemente percorrem elementos interativos em sequência com a tecla Tab e dependem do rótulo do elemento em foco para decidir se devem ativá-lo. Texto de link ambíguo força etapas adicionais de navegação que aumentam a fadiga e as taxas de erro.

Pessoas com deficiências cognitivas — incluindo aquelas com transtornos de atenção, comprometimentos de memória ou baixa alfabetização — se beneficiam de textos de link claros e descritivos porque isso reduz a carga cognitiva necessária para entender a estrutura de uma página. Elas não precisam manter informações contextuais na memória de trabalho enquanto examinam os links.

Um cenário concreto do mundo real: Considere uma página de listagem de produtos de e-commerce que exibe dez produtos, cada um com um botão "Comprar agora" e um link "Saiba mais" renderizados de forma idêntica. Uma pessoa cega navegando pela lista de links ouve dez instâncias consecutivas de "Saiba mais" sem indicação de a qual produto cada link se refere. Para comprar o produto correto, ela precisa ler todo o contexto ao redor de cada link — um processo que pode levar minutos em vez de segundos. Com texto de link descritivo, como "Saiba mais sobre o Fone de Ouvido Sony WH-1000XM5", a mesma tarefa exige apenas um único gesto de navegação.

Além da acessibilidade, texto de link descritivo fornece benefícios mensuráveis de SEO. Rastreadores de mecanismos de busca usam o texto âncora como um sinal para entender o conteúdo da página de destino. Texto de link descritivo e rico em palavras-chave melhora a rastreabilidade e a indexabilidade dos recursos vinculados, contribuindo positivamente para o ranqueamento em buscas. Além disso, texto de link claro reduz taxas de rejeição e solicitações de suporte ao definir expectativas precisas antes que a navegação ocorra.

Regras Relacionadas do Axe-core

• link-name: Esta regra verifica se todo elemento <a> com um atributo href, todo elemento com role='link' e todo elemento <area> tem um nome acessível não vazio. O nome acessível é calculado por meio do cálculo padrão de nome acessível da ARIA: conteúdo de texto interno, aria-label, aria-labelledby ou o atributo alt de uma <img> filha. O Axe sinaliza uma violação quando o nome acessível calculado está vazio, contém apenas espaços em branco ou está totalmente ausente. Esta regra captura a forma mais grave de falha de 2.4.4 — links completamente sem nome — mas não consegue detectar links cujos nomes estão tecnicamente presentes, porém semanticamente sem sentido (por exemplo, "clique aqui" ou "leia mais"), porque ferramentas automatizadas não conseguem determinar a intenção a partir de strings genéricas.
• duplicate-id-aria: Esta regra verifica se nenhum par de elementos na página compartilha o mesmo atributo id quando esse id é referenciado por um atributo ARIA como aria-labelledby ou aria-describedby. IDs duplicados usados em relacionamentos ARIA fazem com que o navegador resolva a referência de forma imprevisível — normalmente para o primeiro elemento correspondente na ordem do DOM — o que pode fazer com que o nome acessível de um link seja calculado a partir do elemento errado. Por exemplo, se dois links usam aria-labelledby='product-title' e dois elementos compartilham esse ID, leitores de tela podem anunciar o nome de produto errado para um ou ambos os links, violando diretamente 2.4.4. O Axe sinaliza isso como um problema crítico porque o nome acessível resultante é pouco confiável.

É importante entender os limites dos testes automatizados para este critério. Ferramentas como axe-core podem verificar se um link tem um nome acessível, mas não podem verificar se o nome é significativo. Um link chamado "aqui" passa automaticamente na regra link-name porque a string não está vazia. É necessário julgamento humano para avaliar se texto de link genérico falha em 2.4.4. Isso torna o teste manual um complemento essencial à varredura automatizada para este critério.

Como Testar

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 uma varredura de página inteira e filtre os resultados pelas regras link-name e duplicate-id-aria. Revise cada elemento sinalizado: confirme que o nome acessível calculado está ausente ou vazio para violações de link-name e verifique se IDs duplicados estão quebrando referências de rótulo ARIA para violações de duplicate-id-aria. Observe que ser aprovado nesses testes automatizados não garante conformidade total com 2.4.4 — prossiga para as etapas manuais.
2. Revisão manual da lista de links: No NVDA com Firefox, pressione a combinação de teclas Insert+F7 para abrir a caixa de diálogo Lista de Elementos e selecione "Links". Revise cada entrada na lista isoladamente, sem contexto visual. Pergunte: é possível determinar para onde cada link leva apenas a partir de seu texto? Repita no JAWS com Chrome usando Insert+F7 para abrir a Lista de Links. No VoiceOver com Safari no macOS, pressione Control+Option+U para abrir o Rotor de Itens da Web e selecione "Links". Qualquer link cuja finalidade seja ambígua em isolamento deve ser examinado em relação ao seu contexto programático.
3. Teste de navegação por teclado: Usando apenas a tecla Tab, navegue por todos os elementos interativos da página. Cada vez que o foco parar em um link, ouça apenas o texto anunciado (não o conteúdo visual ao redor). Se você não conseguir determinar o destino do link a partir do que é anunciado, o link provavelmente falha em 2.4.4. Preste atenção especial a links compostos apenas por ícones (ícones de redes sociais, botões de seta) e links de imagem.
4. Verificação de contexto: Para links que dependem de contexto ao redor (por exemplo, "Leia mais" dentro de um item de lista), inspecione o DOM para confirmar que o texto contextual está na mesma frase, parágrafo, item de lista ou célula de tabela que o link. Contexto que é apenas visualmente adjacente, mas não associado programaticamente, não satisfaz o critério. Use as DevTools do navegador para inspecionar a árvore de acessibilidade calculada e confirmar a relação.
5. Auditoria de rótulos ARIA: Pesquise no código-fonte da página todos os usos de aria-labelledby e aria-describedby em elementos de link. Verifique se cada ID referenciado existe exatamente uma vez no documento e se o elemento referenciado contém o texto descritivo pretendido. Use o painel de árvore de acessibilidade do navegador (disponível no Chrome DevTools na aba Accessibility) para confirmar o nome calculado de cada link.

Como Corrigir

Link apenas com ícone e sem nome acessível — Incorreto

<!-- An icon link with no text and no aria-label -->
<a href='https://twitter.com/accsible'>
  <svg viewBox='0 0 24 24' width='24' height='24'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Link apenas com ícone e sem nome acessível — Correto

<!-- aria-label provides a descriptive accessible name for screen readers -->
<a href='https://twitter.com/accsible' aria-label='Accsible on Twitter'>
  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Links genéricos "Read more" em uma lista de cards — Incorreto

<!-- Multiple identical link texts with no distinguishing context -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>Read more</a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>Read more</a>
  </li>
</ul>

Links genéricos "Read more" em uma lista de cards — Correto

<!-- Option 1: Visually hidden text appended to the link -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>
      Read more
      <span class='sr-only'>about the Istanbul Accessibility Summit 2024</span>
    </a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>
      Read more
      <span class='sr-only'>about the New WCAG 2.2 Guidelines</span>
    </a>
  </li>
</ul>

<!-- Option 2: Use aria-label to override the visible text entirely -->
<a href='/events/istanbul-2024' aria-label='Read more about the Istanbul Accessibility Summit 2024'>
  Read more
</a>

Link de imagem com atributo alt vazio — Incorreto

<!-- The image has an empty alt, making the link completely unnamed -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='' />
</a>

Link de imagem com atributo alt vazio — Correto

<!-- The alt attribute on the image provides the link's accessible name -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='Accsible Overlay Widget — product details' />
</a>

aria-labelledby referenciando um ID duplicado — Incorreto

<!-- Two elements share the same ID; the second link resolves to the wrong label -->
<div>
  <span id='card-title'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title'>View</a>
</div>
<div>
  <span id='card-title'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title'>View</a>
</div>

aria-labelledby referenciando um ID duplicado — Correto

<!-- Each ID is unique; each link resolves to the correct label -->
<div>
  <span id='card-title-docs'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title-docs'>View</a>
</div>
<div>
  <span id='card-title-pricing'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title-pricing'>View</a>
</div>

Erros Comuns

• Usar "clique aqui", "aqui", "mais" ou "leia mais" como texto de link sem qualquer nome acessível suplementar via aria-label, aria-labelledby ou elementos <span> visualmente ocultos — essas strings são sem sentido quando extraídas do contexto visual por um leitor de tela.
• Adicionar um aria-label a um link que contém texto visível diferente sem garantir que o rótulo comece com a string de texto visível — isso viola a WCAG 2.5.3 (Label in Name) e causa confusão para usuários de controle por voz que tentam ativar o link falando seu nome visível.
• Definir alt='' em uma imagem que é o único conteúdo de um link, tornando o nome acessível calculado do link vazio e causando uma violação de link-name — alt vazio é correto para imagens decorativas, mas não quando a imagem é o único conteúdo de um elemento interativo.
• Aplicar aria-hidden='true' ao único nó de texto dentro de um link, o que remove o nome acessível da árvore de acessibilidade e deixa o link sem nome para usuários de leitores de tela.
• Reutilizar o mesmo valor de id em vários elementos que são referenciados por aria-labelledby em links diferentes, fazendo com que leitores de tela calculem o nome acessível errado para um ou mais links devido à resolução imprevisível de IDs.
• Envolver todo um componente de card (título, imagem, parágrafo e botão) em uma única tag <a>, o que faz com que leitores de tela leiam todo o conteúdo do card como o nome acessível do link — uma experiência verbosa e desorientadora — em vez de usar um rótulo breve e descritivo.
• Confiar exclusivamente em um tooltip de atributo title em CSS ou em um pseudo-classe :hover para fornecer contexto de link — o atributo title é exposto de forma inconsistente por leitores de tela e é totalmente inacessível para usuários apenas de teclado que não podem acionar estados de foco por hover.
• Usar a própria URL como texto de link (por exemplo, <a href='https://example.com/p?id=12345'>https://example.com/p?id=12345</a>), o que é impronunciável por leitores de tela e sem sentido para pessoas com deficiências cognitivas.
• Gerar IDs de links ou valores de atributos ARIA dinamicamente com frameworks JavaScript sem garantir unicidade — componentes React, Vue e Angular renderizados em listas frequentemente produzem IDs duplicados, a menos que estratégias explícitas de chaveamento sejam implementadas.
• Esquecer de adicionar focusable='false' a ícones SVG inline dentro de links no Internet Explorer e em versões antigas do Edge, o que faz com que o SVG receba seu próprio ponto de foco na tabulação e faz com que leitores de tela anunciem o SVG separadamente do texto do link, dividindo o cálculo do nome acessível.

Relação com as Normas 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 digital alinhados com a WCAG 2.2. A WCAG 2.4.4 Finalidade do Link (No Contexto) é um critério de Nível A, o que significa que faz parte da base obrigatória que todas as entidades abrangidas devem atingir.

A circular se aplica a um conjunto definido de tipos de entidades em ambos os setores público e privado. Instituições públicas — incluindo ministérios, agências estatais, prefeituras e universidades públicas — são obrigadas a alcançar conformidade total de Nível A em um ano a partir da publicação da circular. Entidades do setor privado abrangidas pela circular têm uma janela de conformidade de dois anos. O escopo do setor privado é amplo e inclui explicitamente plataformas de e-commerce, bancos e instituições financeiras, hospitais privados e prestadores de serviços de saúde, operadoras de telecomunicações com 200.000 ou mais assinantes, agências de viagem, empresas privadas de transporte e escolas privadas autorizadas pelo Ministério da Educação Nacional.

Para todas essas entidades, texto de link não conforme representa uma violação regulatória direta. Considere uma plataforma turca de e-commerce que exibe páginas de listagem de produtos com links repetidos "Satın Al" (Comprar Agora) ou "Devamını Oku" (Leia Mais) sem qualquer contexto programático. Uma pessoa cega que dependa de TalkBack, NVDA ou VoiceOver não conseguiria determinar a qual produto cada link se refere, constituindo uma falha de 2.4.4 e uma infração aos requisitos da circular. Da mesma forma, o portal de agendamento de consultas de um hospital público que use links de navegação compostos apenas por ícones e sem nomes acessíveis falharia tanto na regra link-name do Axe quanto no mandato da circular.

A conformidade com 2.4.4 não é apenas um item técnico de checklist. A circular sinaliza um compromisso governamental mais amplo com a inclusão digital para os aproximadamente 8,5 milhões de cidadãos com deficiência da Turquia. Para as entidades no escopo, tratar falhas de finalidade de link de forma proativa — por meio de padrões de design system, treinamento de desenvolvedores e varredura automatizada em pipelines de CI/CD — é tanto uma obrigação legal quanto um investimento sólido em usabilidade e desempenho em buscas. O não cumprimento dentro dos prazos estabelecidos pode resultar em ação regulatória pelas autoridades supervisoras relevantes designadas na circular.