2.4.4 Link Purpose (In Context)

Screen reader users routinely navigate by pulling up a list of every link on the page and reading it out of visual context. Ten links that all announce as "Read more" tell that user nothing: which article, which product, which policy? The same list defeats speech input users trying to say a link's name, and people with cognitive disabilities scanning for a destination. This criterion, at Level A, requires that the purpose of each link is determinable from the link text alone, or from the link text combined with its programmatically determined context.

That second clause is what makes this criterion gradeable rather than a style preference. Generic text like "Read more" can be rescued at Level A if the machine-readable context supplies the rest: text in the same sentence, the same list item, the same table cell (or an associated header cell), or an explicit ARIA relationship such as aria-labelledby or aria-describedby. Context that is merely nearby on screen, with no programmatic relationship, does not count. The only exception is a link whose purpose is ambiguous to all users, sighted or not, by design (a deliberately unlabelled mystery link, for example). The AAA sibling, SC 2.4.9 Link Purpose (Link Only), removes the context lifeline entirely; do not apply that stricter bar in a Level A or AA audit.

Passes:

• A blog index where each card is a list item containing the post title, an excerpt, and a "Read more" link: the same list item supplies the purpose at Level A.
• A "Read more" link whose aria-labelledby references both its own text and the article heading, announcing as "Read more, Understanding the audit lifecycle".
• A documents table with a "Download" link in each row, where the row header cell names the document.
• The link "annual report 2025" in running prose: the link text alone conveys the purpose.
• A native app list row exposed as one accessible element that announces "Invoices, 3 unpaid, See all" as a single name: merged semantics supply the context.

Fails:

• Ten "Read more" links in a card grid built from sibling div elements, with each card's title in a separate element and no list structure or ARIA relationship connecting them.
• A social footer with three icon links named "icon", "icon", and "icon": names exist, but none conveys a destination.
• A link whose visible text is a machine-generated URL of 120 characters of path segments and tracking parameters.
• A "click here" link where the destination is described in a callout elsewhere on the page with no programmatic relationship to the link.
• A "See all" text button in an app's section header, exposed as its own element announcing only "See all, button", with the section title in a separate node.

Not a fail under this criterion:

• An icon link with no accessible name at all: that is a missing name, graded under SC 4.1.2 for icon-font, SVG, or CSS controls (or SC 1.1.1 where the visual is an image element), not an unclear purpose here.
• A link whose accessible name omits its visible text (visible "View pricing", name "Plans"): grade the mismatch under SC 2.5.3 Label in Name.
• A "Read more" link that passes via its list item context but would fail the link-text-alone bar: that stricter bar is SC 2.4.9 at Level AAA and is out of scope in an A or AA audit.
• A section heading that is vague or unhelpful: heading quality belongs to SC 2.4.6, even when the weak heading sits above a set of links.

• Name, Role, Value, SC 4.1.2. Control naming generally lives there: a link or icon control with no accessible name at all is a 4.1.2 finding (filed by element type, per the house position). This criterion applies once a name exists and asks whether it conveys the link's purpose. One finding, one criterion; never double-count the same missing name.
• Label in Name, SC 2.5.3. That criterion compares the visible text with the accessible name for speech input users. A link can pass 2.5.3 perfectly (name matches the visible "Read more") and still fail here because "Read more" conveys no purpose; the two grade different questions.
• Headings and Labels, SC 2.4.6. The quality of headings and labels is graded there. A weak heading above a group of links is a 2.4.6 finding; a link whose own purpose cannot be determined is a 2.4.4 finding, even though the fix (better wording) often looks similar.
• SC 2.4.9 Link Purpose (Link Only). The Level AAA sibling requires the link text alone to convey the purpose, with no context rescue. Auditors who fail every "Read more" link regardless of its list item or sentence are applying 2.4.9 to a Level A criterion.

AUDITSU's audit walkthrough covers link purpose on every screen you review, with the screen reader running. The walkthrough prompts you to pull the full set of links and navigational controls (rotor links list on web and iOS, TalkBack traversal on Android), read each announced name out of visual context, and then check the programmatic context (sentence, list item, table cell, ARIA relationship, or merged native semantics) before grading. Each question records a pass, fail, or not applicable result per screen, with the announced name and its context captured as evidence, so a "ten identical Read more links" finding lands tied to the exact screen and elements.

Because the criterion applies unchanged to web content and native software under the European standard, the walkthrough asks the same questions across all three platforms and grades them to the same Level A bar.

For the full guided workflow, see the audit platform.