Link text is generic and gives no context

What is this issue?

An <a> element’s trimmed, lowercased text exactly matches one of a small set of context-free phrases (“click here,” “here,” “read more,” “learn more,” “more,” “click,” “this link,” or “link”) and has no aria-label supplying a more descriptive accessible name, the text a screen reader announces to identify an element. The link works and goes somewhere real; the problem is entirely that its name gives no indication of where.

Because the destination lives only in the words around the link, anyone encountering the link text alone (outside its sentence, outside its paragraph) has no way to predict what happens when they activate it.

Why does this matter?

A link’s whole job is to tell the user, before they click it, roughly what they’re going to get. “Click here” and “read more” fail that job identically regardless of what they point to: a pricing page, a PDF, an external site, an unsubscribe form. The user has no signal to decide whether the link is worth following without first re-reading the sentence it’s embedded in, and if the surrounding text has already scrolled off screen or was never announced, they have no signal at all.

This compounds fast on any page with more than one such link. A blog index with ten posts, each ending “Read more,” produces ten links that all say the exact same thing, indistinguishable from each other the moment they’re pulled out of their paragraphs, which is exactly what several assistive technology navigation modes do by design.

Who is affected?

• Screen reader users: most screen readers offer a dedicated links list (NVDA and JAWS: Insert+F7; VoiceOver: the Rotor) that shows every link on the page with no surrounding text, specifically to let users jump straight to navigation. A page of identical “Read more” entries makes that list useless.
• Voice control users: operate links by speaking their visible or accessible name, such as “click Read more.” When several links on one page share that exact name, voice software can’t tell which one the user means and either guesses wrong or asks the user to pick from a numbered list.
• Cognitive disabilities: users relying on link text to orient themselves while skimming a page lose that shortcut entirely when every link says the same generic thing, forcing a full re-read of surrounding text just to navigate.

What users experience

Priya uses NVDA on her Windows laptop to research vendors for a work project. She opens the site’s blog index and presses Insert+F7 to pull up NVDA’s Elements List filtered to links, expecting a scannable menu of article titles. Instead she hears “Read more, link” repeated nine times in a row with no way to tell which entry covers the topic she needs, so she closes the list and reads the entire page top to bottom instead, the exact task the links list exists to let her skip.

How do I fix it?

Rewrite the link text itself to describe the destination, so it makes sense whether it’s read in its sentence or pulled into a links list on its own. This works because the fix addresses the accessible name directly, at its source, rather than papering over a vague name with an attribute; it also benefits sighted users scanning the page quickly, and it improves how search engines and AI systems index the destination page.

When the design genuinely constrains the visible text to something short (a card layout where every “Read more” needs to stay visually identical), add aria-label on the link with the fuller, destination-specific description. This works because aria-label completely overrides the announced name for assistive technology without touching the visible text sighted users see, so the design stays intact while the accessible name becomes descriptive.

Code Examples

<p>We published a new guide to WCAG 2.2.
  <a href="/guides/wcag-2-2">Read more</a>
</p>
<a href="/pricing">Click here</a> to see our pricing.

<!-- Method 1: rewrite the visible text (preferred) -->
<p>We published a new guide to WCAG 2.2.
  <a href="/guides/wcag-2-2">Read the WCAG 2.2 guide</a>
</p>
<a href="/pricing">See our pricing</a>

<!-- Method 2: aria-label when the visible text must stay short -->
<a href="/guides/wcag-2-2" aria-label="Read the WCAG 2.2 guide">
  Read more
</a>

Both fixes give the link an accessible name that names the destination (“the WCAG 2.2 guide,” “our pricing”) instead of describing the act of clicking. Method 1 changes what everyone sees and reads; Method 2 keeps the shorter visible text a card-based design might require, while giving screen readers the same descriptive name through aria-label.

Framework Examples

A reusable card or list-item component is the most common source of this rule’s failures in component-driven UIs, since one hardcoded “Learn more” string in the component template becomes dozens of identical links the moment it’s rendered from a CMS array. Interpolate the specific item’s title into an aria-label per rendered instance instead of leaving the string static.

function ArticleCard({ article }) {
  return (
    <article>
      <h3>{article.title}</h3>
      <p>{article.summary}</p>
      <a href={article.url} aria-label={`Read more: ${article.title}`}>
        Read more
      </a>
    </article>
  );
}

