Craft

Link text that survives getting skimmed

The screen reader test nobody runs

Pull up your site's link list—the thing a screen reader user can summon to jump between targets. Now read only the link text, no surrounding sentences. If half of them say "click here," "learn more," or "read more," you've built a navigation system that requires vision and context to parse. That's not an accessibility edge case. That's broken.

Sighted scanners do the same thing. They hop from blue text to blue text looking for the path forward. When your anchor says "here" or "this article," they have to backtrack and reconstruct meaning from prose they already skipped. You're taxing working memory for no reason.

Front-load the noun

The person skimming doesn't read left to right through your link. They fixate on the first word, maybe two. "Documentation for API endpoints" scans faster than "API endpoint documentation" because "documentation" is the category they're hunting for. "Pricing for enterprise plans" beats "enterprise plan pricing" for the same reason.

This isn't about keyword density or SEO. It's about the [cognitive load of interface copy](/posts/navigation-labels-are-interface-copy-not-branding) when someone's trying to get somewhere. The first word is a flag. Make it the right flag.

Describe the destination, not the journey

"Click here to download the PDF" wastes four words. "Download the Q3 financial report (PDF)" tells me what I'm getting and what format I'm committing to before I click. The second version works in a link list. The first version is decorative fluff that assumes I'm reading sentences in order.

Same with "Learn more about our refund policy." Just write "Refund policy." If the page is good, I'll learn more when I get there. If it's not, lying in the link text won't fix it.

Avoid verb phrases that mean nothing

"Explore our solutions." "Discover new features." "See how we help." These are marketing placeholders pretending to be navigation. They don't describe a destination. They describe a vague aspiration. When you strip the sentence around them, they collapse into noise.

Replace "Explore our content production workflow" with "Content production workflow." You lose nothing. The verb "explore" wasn't doing work—it was inflating word count and slowing comprehension. If you need a verb, pick one that specifies the action: "Download workflow template," "Compare production tools," "Schedule a workflow audit."

Test it by breaking context

Open your draft in the CMS. Highlight every link. Read them in sequence without the surrounding text. If you can't tell where each one goes, rewrite the anchor. This takes sixty seconds per page and catches the majority of accessibility failures before you publish.

You can also sort your site's links alphabetically in a spreadsheet. Duplicate anchors that point to different pages are a warning sign—either you're relying on context to disambiguate, or you're making people guess. Both are fixable with more specific text.

When to keep the sentence structure

Sometimes the surrounding sentence carries meaning you can't strip out. "Submit your application by March 15" works better than "application submission" if the deadline is the point. "Request a refund within 30 days" beats "refund request form" if the time limit is critical.

The rule isn't "never use verbs" or "always front-load nouns." The rule is: does this anchor text work when read in isolation? If not, you're assuming people read the way you write. They don't.

The production habit

Before you publish, run the link list test. Most CMS platforms and content audits tools will generate one automatically. If yours doesn't, a browser extension or a quick DOM script will pull every `<a>` element's inner text into a list. Read that list. If you have to guess where a link goes, your visitors will guess too.

This habit pairs with [field-level help text](/posts/field-level-help-text-that-prevents-mistakes) and [preview mode discipline](/posts/preview-mode-is-for-checking-your-work-not-doing-it). It's a checkpoint that takes less time than arguing about tone, and it prevents more usability failures than a voice and tone guide ever will.

← All posts