How to write accessible link text

Link text is the clickable words of a link, the content of the HTML a element. Sighted readers use the sentence and layout around a link to guess where it leads. Screen reader users often skip that step: W3C's failure F84 notes that many blind people who use screen readers call up a list of the links on a page, and WebAIM advises that links should make sense out of context. The link text has to carry the meaning itself. Our WCAG 2.4.4 page covers the criterion's rules about context in depth.

What the standards ask of link text

Four W3C items frame the rule. They overlap, and they differ in strictness.

The gap between the two criteria is the point to understand. Success criterion 2.4.4 accepts context from the same sentence, paragraph, list item or table cell, so a vague link can pass Level A. Link text that stands alone is the G91 technique, which W3C lists as sufficient for both criteria. It costs a few words and is what a person browsing a list of links needs, so writing to the stricter standard is GotAlt's reading, and it is the one the rest of this guide follows.

Links go wrong often. The 2026 WebAIM Million, with data collected in February 2026, found an empty link on 46.3% of home pages and ambiguous link text such as "click here" or "more" on 15.2% of pages. W3C's Understanding document for 2.4.4 adds a benefit beyond screen readers: clear link text lets people with motion impairments skip links they are not interested in.

Eight rules for writing link text

1. Say where the link goes or what it does

Name the destination (a page, a document, a place) or the action (download, subscribe, view). W3C's technique G91 gives the model: <a href="routes.html">Current routes at Boulders Climbing Gym</a>. In our reading, a good source for the wording is the destination's own title or main heading, so the link and the page it opens agree (see page titles). If the control does something on the same page, such as opening a dialog or submitting a form, it is usually a button, and buttons vs links explains the split. Menu items, breadcrumbs and skip links are links too, and the same wording rules apply: see breadcrumbs and site navigation and skip links.

2. Read it with the sentence removed

Lift each link out of its sentence and read it alone. "Products" works. "Click for details" does not. WebAIM notes that screen reader users can get a list of every link on a page, which may be sorted alphabetically, so wording that reads clearly in a list is wording that works. Its example: "contact us" is a phrase people look for, and a link worded "how to contact us" is harder to find. In NVDA the list is the Elements List, opened with NVDA+F7, and pressing K moves between links (WebAIM's NVDA guide). Headings are another list people browse by, and the heading structure guide covers them.

3. Keep it short

WebAIM prefers "Products" to a long description of the page, and MDN's guide to creating links advises keeping link text as short as possible. None of the sources we read sets a character count. In our reading, use the fewest words that tell this link apart from every other link on the page, and link that phrase, not the whole sentence around it.

4. Leave out "link" and "click here"

WebAIM says link text does not need the word "link" because all users already know a link is a link, and MDN calls "link" or "links to" noise because screen readers announce links. "Click here" says nothing about the destination and, in our reading, assumes a mouse. MDN's example pair makes the point: a link reading "Download Firefox" is good, and a link reading "Click here" in the sentence "Click here to download Firefox" is bad.

5. Do not use the address as the text

G91 says the URI of the destination is generally not sufficiently descriptive, and MDN advises against repeating the URL in the link text. Use the name of the page or document instead.

6. Same destination, same words; different destination, different words

W3C's Understanding document calls it a best practice for links with the same destination to have consistent text, and MDN advises minimizing copies of the same text that link to different places. Three links that all read "Download" look identical in a list of links. "Download the 2024 report", "Download the 2025 report" and "Download the 2026 report" do not.

7. Say when a link is not an ordinary page

A link to a file should name the file type, and the size where it is large, so people on low-bandwidth connections can decide; MDN gives the pattern "Download the sales report (PDF, 10MB)". A link that opens a new window or tab should say so. W3C's technique G201 asks for a visible and announced warning and is advisory, and MDN notes that screen reader users may be confused by links that open in a new tab. Put the destination first and the note after it: WebAIM prefers "Products (opens in a new window)" to "Link opens in a new window: Products", because hearing the same opening for every link slows people down.

8. Name image and icon links by where they go

A link whose only content is an image takes its name from the image's alt text. If the alt is empty and nothing else names the link, W3C documents failure F89, which fails 2.4.4, 2.4.9 and 4.1.2 together, and a screen reader may use heuristics to find some text, as in W3C's example, where it announces a file name. Write alt text that gives the destination or action, such as "Search" or "View basket", not a description of the picture. WebAIM adds that a graphic link's alt text should not say "link".

When an icon and a text link lead to the same page, put them in one link and give the icon empty alt text, as W3C's technique H2 describes, so keyboard users meet one link instead of two. Our guides to alt text for icons and SVG accessibility cover the image side.

Vague link text and a rewrite

Repeated "read more" links on cards and lists

A news index, product grid or blog list often repeats one link text under every item. The page looks fine, but the list of links is a column of identical entries. These fixes run from simplest to most technical, and the order is our reading:

1. Make the item's title the link and drop the separate "read more", or merge the image link, title link and "read more" into fewer links (technique H2 above).
2. Write the item's name into the visible text, as in "Read about our returns policy". Everyone sees it, and nothing needs maintaining.
3. Point aria-labelledby at the visible headline. W3C's technique ARIA7 says the label replaces the link text unless the link's own id is in the list, and that the combined text appears in the list of links.
4. Use an aria-label that starts with the visible words. W3C's technique ARIA8 notes that the label overrides the link text and, in some assistive technologies, shows in the list of links instead of the text.

The third fix looks like this, adapted from the ARIA7 example. The name becomes "Read more Spring returns policy":

<h3 id="story-1">Spring returns policy</h3>
<p>What changed for orders placed after March.
  <a id="more-1" href="/returns/"
     aria-labelledby="more-1 story-1">Read more</a>
</p>

Keep the visible words in the name, and put them first. Success criterion 2.5.3 Label in Name (Level A) asks that the name contain the text presented visually, and W3C calls starting the name with the visible label a best practice. People who use voice control rely on the visible label in their commands, so a name that drops it can break the command.

Check it yourself

Start with the list a screen reader user sees, then use tools for the mechanical failures:

1. Read the links list. Open it with NVDA+F7 or your screen reader's equivalent, ignore the page and read the entries. Each should say where it goes. Our guide to how screen readers read a page explains the other lists.
2. Run the link text checker. It lists every link with the name a screen reader would announce and flags links with no name, generic phrases, bare URLs and the same text pointing at different destinations. Enter a page address, or paste the HTML from your browser to include links added by scripts, which an address check does not see.
3. Use the accessibility bookmarklet on the page as it renders, including pages behind a login. It reports links with no accessible name, and generic text such as "click here" or "read more" as advisory, because 2.4.4 lets the surrounding sentence supply the purpose.
4. Scan my site for free to run 16 rule-based checks, one of which flags links with no accessible name, on up to 3 pages.

None of these can tell whether a well-worded link goes where it says. A link called "Pricing" that opens a contact form needs a person to click it. Our most common accessibility errors guide shows where unnamed links sit among the other failures that tools find.

Keep it checked

A fix holds only until the next template change or batch of new posts. GotAlt checks the pages you monitor every week. It compares each image's alt text with the image itself (up to six images per page), runs its rule checks, opens monitored pages in a browser for contrast and other render-dependent checks (see what we check), and reports what changed. Plans are from $69 a month. Audit my whole site from $69/mo.