How to Write Accessible Link Text That Makes Sense

A link is a promise about what comes next

People scan links to decide where to go. Some screen reader users open a list containing only the links on a page. Keyboard users may tab from link to link without reading every sentence. In each case, meaningful wording reduces the effort required to choose a destination.

Good link text does not need to be long. It needs enough information to distinguish the result from other choices. “Pricing plans,” “Reset your password,” and “Download the 2026 accessibility report” each set a clear expectation.

Understand the two WCAG levels for link purpose

WCAG 2.2 Success Criterion 2.4.4, Link Purpose (In Context), is Level A. It requires the purpose of each link to be determinable from the link text alone or from the text together with its programmatically determined link context, except when the purpose would be ambiguous to users in general.

Success Criterion 2.4.9, Link Purpose (Link Only), is Level AAA. It requires a mechanism that lets the purpose be identified from the link text alone, subject to the same general-ambiguity exception.

Use a simple writing formula

Most links become clearer when their wording includes the object or destination and, when useful, the action or important outcome. Add format or behavior only when it helps the reader decide.

Avoid putting an entire paragraph inside a link just to create context. Overlong links are noisy to hear and harder to distinguish. Link the concise phrase that names the destination.

Know which surrounding text can provide context

Nearby words are not automatically programmatic context. The relationship must be available to assistive technology through an accepted structure. An enclosing sentence, paragraph, or list item can often provide context. In a data table, the cell and associated headers may identify the purpose. A preceding heading can be useful in defined circumstances.

<div class="card-title">
  Beginner’s color guide
</div>
<div class="actions">
  <a href="/guide/">Read more</a>
</div>

<article>
  <h3>Beginner’s color guide</h3>
  <a href="/guide/">
    Read the beginner’s color guide
  </a>
</article>

Do not assume a checker, screen reader, or speech-input system will combine arbitrary text placed elsewhere in a card. When the link can carry the subject naturally, explicit wording is the robust option.

Fix repeated “Read more” links in card grids

A news archive may contain twelve visually distinct cards whose links all say “Read more.” Sighted readers can often infer each purpose from layout, but a list of links becomes twelve identical choices.

The simplest repair is visible, specific wording: “Read the keyboard testing guide.” If repeating the full title makes the card unnecessarily verbose, a carefully implemented accessible name can combine the visible action with the article title. Ensure the visible words remain part of the accessible name so speech-input users can still refer to what they see.

Do not add a title attribute and assume the problem is solved. Tooltips are not consistently available across touch, keyboard, magnification, and assistive-technology use. Put essential purpose in the link text or accessible name and supported context.

Use consistent names for the same result

Links that perform the same function or reach the same destination should be identified consistently. If “Account settings,” “Profile options,” and “My details” all open the same settings page, readers may reasonably expect three different places. Choose one stable name unless the surrounding task calls for a meaningful distinction.

The reverse is equally important. Identical wording should not silently lead to different destinations. Several links labeled “Privacy policy” should not point to unrelated regional documents unless the region is identified in the link or its usable context.

Use links for navigation and buttons for actions

A link normally takes the user to another location or resource. A button performs an action in the current interface, such as submitting a form, opening a menu, saving settings, or displaying a dialog. Styling a link to look like a button is acceptable when it still navigates; changing its visual shape does not change its semantic job.

<a href="/pricing/">
  View pricing plans
</a>

<button type="button">
  Show filter options
</button>

A clickable div or empty anchor requires extra scripting and accessibility work that native elements already provide. Start with the correct HTML element so keyboard behavior, roles, and expectations remain predictable.

Name image links by purpose, not appearance

When an image is the only content of a link, its text alternative supplies the link’s accessible name. Describe the destination or action. A company logo linked to the home page might use the company name as its alternative text; an image that opens a detailed product page should identify the product, not merely say “photo.”

When an icon and visible text are inside the same link and the text already communicates the purpose, the icon can usually use empty alternative text. This avoids a name such as “PDF icon Download report PDF.”

