Como escrever textos de link e de botão que fazem sentido fora do contexto

Uma frase como “Para ver nossos preços, clique aqui” funciona perfeitamente na página. Arrancado da frase, o link vira duas palavras que não apontam para lugar nenhum em especial, e arrancado da frase é exatamente como muita gente o encontra.

Um aviso antes de continuar: o auditor reconhece as frases vagas em inglês (“click here”, “read more”), não em português, então um rótulo como “Clique aqui” não será sinalizado. Por isso, os exemplos que descrevem o que a ferramenta detecta ficam em inglês.

Por que a frase em volta de um link desaparece

Uma lista de links é a visão que um leitor de tela oferece de todos os links de uma página de uma vez, para que o usuário pule direto para o que quer. É uma das formas mais rápidas de navegar numa página, e ela mostra cada link apenas com as próprias palavras, mais nada. Onze links com o texto “Leia mais” viram onze linhas idênticas.

Um nome acessível é o texto que a tecnologia assistiva anuncia para um link ou um controle. A ferramenta o calcula nesta ordem: um aria-label, se houver, depois aria-labelledby, depois o texto do próprio elemento, depois o texto alt de uma imagem dentro dele e, por fim, o atributo title. O que aparecer primeiro é o que a lista de links mostra e o que o controle por voz espera ouvir.

Então o trabalho não é escrever frases melhores em volta dos links. É fazer o nome acessível dar conta do recado sozinho.

Os critérios por trás da regra

Cada problema que a ferramenta aponta cita um de cinco critérios de sucesso da WCAG, o que transforma “este rótulo está vago” de opinião em algo que cabe num ticket.

Critério	Nível	O que reprova	Como a ferramenta informa
2.4.4 Link Purpose (In Context)	A	Um link sem nome acessível, ou cujo rótulo inteiro é uma expressão como “click here”, “learn more” ou “download”	Erro. Uma URL crua com mais de 30 caracteres usada como rótulo gera um aviso
2.4.9 Link Purpose (Link Only)	AAA	As mesmas palavras usadas em links que levam a lugares diferentes	Aviso
2.4.6 Headings and Labels	AA	Um botão que não nomeia nenhuma ação: “Submit”, “OK”, “Send”, “Done”	Aviso
2.5.3 Label in Name	A	Um aria-label que não contém o texto visível do botão	Erro
4.1.2 Name, Role, Value	A	Um controle sem nome acessível; um link nomeado só pelo title	Erro; aviso no caso do title

Uma nuance sobre o 2.4.4: a rigor, ele permite que a frase ou o item de lista em volta conte como contexto, e é por isso que um “Read more” pode tecnicamente passar no Nível A. A ferramenta marca esses rótulos como erro mesmo assim, porque a lista de links é justamente o lugar em que esse contexto some. O 2.4.9, o critério AAA, é o que exige que as palavras do próprio link bastem.

Audite uma página com a ferramenta

1. Abra a página que você está verificando, clique com o botão direito na área com os links, escolha Inspecionar e copie o markup do elemento nas ferramentas de desenvolvedor. Copie o markup, não o texto visível: é nos atributos aria-label que está metade dos problemas.
2. Abra o Link & button text auditor. A caixa abaixo de Paste your markup (cole o seu markup) começa com um exemplo, então clique primeiro em Clear (limpar) na barra inferior e depois cole.
3. Leia as quatro contagens no topo: Links, Controls (controles), Errors (erros) e Warnings (avisos).
4. Resolva os erros antes dos avisos. Cada problema mostra a gravidade, o critério e o nível da WCAG, a regra violada, o texto problemático, por que isso importa e uma linha que começa com “Fix:” (correção).
5. Reescreva os rótulos no seu código, cole o novo markup e repita até o painel mostrar “Every link and control here names where it goes or what it does.” (todo link e controle aqui diz aonde leva ou o que faz).
6. Clique em Copy report (copiar relatório), ou aperte a tecla C, para levar os problemas como texto puro, um bloco por problema com o respectivo critério, para um ticket ou um pull request.

O markup de exemplo, analisado

