May 12, 2026: Complex Link Text Scenarios

Meeting Date

May 12, 2026 @ 11:00 AM Central Time

Topics

This month we will delve into some of the thornier questions around link text. This topic arose from a Teams post by Sydney Flowers (requires U of I login) and comments during Jon Gunderson’s recent Web Con presentation. We plan to focus on the following 2 questions, but feel free to bring your own questions as well!

Question 1: going beyond the link text itself

When is it appropriate to use aria-label, aria-labelledby, or aria-describedby to override/extend a link’s accessible label? What about the title attribute? How does screen-reader only text fit into the picture? How do content creators handle these complex scenarios when using content management systems that don’t provide code-level access to these advanced approaches?

Some specific examples to consider:

Duplicated links (e.g. “Read more”, “Contact”, etc.) which go to different destinations depending on the heading they live under
Repeated sets of links to different versions of an item, e.g.:
- A document in several formats (e.g. PDF, Word)
- Blocks of information on a series of similar categories (e.g. maps, photos, directions for several hotels)
- A table of links to versions (e.g. PDF, Word) of a series of documents (e.g. monthly agendas, quarterly newsletters)

See the following techniques documented by the W3C:

Question 2: providing sufficient context

How do we square the guidance to provide unique link text that’s clear out of context (e.g. in a list of all links on a page) with several W3C WCAG Techniques that seem to encourage link text patterns we typically recommend against?

Some specific examples to consider:

Repeated sets of links to different versions of an item (see prior section for examples)
Non-meaningful link text (e.g. “click here”) inside a sentence that provides context for the link

See the following techniques documented by the W3C, each of which provides context for times where it’s okay to be "less" descriptive:

Join us this month to discuss best practices for link text in complicated scenarios!

Meeting Notes

