Accessibility Fix Guide

How to Fix Vague Links Like "Click Here" and "Read More"

Links are one of the main ways people move through a website. They guide users to pricing pages, contact forms, product pages, resources, downloads, support articles, checkout flows, and account actions. When links are vague, duplicated, hidden, or hard to operate, users can lose context quickly and abandon the task they came to complete.

The classic bad example is "click here."

<p>To view our pricing, <a href="/pricing">click here</a>.</p>

This link technically works, but the link text does not explain the destination. A screen reader user may navigate by links and hear a list of "click here," "learn more," "read more," and "here." A sighted user scanning the page may also have to read surrounding sentences to understand each link. In both cases, the link itself is doing less work than it should.

Accessible link text should usually describe where the link goes or what it does. A clearer version of the same link looks like this:

<p><a href="/pricing">View ADA CodeFix pricing</a>.</p>

This is clearer for users and often better for SEO because the anchor text gives search engines and visitors a stronger signal about the destination. ADA CodeFix flags link issues because vague links are common, easy to fix, and important for navigation. This guide explains how to write descriptive link text, fix repeated "read more" links, handle card links, icon links, downloads, and external links, and avoid common link accessibility mistakes.

This page is informational and is not legal advice. Accessibility requirements can vary by site, organization, and jurisdiction. For legal guidance, consult qualified counsel. For accessibility conformance, combine automated scans with manual testing.

What makes a link accessible?

An accessible link should:

Be implemented as a real <a href=""> element when it navigates
Have meaningful link text or an accessible name
Be distinguishable from surrounding text
Be reachable by keyboard
Have visible focus styling
Make sense in context
Avoid surprising users about downloads, new tabs, or external destinations when relevant

A basic accessible link looks like this:

<a href="/fix/keyboard-navigation">
  Learn how to fix keyboard navigation issues
</a>

The link text describes the destination. A screen reader user navigating by links will hear something specific instead of a generic phrase, and a sighted user can scan a list of links and know exactly which one to choose.

WCAG criteria related to links

WCAG 2.4.4 — Link Purpose (In Context)

The purpose of each link should be determinable from the link text alone or from its surrounding context. In other words, users should be able to understand what a link does without guessing. This is a Level A criterion and is one of the most common reasons link text fails an accessibility audit.

WCAG 2.4.9 — Link Purpose (Link Only)

This AAA criterion goes further and asks that link purpose be identifiable from the link text alone, without relying on surrounding sentences. While not required for WCAG 2.1 AA, it is often a good practice for important calls to action, navigation links, and links inside lists where users may skim quickly.

WCAG 1.4.1 — Use of Color

Links should not rely only on color if users need to distinguish them from surrounding text. Underlines or other non-color cues help users who are colorblind or who view the page in environments where color rendering is unreliable.

WCAG 2.4.7 — Focus Visible

Keyboard users need to see when a link has focus. If your design removes the default outline without replacing it, focus on links becomes invisible and the page becomes very hard to operate by keyboard.

WCAG 2.5.3 — Label in Name

If a link has visible text, the accessible name should include that visible text. This matters for voice control users who say something like "click View pricing" and expect the link with that visible label to activate.

Common link accessibility failures

Failure 1: "Click here"

Problem:

<p>
  Our scanner checks your page for common WCAG issues.
  <a href="/scan">Click here</a> to start.
</p>

Better:

<p>
  <a href="/scan">Start a free accessibility scan</a>
  to check your page for common WCAG issues.
</p>

The better version makes the link itself meaningful. The reader does not need to absorb the surrounding sentence to understand where the link goes.

Failure 2: "Read more" repeated across cards

A blog listing may contain multiple identical links.

Problem:

<article>
  <h2>How to Fix Missing Form Labels</h2>
  <p>Missing labels make forms harder to use...</p>
  <a href="/fix/missing-form-labels">Read more</a>
</article>

<article>
  <h2>How to Fix Color Contrast Issues</h2>
  <p>Low contrast makes text hard to read...</p>
  <a href="/fix/color-contrast">Read more</a>
</article>

A screen reader link list may show two "Read more" links with no distinction between them, forcing the user to investigate each one to figure out where it goes.

Better:

<article>
  <h2 id="labels-title">How to Fix Missing Form Labels</h2>
  <p>Missing labels make forms harder to use...</p>
  <a href="/fix/missing-form-labels" aria-labelledby="labels-title">
    Read more
  </a>
</article>

Or better still, make the title the link:

<article>
  <h2>
    <a href="/fix/missing-form-labels">
      How to Fix Missing Form Labels
    </a>
  </h2>
  <p>Missing labels make forms harder to use...</p>
</article>

Making the title the link is usually cleaner. It removes the need for a separate "read more" link and avoids duplicate anchor names inside the same card.

Failure 3: Links used as buttons

A link should navigate. A button should perform an action.

Problem:

<a href="#" onclick="openModal()">Open filters</a>

Better:

<button type="button" onclick="openModal()">
  Open filters
