F63Documented failure WCAG 2.4.4 Level A Partly scanner-detectable

Do not strand link context away from the link

F63 is a documented failure under the link purpose rule, and it has the clearest test of any failure here. If the user has to leave the link to go looking for the context, the context is not programmatically determined and the failure has occurred. What counts as attached is a longer list than most people carry. The same sentence, the same paragraph, the same list item, the same table cell, the table headers associated with that cell, or an aria-label, aria-labelledby or aria-describedby on the link itself. Six carriers. Most write-ups name two of them. The list-item case decides most navigation menus and the table-header case decides most tables of links, so leaving them out changes findings. The rule has an exception as well. A link whose purpose would be unclear to everybody, a puzzle or a deliberate surprise, is not a failure, because nobody has been singled out.

How we find it in an audit

Reviewers take each ambiguous link and read it with only what is programmatically attached to it, which means walking the six carriers one at a time rather than glancing at what happens to be nearby on screen. Nearby is not the test. Attached is. Automated tools can find generic link text, more and here and read more, which produces the candidate list quickly. Everything after that is checking where the explanation lives in the markup, and whether a screen reader would ever reach it from the link.

How affected users experience it

The fastest way through a page with a screen reader is the links list, which pulls every link out of its surroundings and reads them together. A news page whose lead paragraph is in one block and whose Read more link is in the next gives that list a row saying "more", ten times over. The same thing happens in a table of links, where the description sits in one cell and the link sits in another, and the two are joined only by being next to each other on screen.

Passes vs. fails

Passes: each page names itself. Fails: identical, meaningless titles.

Passes

<tr><td>Storm closes harbor for repairs. <a href="/news/42">More on the harbor closure</a></td></tr>

Fails

<tr><td>Storm closes harbor for repairs</td></tr>
<tr><td><a href="/news/42">more</a></td></tr>

How this gets tested

The W3C publishes test rules that define what a checker looks for here.

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

The other techniques filed under this rule

22 guides on this site are filed under 2.4.4 Link Purpose (In Context). W3C documents this one as a failure of that rule, so it describes a way the rule gets broken rather than a way to pass it.

This guide is our interpretation of W3C technique F63: Failure of Success Criterion 2.4.4 due to providing link context only in content that is not related to the link. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.