Link text should tell a reader where the link goes before they follow it. "Click here" and "read more" fail that test on their own; "Read the returns policy" passes it. WCAG 2.2 success criterion 2.4.4 and Google's link documentation arrive at the same advice from different directions: make the destination clear, keep the wording natural, and do not rely on generic words. The notes here are for content editors, site owners, SEO specialists, and developers who build card and list components.
WCAG and Google have different reasons. WCAG is about people being able to decide whether to follow a link, including people who navigate by a list of links. Google's page is about links being crawlable and understandable. Neither promises a ranking outcome, so the reason to rewrite weak links is that readers and software can use the page.
Why link text has to work alone
The WCAG test
The Understanding page for 2.4.4 Link Purpose (In Context) (Opens in a new tab) says the purpose of each link must be determinable from the link text alone, or from the link text together with its programmatically determined link context. It defines link purpose as the nature of the result obtained by activating the link. The exception covers links whose purpose would be ambiguous to users in general. The criterion sits at level A.
Its stated intent is practical: people should be able to decide whether to follow a link, and descriptive text supports navigating by a list of links and by tabbing through a page.
Which context counts
For HTML, the page describes programmatically determined context as text in the same paragraph, list item, or table cell as the link, plus the table header cell associated with that cell. It adds that screen readers can use punctuation to take context from the enclosing sentence. A visual neighbor that is not in one of those relationships, such as a heading that happens to sit above a button in a different container, does not count. Failure F63 describes exactly that case: context provided only in content unrelated to the link.
The page also states a preference about order. Because screen reader users read from top to bottom, context should come before the link, and ambiguous text works better at the end of a sentence that already names the destination.
Google's view and the accepted exception
Google's version of the same advice
The Google Search Central page on crawlable links (Opens in a new tab) describes good anchor text as descriptive, reasonably concise, and relevant to both the page it sits on and the page it points to. Its test: read the anchor text on its own, and if it does not make sense out of context, make it more descriptive. It names "click here", "read more", "website", and "article" as generic text to avoid, and warns against overly long anchor text and against forcing keywords in. Surrounding words matter too, so the whole sentence is part of the signal.
Anchor text for links from other sites is a separate subject covered in anchor text strategy for link profiles. The focus here is the readability of links on your own pages.
When ambiguity is accepted
The Understanding page gives an example: in the sentence "One of the notable exports is guava," the word guava is a link. It could lead to a definition, an export chart, or a photo, and nobody can tell until they activate it. Because it is ambiguous to users in general, the exception applies. The rule is not that every link must be fully predictable; it is that you may not make a link unclear when the page could have told readers where it leads.
Sentences that carry the link
Decide the destination first
Weak links can come from the order of writing: the sentence is finished, and a link phrase is bolted on afterwards. Reverse it. Choose the destination, then write the sentence so that its natural wording already names that destination. "For delivery details, click here" becomes "Delivery times are listed on the shipping page", with the link on "the shipping page". The link text names the target and the sentence still reads smoothly.
Google asks for natural wording and notes that surrounding words matter. A practical check follows from that: remove the link markup in your head and read the sentence. If the phrase that carried the link feels pasted in, rewrite the sentence rather than the anchor.
Link in the middle, not as an afterthought
Because the Understanding page prefers context before the link, put the explanation first and the link phrase last. "See the table of delivery times" works better than "For delivery times in a table, see here." Both are grammatical, but the second ends on the vaguest word.
Related reading lists
At the end of an article, a list of related guides should give each item its own link phrase, written as the target's topic. The page says text in the same list item counts as context, so a short sentence next to each link is allowed to help. Still write the link part so that it makes sense by itself, because a reader who lists the page's links will see only the link text.
Links in tables
The Understanding page says a table cell's text and the associated header cell provide context. That helps a pricing table whose rows each end in a "Details" link, but only if the table uses real header cells. In a layout table without headers the same "Details" links stay identical. Practical suggestion: link the cell that holds the row's name and drop the separate "Details" column.
Weak patterns and their rewrites
The common weak patterns
The table lists weak patterns and rewrites. The patterns follow WCAG and Google's guidance; the rewrites are practical suggestions.
| Weak link | Problem | Rewrite |
|---|---|---|
| Click here for details | Names an action, not a destination | View the shipping and returns terms |
| Here | Meaningless out of context | 2026 price list |
| Read more | Identical on every card | Link the card title, or tie the text to the title |
| Article | Generic word named on Google's page | A phrase naming the topic |
| Image link with empty alt | Google uses alt as anchor text | Alt text describing the destination |
Why "click" is the wrong verb
"Click" assumes a mouse. More importantly, it describes how to act, not what you get. The Understanding page defines link purpose as the result of activating the link, so the strongest text names that result: the policy, the form, the tutorial. Rewriting the sentence is easier than rewriting the link: "Click here to learn more about delivery" becomes "Delivery times are listed on the shipping page" with the link on the shipping page phrase.
Too short and too long
Google's page warns against both generic one-word text and overly long anchor text, without giving a word count. It asks for text that is reasonably concise. Practical suggestion: use a noun phrase or short verb phrase that names the destination, and avoid turning an entire sentence into a link.
Links stacked side by side
The Google page advises against placing several links next to each other and suggests spacing them out with context. A row of four links separated by commas at the bottom of an article falls under that advice. Make each one self-explanatory, separate them with words or list markup, and add a short phrase explaining why each one matters.
Image links, icons and accessible names
Image links and empty links
Google says anchor text belongs inside a crawlable a element and that empty link text is a bad practice. If the element is empty it can fall back to the title attribute, and for image links it uses the image's alt attribute as anchor text, with empty alt on an image link called a bad practice. The WCAG side names failure F89, where an image that is the only content of a link has no accessible name. Put together: a link that consists only of an image needs alt text that says where the link goes. For general image alt writing, see the readable formatting guide alongside this one.
Visible text versus accessible name
The accessible name is what assistive technology announces for the link. For a plain text link it is the visible text. Techniques such as ARIA7 and ARIA8 can set a different name, so the two can drift apart. The Link Purpose page does not set a separate rule for keeping them aligned. Practical suggestion: let the accessible name contain the visible words and add to them, so that a visible "Read more" becomes "Read more: returns policy". A person who searches the page by the visible label, or speaks it, still finds the link.
Icon plus text in one link
The page lists an icon and text combined into one link, with null alt on the icon, as an acceptable pattern. If a link contains a PDF icon and the words "Annual report", the icon gets alt="" so the name is not announced twice. An icon with no other text in the link needs a real alt value (F89).
Cards, lists and repeated labels
What a list of links sounds like
A blog index with twenty cards, each ending in "Read more", gives a screen reader user a list of twenty identical entries. The Understanding page asks for consistency in one direction and distinction in the other: links with the same destination should use consistent text, and links with different destinations should use different text. Twenty identical labels pointing to twenty destinations break the second part.
The same page lists a "Read more" link whose purpose comes from the surrounding paragraph among its acceptable patterns. The catch is how context is joined to the link. If the card title and the "Read more" link share a paragraph, list item, or table cell, the relationship is programmatic. If they are only near each other on the screen, it may not be.
Three ways to fix it
First, make the card title the link. The title already names the destination, so the repeated "Read more" label either disappears or stays as a decoration. Second, keep the visible "Read more" text and give it a longer accessible name. The page lists ARIA7 (aria-labelledby), ARIA8 (aria-label), and C7, which hides part of the link text with CSS, among its sufficient techniques. Third, turn the whole card into one link. That gives the link an accessible name made of everything inside it, so keep the content short and put the title first.
Practical suggestion: make the first option the default for index pages. A title link plus a decorative button tied to the title through aria-labelledby keeps the design and produces a link list full of distinct names.
| Method | Basis on the pages | Watch for |
|---|---|---|
| Title is the link | G91 and H30, descriptive link text | The title must name the destination |
| aria-labelledby to the title | ARIA7 | Keep the name consistent with visible text |
| aria-label | ARIA8 | Translation and maintenance cost |
| Visually hidden extra text | C7 | Choose a hiding method that keeps text in the page |
| Rely on paragraph context | H78 | Link and title in the same paragraph |
Same destination, same text
If an article links to the same guide twice, word both links alike. For counting and placing links, Google's page offers no ideal number but says excessive links are likely a problem and recommends linking to related resources in context with descriptive anchor text. The internal linking strategy guide covers planning.
Format links, the title attribute and new windows
Format links after a title
Another accepted pattern: related links such as PDF and mp3 following a book-title link, with the title providing the shared context. On an article page this might be a report title linked first, followed in the same list item by a PDF link.
What the title attribute can and cannot do
The page lists supplementing link text with the title attribute (H33) among its sufficient techniques, and Google says an empty a element can fall back to title. Neither statement makes title a replacement for visible descriptive text. Practical suggestion: use title for supporting detail and never leave important information only in a tooltip.
Links that open a new window
The page lists a warning before opening new windows (G201) as an advisory technique. If a link opens a new tab, say so in or next to the link text.
Navigation and utility links
Previous and next links
"Previous" and "Next" are short, but they do not name the target. Adding the destination title ("Next: Heading Structure for SEO") fixes this. WCAG and Google state no rule specific to this component, so treat it as a practical suggestion.
Page numbers
A visible "2" announces as a bare number in a list of links. Hidden text that completes the name ("Page 2") is the kind of CSS-hidden link text C7 describes, and it keeps the visible design short.
Download links
Name the file and its type: "2026 price list (PDF)". The accepted pattern of format links after a title lets shorter labels such as "PDF" follow the main link inside one list item.
Share icons
An icon-only share link is the F89 situation: the only content of the link has no accessible name. Google also calls empty alt on an image link a bad practice. Give each icon a name that states the action and target, for example "Share by email".
Menus and footers
Short menu labels such as "Pricing" or "Contact" can be perfectly clear. The problem is two different destinations sharing a label, such as two entries named "Details". The Understanding page's rule applies: different destinations, different text.
| Component | Weak label | Suggested label |
|---|---|---|
| Previous and next | Next | Next: title of the target article |
| Pagination | 2 | Visible 2, accessible name Page 2 |
| Download | Download | 2026 price list (PDF) |
| Share icon | Icon with empty alt | Share by email |
| Menu | Two entries named Details | A distinct name per destination |
Checking the result
The links-only read
List the text of every link on a page, in order, with nothing around it. Repeated read more entries, bare "here" links, and one-word generic labels show up at once. The test applies both lines of advice: the WCAG intent of navigating by a list of links, and Google's advice to read the anchor text out of context. Run it once per template and the result carries across every page that uses the template.
Links added by JavaScript
Google says JavaScript-inserted links are crawlable if they use the same a href markup, and that if JavaScript inserts the anchor text you should confirm it appears in the rendered HTML with the URL Inspection Tool. It does not recommend routerLink, span href, or onclick without an href, and it advises against javascript: URLs. A card grid drawn on the client side should be checked for this. Crawlable markup and a meaningful name are separate requirements, and a real a href element with descriptive text satisfies both.
Keeping the fix in place
Put two sentences in the style guide: link text names the destination when read alone, and the same destination gets the same text while different destinations get different text. Add a card template where the title is the link and the visible button label is tied to it. Making the links-only read a draft approval step catches regressions before publishing.
Where to start: decision rule and checklist
Decision rule: where to start
You do not need to rewrite every link on the site at once. Start with templates, because one card component can generate hundreds of links. Next, repair image-only links, which have no name at all and carry the highest risk (F89, Google's empty alt warning). Third, rewrite article-body links built on "click", "here", and "read more". Last, leave links whose purpose is clear from the same paragraph, list item, or table cell, since the Understanding page treats those as acceptable.
The order follows risk and reach: a link that cannot be named or understood (F63) comes before one that is clear from context.
Checklist
- Does each link, read alone, name its destination?
- Are generic words such as click here, read more, website, and article gone?
- Do links to the same place share text, and links to different places differ?
- Does every card link have programmatic context: a title link, aria-labelledby, or a shared paragraph?
- Do image-only links have alt text describing the target?
- Is the anchor text natural rather than stuffed with keywords?
- Are adjacent links separated by context?
- Does the accessible name contain the visible words?
- Do links that open a new tab say so?
A worked example and who owns the fix
Example scenario: a hardware store's product grid
Example scenario: an online hardware store lists product cards with a thumbnail, a name, and a "View" button. The thumbnail and the button are separate links to the same product, and the thumbnail has empty alt. On a category page with twenty-four products, a screen reader's link list reads "View" twenty-four times plus twenty-four unnamed image links.
The repair: the product name becomes the single link. The thumbnail sits inside that link with empty alt, since the link is already named by the product name nearby in the same link. The "View" button keeps its look but takes its accessible name from the product name through aria-labelledby. Three links to one destination become one named link, and the link list shows twenty-four distinct product names. The change lives in the card template, so every category page improves together.
Measuring progress
Three counts show whether the cleanup is finished: generic phrases left in the link list test, image-only links with no name, and pairs of links with the same text and different destinations. Keep them per template. They measure quality, not rankings; any traffic effect needs separate measurement and is not guaranteed.
Who owns what
Editors own the wording of links inside article text. Developers own links produced by components. Give both the same rule in the style guide: read alone, a link names its destination. Heading outlines and list formatting support the same readability; see the heading structure guide.
Practical suggestion for component design: decide where the link's accessible name comes from before building the card. If the title field is required and the button text is not editable per card, authors cannot produce a repeated label by accident. Write the answer in the component documentation so later changes keep the rule.
Currency
The techniques and rules above follow the WCAG 2.2 Understanding page and Google's documentation as published. Both can change, so check the current pages before applying them. No rewrite carries a ranking promise.
Frequently Asked Questions
Is a read more link a WCAG failure?
No. The Link Purpose page lists a read more link whose purpose comes from the paragraph context among acceptable patterns. Context should come before the link where possible, and it must be programmatically determinable.
What does Google say about generic anchor text?
Google's page names click here, read more, website, and article as generic text to avoid. It contains no statement about a ranking effect.
How long should link text be?
The page gives no number. It asks for anchor text that is descriptive and reasonably concise, and warns against overly long anchor text.
Why does alt text matter on an image link?
Google uses the alt attribute of an image link as anchor text and calls empty alt a bad practice. WCAG lists an image-only link with no accessible name as failure F89.
Is aria-label enough on its own?
ARIA8 is listed among sufficient techniques, but the pages set no separate rule for matching it to visible text. As a practical suggestion, include the visible words in the accessible name.
Should two links to the same page use the same text?
According to the Understanding page, links with the same destination should use consistent text and links with different destinations should use different text.
Can the title attribute replace visible link text?
No. H33 supplements link text and Google may fall back to title on an empty element, but neither replaces visible descriptive text. That is a practical suggestion.
Conclusion
A link should name its destination when read alone. A "read more" link can pass WCAG when its paragraph context is programmatic, but on card grids it is safer to link the title, use aria-labelledby, or both. Give image-only links alt text, match text to destination consistently, and fix templates before individual pages. The rules can change, so check the current pages before applying them.
If you want help rewriting link text across articles and category pages, you can look at the content writing service at Akua Adforce.
Post a comment
Please log in to leave a comment. Login