Link Text

Use descriptive link text

Screen reader users navigate by listing all links—'click here' repeated 10 times tells them nothing, while descriptive links let them jump directly to relevant content.

Quick Reference

• Avoid generic text like 'click here', 'read more', 'learn more'
• Link text should describe the destination without surrounding context
• Use links for navigation to a URL, not for in-page actions
• Use aria-label when visual design requires short text
• Include file type and size for download links

Check

Review all links and verify text describes the destination. Avoid generic phrases like 'click here', 'read more', 'learn more' without additional context. Check that screen readers can understand link purpose out of context.

Fix

Replace generic link text with descriptive phrases. Use aria-label or aria-labelledby when visual design requires short text but context is needed. Ensure each link's purpose is clear from its text alone.

Explain

Explain how screen reader users often navigate by listing all links on a page, and why 'click here' repeated multiple times provides no useful information about where each link leads.

Code Review

Review the rendered markup and interactive states that affect Use descriptive link text. Flag exact elements, roles, labels, focus behavior, or keyboard interactions that violate the rule, and note how to verify the fix with browser accessibility tooling or assistive tech.

---

For full implementation details, code examples, and framework-specific guidance, see references/rule.md.

Rule page: https://frontendchecklist.io/en/rules/accessibility/link-text

Use descriptive link text

Link text clearly describes the destination or purpose without relying on surrounding context.

Priority: high · Difficulty: beginner · Time: 10 min

--- Link text should clearly describe where the link goes or what it does, without relying on surrounding context.

Code Example

<!-- ❌ Bad: Generic, meaningless out of context -->
<a href="/pricing">Click here</a>
<a href="/docs">Read more</a>
<a href="/signup">Learn more</a>

<!-- ✅ Good: Descriptive, understandable alone -->
<a href="/pricing">View pricing plans</a>
<a href="/docs">Read the documentation</a>
<a href="/signup">Create your free account</a>

Why It Matters

• Screen Reader Navigation: Users often use a shortcut to list all links on a page; descriptive text makes this list meaningful.
• Cognitive Accessibility: Clear labels help users with cognitive disabilities understand what will happen when they click a link.
• SEO: Search engines use link text (anchor text) to understand the content of the linked page.
• Context Independence: Users should be able to understand the link even if they don't read the surrounding paragraph.
• Correct Semantics: Links should navigate to another URL. If the interaction opens a menu, submits a form, or toggles UI state, use a button instead.

Links vs Buttons

<!-- ❌ Bad: button used for navigation -->
<button type="button" onclick="window.location.href='/pricing'">
  View pricing
</button>

<!-- ✅ Good: link used for navigation -->
<a href="/pricing">View pricing</a>

Common Patterns

"Read More" Links

<!-- ❌ Bad: Multiple "Read more" links -->
<article>
  <h3>Getting Started with React</h3>
  <p>Learn the basics of React...</p>
  <a href="/react-intro">Read more</a>
</article>

<!-- ✅ Good: Descriptive link text -->
<article>
  <h3>Getting Started with React</h3>
  <p>Learn the basics of React...</p>
  <a href="/react-intro">Read the React introduction guide</a>
</article>

<!-- ✅ Also good: Visually hidden expanded text -->
<article>
  <h3>Getting Started with React</h3>
  <p>Learn the basics of React...</p>
  <a href="/react-intro">
    Read more<span class="sr-only"> about Getting Started with React</span>
  </a>
</article>

Download Links

<!-- ❌ Bad: No file information -->
<a href="/report.pdf">Download</a>

<!-- ✅ Good: Includes file type and size -->
<a href="/report.pdf">Download annual report (PDF, 2.4 MB)</a>

External Links

<!-- ✅ Good: Indicate external links -->
<a href="https://github.com" target="_blank" rel="noopener noreferrer">
  View the project on GitHub (opens in new tab)
</a>

Exceptions

• Evaluate the rendered experience before treating a static-code smell as a blocker; interaction timing, browser behavior, and assistive technology output often determine severity.
• Not every secondary accessibility issue deserves equal weight; prioritize the issue that most directly blocks perception, operation, or understanding.
• Avoid adding redundant markup or ARIA solely to satisfy a rule when a simpler semantic implementation would eliminate the issue entirely.

Verification

Automated Checks

• Inspect the browser accessibility tree or accessibility pane for the relevant element, role, or accessible name.
• Run an automated accessibility checker such as axe or Lighthouse where applicable.

Manual Checks

• Test the affected UI with keyboard-only navigation and confirm the rule holds in the rendered experience.
• Re-test one representative user flow with a screen reader if this rule affects a key interaction.