Vague Link Text on Product Grids: What WCAG SC 2.4.4 Link Purpose Requires
A category page lists twenty products. Every card has a thumbnail, a name, a price, and a link that says “Read More” or “Shop Now.” A sighted shopper scanning the page never notices — the product name sits right above the link, so the destination is obvious. A screen-reader user pulling up a list of links on that same page hears “Shop Now, Shop Now, Shop Now” twenty times in a row, with no way to tell which one goes where.
Quick answer: WCAG SC 2.4.4 Link Purpose (In Context) (Level A) requires that “the purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context.” On a product grid, the surrounding card can supply that context — but only if it’s actually linked to the anchor in a way assistive technology can follow, not just placed nearby on the screen. Most “Read More” cards fail on that technicality, not on the visible copy.
This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question — consult qualified counsel for legal risk questions.
What the criterion actually requires
The Understanding document’s own examples make the bar clearer than the criterion text alone. One passing example: a sentence reading “There was much bloodshed during the Medieval period of history,” where “Medieval period of history” is the link — the surrounding sentence is what makes the destination clear, not the link text in isolation. Another: a page of news summaries where each is followed by a “Read more” link — acceptable because the preceding summary text supplies the context for that specific link.
There’s also a named exception worth knowing: a game with links reading “door #1,” “door #2,” and “door #3” is fine, because the ambiguity — not knowing what’s behind each door — is the intended experience for every user, not a barrier for some. That’s the only carve-out. “Shop Now” pointing at a t-shirt isn’t creating suspense; it’s just missing information.
So “Read more” and “Shop Now” aren’t automatically non-compliant patterns. The question is whether the context that disambiguates them for a sighted user is programmatically tied to the link — readable by a screen reader — or only visually adjacent to it.
Where product grids actually fail this
1. Context that’s visually near the link but not programmatically connected to it. This is the
single most common failure, and it’s WCAG Failure F63:
the product name sits in its own <h3> or <span>, the “Read More” link sits below it in its own
element, and nothing in the markup associates the two beyond CSS layout. A sighted user’s eye
connects them instantly; a screen reader announcing the links list has no such relationship to
read.
2. Image-only “view product” links with no accessible name at all. Product cards frequently
wrap the entire thumbnail in an <a> with no visible text — the image is the link. If that image
has no alt text (or an empty alt="", which is correct for genuinely decorative images but wrong
here), the link has no accessible name whatsoever. This is
Failure F89, which the SC 2.4.4
Understanding document’s own Failures list cites as failing three success criteria simultaneously —
2.4.4, 2.4.9, and 4.1.2 Name, Role, Value
— a screen reader announces nothing more useful than “link, graphic” or the image’s filename.
3. Footer and related-product link lists. The same “Learn More” or “Details” text repeated down a sidebar of related items or a footer’s policy links has the identical problem at smaller scale — fewer links, same failure mode.
The fix: tie the context to the link, not just next to it
The sufficient techniques here are G91 (providing link text that describes the purpose of the link) and H30 (the anchor-element version of the same idea) — in short, put the product name in the link itself:
<a href="/products/wireless-headphones">Wireless Headphones — Shop Now</a>That’s the most direct fix, but it changes the visible copy, which design teams often resist on a dense grid where every card is fighting for space. The standard alternative keeps “Shop Now” as the only visible text and adds the product name in a way a screen reader announces but a sighted user never sees, using Technique C7 (using CSS to hide a portion of the link text):
<a href="/products/wireless-headphones">
Shop Now<span class="sr-only"> — Wireless Headphones</span>
</a>.sr-only {
position: absolute;
width: 1px;
height: 1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
}The technical detail that matters here, and that C7’s own description is explicit about: the hidden
text has to stay in a 1-pixel box with overflow: hidden, not use display: none or
visibility: hidden. Both of those properties remove content from the accessibility tree entirely
— they hide the text from screen readers too, which silently defeats the fix while looking correct
in a code review. A pattern-library .hidden class built for toggling UI visibility is often
exactly the wrong tool reached for here.
For the image-only card link, the fix is simpler: give the wrapping anchor an accessible name,
either through descriptive alt text on the image (alt="Wireless Headphones", not
alt="product-thumbnail-04.jpg" or an empty string) or an aria-label on the anchor itself.
| Fails | Passes |
|---|---|
<a href="/p/123">Shop Now</a> with the product name in an unrelated sibling element |
<a href="/p/123">Shop Now<span class="sr-only"> — Wireless Headphones</span></a> |
<a href="/p/123"><img src="thumb.jpg" alt=""></a> (empty alt on the only content) |
<a href="/p/123"><img src="thumb.jpg" alt="Wireless Headphones"></a> |
| A footer list of five “Learn More” links to five different policy pages | Each link naming its own destination: “Learn more about shipping,” “Learn more about returns” |
The AA floor and the AAA ceiling
SC 2.4.4 is a Level A requirement, and it explicitly allows surrounding context to do the work — that’s why “Read more” under a linked news summary is fine. There’s a stricter sibling criterion, SC 2.4.9 Link Purpose (Link Only), Level AAA, that raises the bar: the link text has to identify the destination on its own, with no context needed at all. The Understanding document’s own framing is that this matters specifically for someone using a screen reader’s link-list feature — pulling up every link on the page as a flat list, stripped of surrounding paragraphs and card layout entirely. In that view, “Read More,” repeated twenty times, fails outright regardless of how well it reads in place on the page. Meeting AA (2.4.4) with programmatically-tied context is the floor; naming the product directly in the visible or hidden link text, as in the fix above, happens to clear the AAA bar too, at no extra engineering cost.
What a scanner catches here, and what needs a person
Automated tools genuinely help with part of this. axe-core and Lighthouse can both flag an anchor with no accessible name at all — the image-only link failure is a clean automated catch. What no scanner can determine is whether “Read More,” repeated across a grid, is properly disambiguated: that requires reading the actual DOM relationship between a link and its card, then checking what a screen reader’s links list sounds like with the surrounding context stripped away — the same kind of manual pass Quietramp’s screen-reader testing guide covers for other components. A tool can tell you a link has a name; only a person checking the links list can tell you the name is actually useful.
FAQ
Is “Read More” always a violation?
No. If the surrounding text a screen reader can programmatically reach — the same list item, the
same table cell, an aria-labelledby reference — actually describes the destination, it passes.
The failure is disconnected context, not the specific words “Read More.”
Does adding a title attribute fix this?
Not reliably. title attributes aren’t consistently exposed by screen readers and aren’t triggered
at all on touch devices, so they’re an unreliable supplement, not a substitute for real link text or
a properly hidden span.
What about breadcrumb links or “Load more” buttons? Those hit SC 2.4.4 too, but with different specifics — see Quietramp’s breadcrumb navigation and pagination and infinite scroll articles for those components specifically. This article covers the repeated-card-link pattern on product and category grids.
Get your product grid checked by a person, not just a parser
Quietramp’s $890 audits include a manual pass through category and search-results pages checking whether repeated link text like “Read More” or “Shop Now” is actually tied to its product in the markup — not just visually adjacent on screen. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.