</button>

If the control opens a modal, expands a menu, submits a form, or changes the current page state without navigating, use a button. Screen readers announce buttons and links differently, and users rely on those announcements to predict what will happen.

Failure 4: Buttons used as links

The opposite problem also happens.

Problem:

<button onclick="window.location.href='/pricing'">
  Pricing
</button>

Better:

<a href="/pricing">Pricing</a>

If the action is navigation to a URL, use a link. Users expect to be able to right-click, open in a new tab, or share the URL, which does not work with a button that simulates navigation in JavaScript.

Failure 5: Icon-only links without names

Problem:

<a href="https://twitter.com/example">
  <svg aria-hidden="true" focusable="false">...</svg>
</a>

A screen reader may announce this as an unnamed link or simply read the URL, neither of which is helpful.

Better:

<a href="https://twitter.com/example" aria-label="Follow ADA CodeFix on X">
  <svg aria-hidden="true" focusable="false">...</svg>
</a>

If the icon is accompanied by visible text, hide the SVG and let the visible text provide the accessible name:

<a href="https://www.linkedin.com/company/example">
  <svg aria-hidden="true" focusable="false">...</svg>
  Follow us on LinkedIn
</a>

Failure 6: Bare URLs as link text

Problem:

<a href="https://example.com/accessibility-report.pdf">
  https://example.com/accessibility-report.pdf
</a>

Better:

<a href="/reports/accessibility-report.pdf">
  Download the accessibility report PDF
</a>

Human-readable link text is easier to understand. A screen reader announcing a long URL character by character is slow and gives the user no useful summary of where the link goes.

How to write better link text

Good link text is specific, concise, and action-oriented when appropriate.

Instead of:

<a href="/learn/wcag-checklist">Learn more</a>

Use:

<a href="/learn/wcag-checklist">Read the WCAG 2.1 AA checklist</a>

Instead of:

<a href="/pricing">See details</a>

Use:

<a href="/pricing">Compare ADA CodeFix plans</a>

Instead of:

<a href="/fix/color-contrast">This article</a>

Use:

<a href="/fix/color-contrast">Fix color contrast issues</a>

The user should know what will happen before activating the link. That is the basic test: read the link text alone and ask whether the destination is predictable.

Card links

Cards are common in blogs, pricing pages, and resource libraries. The accessible pattern depends on the design.

Best simple pattern: link the heading

<article class="guide-card">
  <h2>
    <a href="/fix/color-contrast">
      How to Fix Color Contrast Issues
    </a>
  </h2>
  <p>Learn how to improve text, button, and UI contrast.</p>
</article>

This gives a clear link and avoids duplicate links inside the same card.

Whole-card click target

If the whole card needs to feel clickable, keep a real link inside and use CSS to expand the clickable area carefully.

<article class="guide-card">
  <h2>
    <a class="card-link" href="/fix/color-contrast">
      How to Fix Color Contrast Issues
    </a>
  </h2>
  <p>Learn how to improve text, button, and UI contrast.</p>
</article>

.guide-card {
  position: relative;
}

.card-link::after {
  content: "";
  position: absolute;
  inset: 0;
}

Be careful that expanded pseudo-element links do not block other interactive controls inside the card, such as a bookmark button or a secondary action.

Avoid nested interactive elements

Do not put buttons inside links or links inside buttons.

Bad:

<a href="/pricing" class="card">
  <h2>Pro plan</h2>
  <button>Start trial</button>
</a>

Better:

<article class="card">
  <h2><a href="/pricing">Pro plan</a></h2>
  <p>For teams that need continuous monitoring.</p>
  <a class="button-link" href="/signup">Start trial</a>
</article>

Nested interactive elements create unpredictable behavior for keyboard users and assistive technology, and they violate the HTML specification.

Links that open in a new tab

Opening links in a new tab can surprise users. If you use target="_blank", include rel="noopener noreferrer" to protect against window.opener exploits and to avoid leaking referrer information.

<a
  href="https://www.w3.org/WAI/"
  target="_blank"
  rel="noopener noreferrer"
>
  Visit W3C Web Accessibility Initiative
</a>

Whether to announce "opens in a new tab" depends on the context and site pattern. For important actions, it can be helpful:

<a
  href="https://www.w3.org/WAI/"
  target="_blank"
  rel="noopener noreferrer"
>
  Visit W3C Web Accessibility Initiative
  <span class="sr-only">(opens in a new tab)</span>
</a>

Avoid opening internal navigation links in new tabs unless there is a strong reason. Users generally expect internal links to load in the same tab so they can use the browser back button to return.

Download links

If a link downloads a file, tell users what they are getting.

<a href="/downloads/accessibility-checklist.pdf">
  Download the accessibility checklist PDF
</a>

Even better if you know the file size:

<a href="/downloads/accessibility-checklist.pdf">
  Download the accessibility checklist PDF, 240 KB
</a>

If the file type matters, include it in the link or nearby text so users with limited data plans or older devices can decide whether to proceed.