The template-level fix matters here because it’s structural: without the per-instance aria-label, every card rendered from this component produces the same generic link name, and the failure scales with however many articles the CMS returns; fixing one instance by hand doesn’t fix the component.

Common Mistakes

Mistake: “The title attribute explains the link, so that’s enough.” The title attribute produces a mouse-hover tooltip in visual browsers and has inconsistent, often absent, screen reader support for being read as part of the accessible name. It’s invisible to touch and keyboard-only users entirely. Use aria-label or descriptive visible text instead.

Mistake: “The surrounding paragraph explains the link, so the link text itself doesn’t matter.” Context in the surrounding sentence only helps a user who’s already reading that sentence in order. A links list, a voice command, or a screen reader user tabbing quickly through the page never sees that paragraph; the link’s own accessible name is the only information some navigation methods ever expose.

Mistake: “Sighted users understand ‘click here’ fine because they can see where it is on the page.” This is true and irrelevant: the rule exists for the users who can’t rely on visual position, and a fix that only works for sighted users doesn’t fix the accessibility problem at all. Position on the page isn’t a substitute for a descriptive name for anyone using a screen reader, voice control, or a links list.

Mistake: “RedFlag didn’t flag this link, so the text must be fine.” RedFlag’s detector matches a fixed list of exact phrases after trimming and lowercasing: “Click Here Now,” “Learn More About Our Services,” or a link that just says “More Info” all pass the automated check by not being an exact match, even though they’re just as unhelpful out of context as the phrases the detector does catch.

How RedFlag Detects This

Custom automated: RedFlag’s own DOM detector, runs on every scan. RedFlag scans every <a> element on the page, trims and lowercases its rendered text, and flags any that exactly matches one of eight hardcoded phrases (“click here,” “here,” “read more,” “learn more,” “more,” “click,” “this link,” “link”) provided the link also has no aria-label supplying a different accessible name.

False negative: the match is exact-match only. “Click Here Now,” “Learn More About Pricing,” “Read the full guide,” or any phrasing that isn’t byte-for-byte on the list after trim/lowercase passes silently, even when it’s just as context-free as the phrases that do get flagged. False positive: a link whose visible text genuinely is just “More” (for example, a pagination control where an adjacent icon or heading already disambiguates it) can still be flagged, since the detector has no way to evaluate surrounding visual context. Manual step: read every link’s text in isolation, as if you were only seeing a links list with nothing around it, and confirm you could guess where it goes, for both flagged and unflagged links, since the detector’s exact-match list is narrower than the real problem.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
2. Pull up the links list (NVDA/JAWS: Insert+F7, then filter to Links; VoiceOver: open the Rotor and select Links).
3. Read through the list with no other page context. Each entry should make its destination clear on its own.
4. Flag any entry that’s generic, duplicated across multiple links pointing to different destinations, or that only makes sense if you already know the surrounding sentence.
5. For any flagged link, confirm whether it has visible text or an aria-label that would fix it, then verify your fix actually appears correctly in the links list afterward.

Related WCAG Success Criteria

2.4.4 Link Purpose (In Context): The purpose of each link must be determinable from the link text alone, or from the link text combined with its programmatically-determined context (the enclosing sentence, list item, or paragraph). This rule fails that requirement at its narrowest point: text with no descriptive value even with context.

The related AAA criterion, 2.4.9 Link Purpose (Link Only), is stricter still: it requires the link to make sense with no surrounding context at all, which is a higher bar than this Level A rule requires but the same underlying skill: writing a link that names its destination.

Related Issues

Link is not distinguishable from surrounding text covers a different link-purpose failure in the same neighborhood: a link that’s descriptive enough in wording but visually indistinguishable from the plain text around it.

Button or link has no accessible name is the more severe version of this problem: a link with no accessible name at all, rather than one with a name that’s merely unhelpful.

Link opens in a new tab without warning text covers a related context gap: a link whose destination is clear but whose behavior (opening a new tab) isn’t communicated before activation.

Link opens a file with no format or size warning is the same “predict what happens before you click” principle applied to file downloads instead of generic phrasing.

References

• W3C Understanding 2.4.4: Link Purpose (In Context)
• W3C Technique H30: Providing link text that describes the purpose of a link
• WebAIM: Links and Hypertext - Link Text