Link Purpose (In Context)
A link's purpose has to be clear from its own text, or from its text plus the context the code puts it in. Context here means a relationship a machine can follow, not whatever happens to sit nearby. For HTML, W3C's examples are the sentence the link is in, the paragraph, the list item, the table cell, and the header cell belonging to that cell. Text sitting visually next to a link but in a different container does not count, and supplying context that way is a documented failure of its own. So eleven 'read more' links, each inside its own card, do conform, because the card carries what the words leave out. One exception is written into the rule as well. A link whose destination is unclear to everybody, sighted readers included, satisfies it, because the point is equal access rather than better writing.
Why it matters
Links are how the web gets used, and screen reader users routinely pull up a flat list of every link on a page. Context does not follow a link into that list, which is why link text that stands on its own is worth writing even where this rule does not demand it. The stricter version exists as 2.4.9 at Level AAA, and reading the link list cold is its test rather than this one's. That is why 'click here' can pass this rule and fail the AAA one. W3C's own example, 'To advertise on this page, click here', satisfies 2.4.4 because the sentence carries what the link text leaves out. Write the destination into the link anyway, because the sentence is the thing the link list leaves behind. There is a second group this helps that rarely gets a mention. Somebody with a motion impairment who can tell from the link text that they do not want the page has been spared the keystrokes to go there and come back.
Who this rule protects
This affects screen-reader users navigating by link list, voice-control users who speak a link's visible name to follow it, people with motion impairments who need to know which links to skip, and anyone reading search results where the link text is the whole preview.
How to check it yourself
- Read each link together with the sentence, paragraph, list item or table cell it sits in. Those are the relationships W3C names for HTML, and what they have in common is that the code carries them. Text that is merely nearby does not count, however obvious it looks on screen.
- Prefer context that comes before the link rather than after it. A screen reader user reading forward meets the link first, so a description that follows it arrives too late to be much use. W3C allows it either way and says so, which makes this a note to raise rather than a finding to write.
- Find every repeated 'read more' and look at what container holds it. Each inside its own card or list item conforms. Two of them loose in the same paragraph, going to different places, does not.
- Check that icon-only links carry an accessible name. A row of social icons that all announce as 'link' is the most common version of this.
- Where two links share the same text in the same context, check they do the same job. This is the version of the failure a tool can flag, and the tool flags the addresses rather than the purposes, so read what it raises. Two different addresses can land on the same resource through a redirect, or on resources close enough that the shared wording is honest.
Failures we see most often
- Several 'read more' links inside one paragraph, pointing at different pages, with no container between them to supply the difference.
- A link whose only text is 'click here', with the destination named in a separate block the code does not connect to it. The same words inside a sentence that names the destination pass this rule, which is exactly why the finding turns on the container and not on the wording.
- Social icons that all announce as 'link', four in a row, with no name on any of them.
- An image used as the entire content of a link with no alt text, so the link has no accessible name at all and three separate rules break together.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Blind and screen reader userspeople who cannot see the screen
- Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
- Voice controlpeople who operate the page by speaking to it
How this one is tested
We list 3 ACT rules against 2.4.4. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.
- Link has non-empty accessible nameA tool can check this
- Link in context is descriptiveA tool can check this
- Links with identical accessible names and same context serve equivalent purposeA tool finds candidates, you decide
How to fix it
- Make the destination the link text. 'See our pricing' as the link beats 'click here' sitting next to the word pricing, and it costs one edit.
- Where a template has to repeat generic text, extend it for assistive technology with something like aria-label="Read more: How audits work", so the visible design stays and the link list starts making sense.
- Name every icon-only link, such as aria-label="WCAGrules on LinkedIn".
- When one item links out in several formats, name the item once and label the formats. The first link carries the title, the second says PDF, the third says mp3, and nobody hears the same title three times.
- Where an icon sits inside a link beside real text, give the icon empty alt text. The words already say where the link goes, so describing the picture as well just makes the link longer.
Step-by-step fix guides (22)
- H30: Write link text that says where the link goes
- H2: Combine adjacent image and text links into one
- H24: Add alt text to every image map area
- H33: Supplement vague link text with a title attribute
- H77: Give list links context from their list item
- H78: Give links context from their enclosing paragraph
- H79: Give table links context from cells and headers
- H80: Give links context from the heading above themAdvisory
- H81: Give nested list links context from parent items
- ARIA7: Build clear link names from nearby headings
- ARIA8: Fix vague link text with aria-label
- C7: Add hidden text to clarify short links
- SCR24: Open new windows only when the user asks
- SCR30: Let users swap in self-explanatory link text
- G53: Let the sentence around a link explain it
- G91: Write link text that states its purpose
- G189: Offer a switch to self-describing link text
- G201: Warn users before opening a new windowAdvisory
- PDF11: Tag PDF links so they are announced
- PDF13: Replace raw URLs in PDFs with descriptive text
Passes vs. fails
Passes
Each 'read more' sits inside its own article card, under its own heading, so the context names the destination even where the words repeat.
Fails
Five 'read more' links sit in a row with no card or list item around them, so nothing in the code tells a screen reader user which is which.
In audits and lawsuits
This shows up in every expert review, because a template generates 'Read more' by the dozen and nobody notices. It is cheap to fix once at the template level and tedious link by link, so our findings name the template rather than listing every instance. Two things are worth knowing when you read one. A heading above a link is an advisory technique rather than a sufficient one, so 'the heading explains it' does not settle a finding. And an image that is the only content inside a link, with no accessible name, breaks three rules at once, this one, its AAA sibling and 4.1.2, which is why we grade that above a vague-wording finding.