Links and visual design

Links should be visually distinguishable from surrounding text. Underlines are the most recognizable pattern.

Bad:

.prose a {
  color: #4b5563;
  text-decoration: none;
}

Better:

.prose a {
  color: #0645ad;
  text-decoration: underline;
  text-underline-offset: 0.15em;
}

Also add focus styles:

.prose a:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 3px;
}

If you remove underlines in navigation menus, make sure the visual design still makes links obvious through spacing, weight, or other consistent cues.

How ADA CodeFix detects link issues

ADA CodeFix can flag common link accessibility problems such as:

Links with empty text
Links with vague text like "click here," "read more," or "learn more"
Repeated links with identical accessible names but different destinations
Icon-only links without accessible names
Links used as fake buttons
Buttons used as fake links
Links without visible focus states
Links that rely only on color
Images inside links with missing or empty alt text
Download links that may need clearer labels

Some link issues require human judgment. A link named "Read more" may be acceptable if programmatically associated with a heading. A scanner can flag it for review, but a developer should confirm the final accessible name and decide whether the heading link pattern would be cleaner.

Manual link review checklist

Use this checklist after making changes.

Does each link navigate to a real URL?
Does each link have meaningful text or an accessible name?
Would the link make sense in a screen reader link list?
Are repeated links distinguishable?
Are card titles linked instead of relying on generic "Read more" links?
Are icon-only links labeled?
Are download links clear about file type?
Are external and new-tab links handled consistently?
Are links visually distinguishable from body text?
Is keyboard focus visible on links?
Are fake links replaced with buttons?
Are fake buttons replaced with links?
Are nested interactive elements avoided?

A quick screen reader pass through your page's link list will often surface vague or duplicated link text faster than reading the page top to bottom.

Common mistakes to avoid

Mistake 1: Writing for the sentence, not the link

"Click here" may make sense inside a sentence, but the link itself is weak. Write the sentence so the meaningful words are the link text and the rest of the sentence supports it.

Mistake 2: Repeating "learn more" everywhere

If every card has a "learn more" link, screen reader users may get a poor link list. Link the heading or make each link unique with a phrase that describes its destination.

Mistake 3: Using ARIA labels that disagree with visible text

If visible text says "Pricing" but aria-label says "Start trial," users get conflicting information. Voice control users will try to say the visible text and the wrong control may activate. Keep visible and accessible names aligned.

Mistake 4: Making an entire complex card a link

Whole-card links can be useful, but they can also create nested interactive problems, force assistive tech to read all card content as one long link name, and prevent users from selecting text inside the card. Use heading links when possible.

Mistake 5: Hiding links with low-contrast colors and no underlines

Users need to recognize links quickly. Do not make links indistinguishable from normal body text. If the brand requires a specific color, pair it with an underline or another consistent visual cue.

Platform-specific notes

WordPress

Check blog archive cards, menu links, plugin buttons, footer links, and page-builder CTA blocks. WordPress themes often use repeated "Read more" links by default and ship buttons that are actually styled anchors. Audit the markup, not just the visual.

Shopify

Review product cards, collection filters, cart links, account links, footer links, and icon links for search, cart, and user account actions. Shopify themes commonly use icon-only links in the header that need accessible names.

Webflow

Webflow makes it easy to wrap large blocks in links. Check for nested buttons or multiple links inside a linked card, and make sure the heading or main CTA carries the meaningful link text.

React and Next.js

Use framework link components correctly, but keep semantic HTML in mind.

<Link href="/fix/color-contrast">
  How to Fix Color Contrast Issues
</Link>

For a component library, require meaningful text or an explicit label for icon links.

function IconLink({ href, label, children }) {
  return (
    <a href={href} aria-label={label}>
      {children}
    </a>
  );
}

Do not allow unlabeled icon links to pass code review. Surface the requirement in the component API so engineers cannot accidentally render a nameless link.

Final takeaway

Good link text helps everyone. It makes pages easier to scan, improves navigation for screen reader users, supports keyboard users, and gives clearer context to search engines.

The main fix is simple: replace vague links with descriptive links. Use real links for navigation, real buttons for actions, label icon-only links, avoid repeated "read more" links, and make links visually distinguishable. ADA CodeFix can help find weak link patterns and generate developer-reviewable suggestions, but a human should still review whether each link makes sense in context.

Sources

Run a free WCAG 2.1 AA scan on your site

ADA CodeFix scans your pages, identifies likely WCAG failures, and generates developer-reviewable code fixes for link text, labels, focus styles, alt text, color contrast, and more.

Scan My Site Free

Related guides

Button accessibility fixes

Distinguish buttons from links and label icon-only buttons.

Keyboard navigation fixes

Fix clickable divs, hover-only menus, and focus traps for links.

WCAG 2.4.7 Focus Visible

Keep keyboard focus visible on links and other interactive controls.

WCAG 2.1.1 Keyboard

Ensure every link and control can be reached with a keyboard.