Search topics
"Read more" links that all say the same thing
A row of journal cards each ends in the same "Read more" link, with the card's title outside it, and the usual quick fix, an aria-label naming the article, leaves out the words people see.
<a href="/journal/enamel-care" class="card-more">Read more</a> The problem
Screen reader users can't tell three identical "Read more" links apart, and once an aria-label renames them, voice control users can't say them.
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.
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 guide covers that failure on its own.
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.
4 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without vision Screen reader users often open a list of every link on the page, or Tab from link to link, and hear "Read more" three times with nothing to say which article each one opens, so they follow each one to find out.
- Limited manipulation Voice control users click a link by saying its words. With the aria-label, "click Read more" matches nothing, because no link's name holds those words any more, and they fall back on numbering every link on the page.
- Limited vision Under a magnifier, a card's Read more can be in view while its title is off screen above it, so the link on its own says nothing.
- Limited language, cognitive and learning abilities People who find reading hard, or who skim, look for the words that say where a link goes; "Read more" makes them read the card again to work it out.
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.
Try it
Read the screen reader’s list of links under the journal, then try the simulated voice control.
Which link in the list is about travel mugs? Then switch to Broken 2, where each link has an aria-label, and say the words on the link again.
Broken Can you fix this?
Screen reader says:
Its list of links:
- Read more
- Read more
- Read more
The fix
Add the article to each link's name after its visible words, make the title the link, or write visible words that say where it goes.
- 1A link's name says where it goes, even read alone in a list of links.
- 2The name starts with the words the link shows: add to them, never replace them.
- 3Name each card's link after its article: hidden words after Read more, the title as the link, or visible words that say where it goes.
The same Read more on every card
<div class="cards"> <div class="card"> <img src="/images/journal/enamel-mug.jpg" alt=""> <p class="card-title">Caring for enamel mugs</p> <p>A soft sponge and no scouring powder keep the enamel bright.</p> <a href="/journal/enamel-care" class="card-more">Read more</a> </div> …</div>Hidden words after Read more
<div class="cards"> <div class="card"> <img src="/images/journal/enamel-mug.jpg" alt=""> <p class="card-title">Caring for enamel mugs</p> <p>A soft sponge and no scouring powder keep the enamel bright.</p> <a href="/journal/enamel-care" class="card-more"> Read more<span class="visually-hidden"> about caring for enamel mugs</span> </a> </div> …</div>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.
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 ids per card.
All three pass 2.4.4 and 2.5.3, and all three make the links clear on their own, as 2.4.9 asks. Hidden words change nothing on screen, so they suit a design that must keep "Read more", or a theme you can only add to. Saying "click Read more" then matches every card, and Apple's Voice Control has been reported to need the whole name, so on a Mac or an iPhone the person may have to use numbers. The title as the link is the cleanest markup, one link per card named by words everyone sees, and it suits cards whose title says enough; the stretched click area brings its own care with other controls in the card. Visible words suit a design that wants a call to action on each card, and need a writer for each one. None is right for every site, so choose by what the design must keep.
Hidden text, not aria-label. If you do want an aria-label, start it with the visible words: "Read more about caring for enamel mugs". Hidden text is still the better choice: it is translated with the page, while some browser translation tools leave an aria-label in the original language, which brings the mismatch back. Use a clip-based .visually-hidden class, never display: none, which removes the words from the name too.
aria-describedby doesn't fix the list. Pointing aria-describedby at the title adds it as a description, read after "Read more, link". W3C's failure test and the Section 508 test both count a description, so the link most likely passes 2.4.4, but a screen reader's list of links shows names only, and still reads "Read more" three times.
A hidden Read more beside a heading link. A common pattern keeps the visible "Read more" but takes it out of everything: aria-hidden="true" so screen readers skip it, tabindex="-1" so Tab skips it, with the title as the real link. Screen readers then hear one link per card, but it is not a clean fix. A voice control user who says "click Read more", the words they can see, gets nothing, because speech software that works from the accessibility tree can't find a hidden link. A sighted keyboard user sees a link that Tab never reaches. Hide something from everyone or no one; if the words should stay, give them to the link, as the hidden-words fix does.
A whole card in one link. Wrapping the card in one <a> is valid HTML, but the link's name becomes everything inside the card, so the screen reader reads a paragraph, and the card can't hold any other link or button. A link on the title, stretched, avoids both.
A card title is usually a heading. A title drawn bigger and bolder than the text around it reads as a heading, and screen reader users navigate by headings. Marking it as one, at the level that fits the page, as in the title-as-link fix, helps them whichever fix you choose. See headings chosen by size, not by structure.
Every generic label is the same failure. "Learn more", "Shop now", "Details", "Click here" and "View" repeated over cards fail in the same way and take the same fixes. In a CMS or a design system, give the card component a field for the link's words, or for the hidden words after "Read more", and fill it from the article's title when an editor leaves it empty, so a new card can't publish with a bare "Read more".
A Read more that opens text in place is a button. When "Read more" shows the rest of a review or description on the same page instead of going to another one, it is a button, never a link to href="#", with aria-expanded saying whether the text is open. Name it after its item in the same way when several sit on one page. Show and hide buttons that don't say whether they are open covers the button itself.
Fixing this with an AI coding assistant? Get this guide as Markdown, or get every guide in your coding agent.
Design ideas
A row of cards can look even without saying the same thing.
Five ways to draw the way into a journal card. Picture each repeated on three cards, then Tab through them: three would still tell the cards apart in a list of links, and two would read the same on every card.
In the design file
- Write each card’s link words beside the card, as a list of links will read them.
- If the words on screen stay Read more, write the hidden words that follow them too.
- Mark which part of the card is clickable, and draw the focus ring around that part.
- Give the link words a field of their own in the card component, so every card gets its own.
Passes
Caring for enamel mugsA soft sponge keeps the enamel bright.
The title as the link, with an arrow The title, in the #1a1a1a ink at 17.40:1, is the card’s only link, and a small green arrow after it moves 4px on hover and focus, then stops. Read more can go: the arrow shows where to click, and the list of links reads each title.Rule of thumb: Move to show a change, then stop
- A pill that names the topic A soft green pill with the article’s own topic, “Care guide”, in #1d4d3f on #e3efe9, 8.14:1, filling darker on hover and focus. Every card’s pill says something different, so the row stays even in shape while the words tell the cards apart.
- Read more, finished in a quieter grey Read more stays in green on every card, and the topic follows it inside the same link in the quiet #555555, 7.46:1: “Read more on enamel care”. The row keeps its repeated label, and the eye, the list of links and voice control all get the topic.
Fails
- An arrow in a circleWCAG 2.4.4 A 40px green circle with a white arrow, 6.26:1, in the card’s corner. It shows no words, so its name is whatever the developer types, usually the same “Read more” on every card, or nothing: the list of links can’t tell the cards apart.
- The same Learn more button on every cardWCAG 2.4.4 A full-width filled pill, white on #2f6b55 at 6.26:1, saying “Learn more” on every card. It looks like the clearest call to action on the page, and in a list of links it is the same entry three times.
Verify the fix
4 checks.
Test with: Screen reader, Speech input, Keyboard, Mouse
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the shared card component or its template changes.
Limits
This is a starting pattern, not a guarantee for every application. Paths and class names in the snippets are placeholders. Speech software differs in how it matches what is said, so test with the voice control your users have. Editors can still publish a card with a vague link later, so keep link text in your publishing review. A banner made clickable with an empty link is covered in banner and image links with no name. Test the complete journey with your target assistive technology.
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.
References
- WCAG Understanding: link-purpose-in-context (opens in a new tab)
- WCAG Technique F63 (opens in a new tab)
- WCAG Technique C7 (opens in a new tab)
- WCAG Technique H80 (opens in a new tab)
- WCAG Understanding: label-in-name (opens in a new tab)
- WCAG Understanding: link-purpose-link-only (opens in a new tab)
- ictbaseline.access-board.gov: 14Links (opens in a new tab)
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.