Skip to main content
Beta: Front-End Checklist is currently in beta. Some issues are still being fixed. Thanks for your patience.

Use descriptive link text

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

Utilities
Quick take
Typical fix time 10 min
  • 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
Why it matters: 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.

Rule Details

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.
<!-- ❌ 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

<!-- ❌ 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>
<!-- ❌ 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>
<!-- ✅ 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.

Use with AI

Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.

Check

Verify implementation

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

Auto-fix issues

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

Learn more

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.

Review

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.

Sources

References used to support the guidance in this rule.

Further Reading

Tools and supplementary material for exploring the topic in more depth.

axe DevTools
deque.comTool

Rules that often go hand-in-hand with this one.

Fix empty and broken links

All links contain accessible text content and do not lead to broken destinations.

Accessibility
Provide accessible names for all interactive elements

Checks that interactive elements have accessible names for clear navigation.

Accessibility
Use descriptive anchor text

Checks for descriptive, keyword-rich anchor text that provides context for users and search engines.

SEO
Avoid sensory-only instructions

Instructions do not rely solely on sensory characteristics like color, shape, size, location, or sound.

Accessibility

Was this rule helpful?

Your feedback helps improve rule quality. This stays internal for now.

Loading feedback...
0 / 385