O exemplo com que a ferramenta abre tem dez linhas e reúne a maioria dos erros comuns. Ele conta 5 links e 3 controles, e encontra 4 erros e 2 avisos:

Markup	Problema	Critério
<a href="/pricing">Click here</a>	Texto do link sem sentido fora do contexto (erro)	2.4.4, A
<a href="/docs">Learn more</a>	Texto do link sem sentido fora do contexto (erro)	2.4.4, A
Dois links com o texto “Documentation”, para /help e /api	Mesmo texto de link, destinos diferentes (aviso)	2.4.9, AAA
<a href="/home"> contendo só um ícone vazio	Link sem nome acessível (erro)	2.4.4, A
<button>Submit</button>	O rótulo do controle não nomeia a ação (aviso)	2.4.6, AA
<button aria-label="Find records">Search</button>	O texto visível não está no nome acessível (erro)	2.5.3, A
<button>Delete 3 invoices</button>	Nada: ele nomeia o resultado e a quantidade	Nenhum

Os dois links “Documentation” contam como um único problema, porque o problema é o par. O botão de busca é o que as pessoas deixam passar. Ele soa bem num leitor de tela, que anuncia “Find records”. Mas quem usa controle por voz diz a palavra que está vendo, “Search”, e nada acontece, porque “Search” não está no nome acessível. Começar o rótulo pela palavra visível, como em “Search records”, atende aos dois casos.

O índice de legibilidade que premia os piores rótulos

O atalho óbvio é passar os rótulos por um verificador de legibilidade. Ele dá exatamente a resposta errada. As fórmulas de legibilidade dividem pelo número de frases e foram ajustadas em texto corrido, então uma string de duas palavras as joga para fora da escala. O Flesch–Kincaid dá a “Learn more” e “Click here” uma facilidade de leitura de 120.2, acima do topo da própria escala, e dá ao muito mais claro “Download invoice PDF” apenas 62.8.

É por isso que o auditor não mostra índice de leitura nenhum, e diz isso na página. O que dá para testar num rótulo é se ele nomeia um destino ou uma ação, e se o nome acessível dele bate com o que está na tela.

Onde as verificações param

Uma ferramenta que cita critérios só é tão boa quanto as regras que aplica, e estas têm limites que vale conhecer:

• As listas de palavras vagas comparam o rótulo inteiro, não uma expressão dentro dele. “Click here” é apontado; “Click here to compare plans” não, embora ainda faça quem ouve esperar pelas palavras úteis.
• A lista para links é mais longa que a lista para botões. Um link com o texto “Download” é erro; um botão com o texto “Download” passa, e ainda assim deveria dizer o que baixa.
• Ela não consegue dizer se um rótulo é exato, só se é específico. Um botão com o texto “Delete” que na verdade arquiva vai passar em todas as verificações.
• Ela não consegue buscar uma página a partir de uma URL. Os navegadores impedem que um site leia o HTML de outro, e não há servidor por trás da ferramenta para fazer isso no lugar dela, e é por isso que você cola o markup.

Outras formas de fazer isso

Não há um método nativo do sistema operacional para auditar textos de link. A versão manual é o mesmo teste que a lista de links aplica: leia as palavras de cada link sozinhas, numa coluna, sem a página em volta, e pergunte se você saberia aonde cada uma leva. Para botões, pergunte se o rótulo nomeia o que acontece depois do clique. É lento numa página grande, e não pega um aria-label que contradiz o texto visível, porque não dá para vê-lo sem ler o markup.

Conferindo que nada foi enviado

O markup é analisado pelo seu próprio navegador, na aba. Abra o painel Network (rede) nas ferramentas de desenvolvedor, cole um bloco de markup e observe: nenhuma requisição o leva. Desconectar da rede depois que a página carrega também funciona, e a ferramenta continua auditando.

Próximo passo

Cole uma barra de navegação ou uma grade de cards no Link & button text auditor; é ali que costumam se acumular links repetidos de “Read more”. Se os seus botões de ícone usam SVG inline, o otimizador de SVG mantém por padrão o elemento <title> de cada arquivo, em vez de removê-lo para economizar bytes.