# "Read more" links that all say the same thing
Source: https://easeweb.dev/learn/read-more
Topics: Buttons and links > Read more links say what they lead to (WCAG 2.4.4, 2.5.3)
The fix: Give each card's link a name that says what it leads to and starts with the words it shows. Either add the article's title after "Read more" as visually hidden text, or make the title itself the link and drop "Read more", or replace "Read more" with visible words that say where it goes.
Test with: screen reader, speech input, keyboard, mouse
References: https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html https://www.w3.org/WAI/WCAG22/Techniques/failures/F63 https://www.w3.org/WAI/WCAG22/Techniques/css/C7 https://www.w3.org/WAI/WCAG22/Techniques/html/H80 https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-link-only.html https://ictbaseline.access-board.gov/web-baselines/14Links
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
## What happens
A homeware shop's journal shows its three latest articles as a row of cards: a photo, a bold title, a line from the article and a green "Read more" link with an arrow. Every card ends in the same link, so the row looks even and the eye always finds the way in at the same place. Someone using a screen reader opens its list of links to choose an article, and hears "Read more, Read more, Read more". Nothing says which one is about travel mugs, so they follow each in turn to find out.
A developer, told that the links all sound the same, gives each one an `aria-label` with its article's title. The list of links now reads well: "Caring for enamel mugs", "Why stoneware keeps tea hot", "Choosing a travel mug". But a voice control user looks at the card, says "click Read more", and nothing happens, because no link on the page is called that any more.
## Why it fails
WCAG 2.4.4 Link Purpose (In Context) lets a link's purpose come from its text together with its programmatically determined link context: text in the same sentence, paragraph, list item or table cell, the cell's table headers, or words tied to the link with ARIA. On these cards the title is a paragraph of its own and the link sits after it in a plain `div`, so in code the title isn't the link's context at all. W3C describes exactly this, a "Read More" link in the paragraph after the one it is about, as failure F63. Read alone, as a screen reader reads it on Tab and in its list of links, "Read more" says nothing about where it goes.
How the card is built changes the answer. Had each card been a list item, the title would be in the same list item as the link (technique H77), and the link would most likely pass 2.4.4. A real heading before the link is weaker: W3C lists reading a link with the heading before it only as an advisory technique (H80), and neither its definition of link context nor the US Section 508 baseline test names headings, though some auditors accept one. Either way, the list of links still holds three identical entries, which fails the Level AAA criterion 2.4.9 Link Purpose (Link Only).
The quick fix trades one failure for another. An `aria-label` replaces the link's text as its name, so each link now says where it goes and passes 2.4.4, but the words on screen, "Read more", are no longer in its name. WCAG 2.5.3 Label in Name (Level A) asks that the name of a control with visible words contains them, so that people can operate it by saying what they see. The [buttons and links named differently from their text](/learn/label-in-name) guide covers that failure on its own.
## Who is affected
The pattern is everywhere cards repeat: blog and news listings, product teasers, search results and help-centre tiles. "Learn more", "Shop now", "Details" and "Click here" fail in the same way.
## What automation and AI miss
axe's `link-name` rule passes every "Read more", because each has text. Whether the words around a link name its destination takes judgement, so the audit records every link with a generic name, such as "Read more", "Learn more" or 詳しくはこちら, as a lead, with the paragraph, list item, table cell, description and heading a screen reader can reach from it, and how many links share the name but go elsewhere. ANDI adds its own warning when links share a name and not an address. A person, or the audit's AI review, then decides whether the context says where each one goes. For the second Before, axe's experimental rule `label-content-name-mismatch`, which the audit runs and reports as a lead, compares the aria-label with the visible text and flags it. Asked to fix "links with the same name", an AI coding tool can write the second Before.
## Before: the same Read more on every card
```html
Caring for enamel mugs
A soft sponge and no scouring powder keep the enamel bright.
```
```css
.card-title {
font-size: 1.125rem;
font-weight: 700;
}
```
The title looks like a heading but is a paragraph, and the link is in neither paragraph, so nothing in code ties "Read more" to the article it opens. It fails 2.4.4, and every card's link is the same entry in the list of links.
## Before: an aria-label that leaves out the words on screen
```html
Caring for enamel mugs
A soft sponge and no scouring powder keep the enamel bright.
```
```css
.card-title {
font-size: 1.125rem;
font-weight: 700;
}
```
The `aria-label` becomes the name, so the link now says where it goes and passes 2.4.4. But its name doesn't contain "Read more", the words it shows, so it fails 2.5.3, and "click Read more" finds nothing.
## After: hidden words after Read more
```html
Caring for enamel mugs
A soft sponge and no scouring powder keep the enamel bright.
```
```css
.card-title {
font-size: 1.125rem;
font-weight: 700;
}
.visually-hidden {
position: absolute;
width: 1px;
height: 1px;
overflow: hidden;
clip-path: inset(50%);
white-space: nowrap;
}
```
The smallest change, and the design stays exactly as drawn. The link's name is now "Read more about caring for enamel mugs": it says where it goes in the list of links, which passes 2.4.4 and 2.4.9 (technique C7), and it starts with the words on screen, which passes 2.5.3. "Click Read more" matches all three cards, and voice control such as Dragon numbers them to choose from, as it does for any repeated label. `aria-labelledby="more-enamel title-enamel"`, listing the link's own `id` and then the title's, gives a similar name without the span, "Read more Caring for enamel mugs", at the cost of two `id`s per card.
## After: the title as the link
```html
A soft sponge and no scouring powder keep the enamel bright.
…
```
```css
.card-title {
font-size: 1.125rem;
font-weight: 700;
}
/* The title's link covers the whole card. */
.card {
position: relative;
}
.card-link::after {
content: "";
position: absolute;
inset: 0;
}
.card-link:focus-visible {
outline: none;
}
.card-link:focus-visible::after {
outline: 3px solid var(--focus-ring);
outline-offset: -3px;
}
```
"Read more" goes, and the title people already read becomes the one link on the card: its name is the title, so the list of links reads "Caring for enamel mugs", and voice control users say the title they see. It passes 2.4.4, 2.4.9 and 2.5.3, and the title is now a heading as well, so screen reader users can move from card to card by heading. The pseudo-element stretches the link's click area over the whole card; leave it out if only the title should be clickable. Any other link or button in the card, such as a Save button or a tag, needs `position: relative` and a `z-index` above the pseudo-element, or it can't be clicked.
## After: words that say where it goes
```html
Caring for enamel mugs
A soft sponge and no scouring powder keep the enamel bright.