Sydney Flowers: these questions came up in context of megamenu
- Example: U of I homepage, see Admissions section in main navigation
- Is nested listing sufficient context for links? E.g. two "Apply", "Cost and Aid", and "Contact" links with different destinations are listed under Undergrad Admissions and Graduate College headings, plus Apply also appears in the Utility menu at the top of the page above the site search. Additionally, on the Admissions page, these links also appear with more complete link text
- When should we use aria-label vs. change visible text?
Mark McCarthy: changing link text with aria-label could cause confusion or even make it challenging for users using voice-to-text to click the right link
- Making the links look like what their label is (or ensuring their text isn’t modified with aria-label) makes it easier/more likely for the speech-to-text software to “click” on the right link the first time
- E.g. if you say “click ‘admissions’” but the link is aria-label’ed with “apply for undergrad admissions,” it may not pick it up. Sample code:
```
<a href="#" aria-label="apply for undergrad admissions">Apply</a>
```
- Speech-to-text tools (Dragon, Siri, Voice Control, etc.) use the same kind of accessible names etc. (all that underlying stuff) screen readers do, but that’s still invisible to sighted users. So if you have a button visually labelled “check out” but aria-label’ed to be “pay now,” saying “click ‘check out’” wouldn’t click that button since its “actual” label is "pay now".
- But if the labels are close, or contain the same thing someone is saying even if not exact, some of them may be able to infer and give the option/confirmation to click what it thinks is the best match. Have found that Dragon likes things to be pretty much a 1:1 match, though.
- Tanusha Gottipati: for speech-recognition users, the accessible name must include the exact text of the visible label. The visible label text does not need to be the entire name, but it should ideally be at the beginning of the text string.
Jon Gunderson: if screen reader user pulls up list of links, will see “Apply” twice in list; won’t be able to distinguish between them
Michael McKelvey: according to the standards, links going to different destinations should have different link text, making two “Apply” links with different destinations a problem. Plus, links going to the same location should ideally have the same link text.
Tim Offenstein: SilkTide Toolbar is a great tool for finding duplicated link text.
Hadi Rangin: we have been preaching that links should be unique when pulled up in a list of links; has been rethinking whether that approach makes the most sense. aria-label causes a lot of noise.
Hadi: main use case for pulling up the list of links in a page: when you already know the link you want to reach; makes searching for it easier
Hadi: ok w/aria-describedby - extra info is only read out if user tabs to the link
Jon: this came up in presentation last month; H2L currently shows aria-describedby as part of the link text
Jon: title attribute - avoid using 🙂
- Leighton Taylor: Deque has a chart of title, anchor and aria label that was updated in 2020: Text link Accessibility: aria-label and title attribute
- MDN warns against the title attribute because of inconsistent behavior across browsers / screen readers.
- Also, keyboard-only users cannot access the title attribute (tooltip).
Kelly Delahanty: what would happen if the link text was “Apply to Graduate Programs” / “Apply to Undergrad Programs” but you used a span with a class that hides thing visually but not from screenreader to have it look like both links just say “Apply”?
- Mark: probably has same issue with voice-to-text
Brenden West: what about making each link more specific, e.g. "Apply for undergraduate admissions" and "Apply for graduate admissions"?
- Kelly: may work in this particular case, but sometimes you won’t have the room. And even in this case you’d have to also add an undergrad/graduate qualifiers to the “Cost and Aid” and “Contact” links as well, and that repetition would likely interfere with users’ ability to parse the information quickly.
- Bryan Jonker: "Extra words" also affects sighted users as well. Visual clutter is a real thing.
- Kelly: plus, there are still places where writing out complete link text isn't going to be an option. For example, dashboard tables where each row has a “View” or “Edit” link, and there’s not enough room for each link or button to say something like “View record 123456789”
- Jack Thomas: could you visually hide "record 123456789” in that case?
- Kelly, Mark: would have same speech-to-text issue mentioned before, since the sighted user would just say "click 'view' link, but there would be multiple links starting with the word 'view' and the sighted speech-to-text user wouldn't know the full accessible label of the link to reference it explicitly.
- Jack: seems there's an underlying ambiguity from having 3 links with the text "Apply" anyway - can text-to-speech be expected to select the right link to begin with?
Sydney: some resources say that as long as, in context, links make sense, they can be shorter; but same links going to different locations can’t have same link text
Lance: would aria-labelledby on links pointing to preceding heading work?
- Sydney: I believe that will still have the same speech-to-text issue that Mark was referring to earlier
Jon: recommend putting each grouping in a landmark region; when screen reader user enters the region, the region’s accessible name will be announced (e.g. “Undergraduate Admissions Apply”
- Kelly: here's information on landmark regions
  - HTML <section> element and ARIA "region" role are equivalent:
    - ```
    <section>...</section>
```
- ```
<div role="region">...</div>
```
    - Combining them:
```
<section role="region">...<section>
```
- Hadi: screen readers don’t typically tab through the page; typically use reading mode
- Michael: will that lead to too many landmarks on page?
- Hadi: adding landmarks seems reasonable in this instance; this is a situation where we’re choosing between “bad” and “worse”, not “good” and “better” ;-)
- Bryan: how to label the region? aria-label or aria-labelledby?
- Jon: use aria-labelledby pointing to the parent link inside the section; no need for the word "submenu" - aria-labelledby would just get the text "Undergrad Admissions", which is sufficient.
- Current markup in Illinois megamenu:
```
<li>
	<a>Admissions</a>
	<section aria-label="Admissions submenu">
		<ul>
			<li>
				<strong><a>Undergrad Admissions</a></strong>
				<ul>
					<li><a>Apply</a></li>
					.... more items
				</ul>
			</li>
		</ul>
		<ul>
			<li>
				<strong><a>Graduate College</a></strong>
					<li><a>Apply</a></li>
					.... more items
				</ul>
			</li>
		</ul>
	</section>
</li>
```
- This could be altered to make each column its own region (first need to inquire whether there was a reason for the outer region around the whole megamenu):
```
<li>
	<a>Admissions</a>
		<ul>
			<li>
				<strong><a>Undergrad Admissions</a></strong>
				<section aria-label="Undergrad Admissions submenu">
					<ul>
						<li><a>Apply</a></li>
						.... more items
					</ul>
				</section>
			</li>
		</ul>
		<ul>
			<li>
				<strong><a>Graduate College</a></strong>
				<section aria-label="Graduate College submenu">
					<ul>
						<li><a>Apply</a></li>
						.... more items
					</ul>
				</section>
			</li>
		</ul>
</li>
```
Michael: I also want to discuss the WCAG techniques that allow you to use text like “Read more”, going against my understanding of best practices for link text.
- Jon: these techniques come mainly from compromises between guidance document, best practices document, and conformance document. In order to get everyone on board, the standards need some flexibility in the accepted techniques. It doesn’t make best practices people happy, but it's how we get to consensus.
- Michael: well, that explains a lot. So it sounds like we can explain that those techniques are technically part of the standards, but not how we should actually be doing things.
Lance: can you jump between regions? Does that help?
- Jon: screen reader user doesn’t know regions exist until they start exploring the menu. Once they know they’re there, they can navigate easily (e.g. pressing ‘r’ to jump between regions)
- Hadi: have to be in browse mode rather than application mode to use regions
- Jon: perhaps a screen reader demo would be a good EWH topic (much agreement among participants)

Topics

Question 1: going beyond the link text itself

Question 2: providing sufficient context

Meeting Notes

Tags