<a href="/camera/">
  <img src="camera.jpg"
       alt="Image">
</a>

<a href="/camera/">
  <img src="camera.jpg"
       alt="View the TrailCam X2">
</a>

If an image and adjacent text are separate links to the same resource, combining them into one link often removes a duplicate keyboard stop and creates one clear accessible name.

Disclose downloads and unexpected behavior when useful

Users may want to know that a link downloads a large file, opens a PDF, changes language, starts media, launches another application, or opens a new window. Include the information that materially affects the choice, either in the link or clearly associated text.

• Documents: name the document and add format and size when relevant: “Accessibility policy (PDF, 820 KB).”
• Language: identify an alternate-language resource in that language or with a clear language label.
• Email and telephone: wording such as “Email support” or “Call customer service” predicts the mechanism.
• New windows: avoid forcing them when possible. If the behavior is necessary and unexpected, warn users consistently.
• Media: indicate when following the link immediately plays audio or video.

Make links visually identifiable and operable

Descriptive wording is only one part of link accessibility. Links within paragraphs should not rely on color alone for identification. A persistent underline is the clearest conventional cue. If color alone is used in the resting state, additional WCAG conditions apply, including contrast between link and surrounding text and a non-color cue on hover or focus.

Link text also needs sufficient contrast against its background. Keyboard focus must remain visible, and focus order should follow a meaningful sequence. Provide targets with enough space to activate accurately, especially when several links sit close together. Do not remove underlines and focus outlines merely to achieve a cleaner visual style.

Audit links on the complete WordPress page

WordPress themes and blocks can add navigation, breadcrumbs, category links, author links, card grids, pagination, related posts, image links, and footer menus around the content you write. Reusable patterns can also repeat vague labels across many pages.

1. Collect every rendered link.Include theme regions, mobile navigation, overlays, cookie notices, widgets, and dynamically revealed content.
2. Read the links without surrounding prose.Mark empty, URL-only, icon-only, and generic names that are hard to distinguish.
3. Inspect accepted context.For short names, verify that the relationship is programmatically available rather than only visually nearby.
4. Compare name and destination.Find identical names going to different resources and inconsistent names for the same function.
5. Review accessible names.Check image alternatives, hidden text, aria-label, and whether visible wording remains in the computed name.
6. Test behavior.Confirm downloads, new windows, redirects, languages, and application launches match the expectation created.
7. Use keyboard and assistive technology.Tab through the page, inspect the link list, activate representative links, and verify visible focus.

The DOFIW Link Text Checker can quickly inventory names, destinations, repeated phrases, empty links, image-link alternatives, and suspicious generic text in supplied HTML.

What the Link Text Checker can—and cannot—decide

The checker analyzes HTML locally in the browser; supplied code is not uploaded to a server. It can highlight common phrases such as “click here,” list repeated names, expose URLs and targets, and flag empty or image-only links that need inspection.

A generic phrase is a review signal, not always a conformance verdict. A specific phrase can also be misleading if it points to the wrong destination. Dynamic links generated after page load may not exist in copied source HTML, so test the rendered experience as well.

Common link-text mistakes and direct fixes

• “Click here”: link the destination or task, such as “review the refund policy.”
• Repeated “Read more”: include the article or card topic in the visible or accessible link name.
• Bare URL: replace a long address with the page, organization, or resource name.
• Same words, different targets: add the distinguishing product, region, format, or purpose.
• Different words, same function: standardize repeated navigation and actions.
• Title-only clarification: move essential meaning into dependable text or an accessible name.
• Image link with empty or generic alt: describe the destination or action.
• Separate icon and text links: combine adjacent links that reach the same resource.
• Link used as a scripted button: use a native button for an interface action.
• Unexpected file or window: disclose behavior that affects the user’s decision.
• Color-only link styling: retain an underline or another persistent non-color distinction.
• Audit limited to article content: review the published theme, menus, cards, and footer.

Accessible link text checklist

Continue the DOFIW content workflow

Frequently asked questions