Last updated on September 24, 2025
Links are what make the internet the world wide web. The original idea was that the internet is a set of digital documents. The link allows you to move between them. To make them as effective as they can be, we want to make them clear in what they do. Often though, the simple link doesn’t provide a clear purpose. Let’s look at what it takes to pass 2.4.4 Link Purpose (in Context).
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, except where the purpose of the link would be ambiguous to users in general.
Let’s dissect this a little bit. “The purpose of each link can be determined from the link text alone” is pretty clear. The text node of the link explains what it does.
<a href="https://duckduckgo.com">Search Duck Duck Go</a>
Trying to make the text node this specific isn’t always easy. WCAG provides an alternative way to identifying link purpose. We get this from the context around the link.
How is context determined?
WCAG has several sufficient techniques that help us define context. The first technique to look at is G53. Here context is defined as being included in a sentence. In fact we just did that! The phrase “G53” means nothing on its own. In the context of an accessibility blog, the audience may think of WCAG, but beyond that it still is non-sensical. But when we put it in a sentence mentioning the technique, we get more information.
Now we move to the next technique, H78. While the previous technique provides more context by including the sentence, H78 builds on this. My example sentence still doesn’t provide much context. But H78 allows us to define context at the paragraph level.
But we’re not done. A list can create context. A table cell can create context if the row and column headers are properly set.
If you are careful, occasionally a heading can be context. I urge caution with this technique. It works on lists, but rarely anything else. The trick is that the list container element uses aria-labelledby to point to the heading.
<h2 id="heading">Favorite Parks</h2> <ul aria-labelledby="heading"> <li><a href="https://www.nps.gov/yell/index.htm">Yellowstone</a></li> <li><a href="https://www.nps.gov/glac/index.htm">Glacier National Park</a></li> <li><a href="https://www.dorneypark.com/">Dorney Park</a></li> <li><a href="https://mendota.madison.k12.wi.us/">The School two blocks over</a></li> </ul>
This is considered an Advisory technique. I think it works well when there is a specific semantic container like lists. Where it breaks down is when the content is in a generic or less specific semantic elements. For instance a <div> has no semantics. If a <section> doesn’t have an aria-label, it is the same as a <div>. With it, it acts more like a region. Yet a region is not specific enough in my opinion.
There is one way that I see frequently that does not provide context. This is when there is a heading followed by a paragraph, then a link below and detached from the paragraph.
I’m grabbing an add for the AirPods I saw online as an example. While the underlying code does provide the “Shop Now” link with an accessible name that meets this SC, I’m looking just at the design here. We have an image with text, bolded text, body text, and the link. I’m going to make an assumption that the “AirPods Pro 3” is a heading. That makes the rest of the text paragraphs. This doesn’t provide context for the link.
If the container was an <aside> with the heading set as the name of the aside, it might work. Even still it is a rather generic container type. There are more semantics, but are they enough? This is why the approach is considered Advisory.
Conclusion
If a link doesn’t say what it does in the text node, you can use the context to help provide the purpose. Context can be a sentence, paragraph, list, or table cell. Of course, you can always use ARIA, but that isn’t dealing with the context. Try to avoid relying on headings before a link with no other content.