[thet]

Build upon: #1298

• feat(pat-tooltip): Add content-text as source, which extracts the triggers text without markup. (source option: content-text)

From the docs:

Property	Default value	Values	Description	Type
source	title	ajax content content-text title aria-label	Select where the contents of the tooltip is taken from: ajax load the tooltip contents from the link target url or from a selector given by the href attrobite. content: tooltip contents are the tooltip elements children. content-text: trimmed text content of the trigger, including visually hidden text, displayed as plain text. title, aria-label: tooltip content is the title resp aria-label attribute value.	Mutually exclusive

[thet]

Regarding the second source option, content-text. This is the reasoning.

In summary: No big benefits, other than on devices without mouse support and thus no hoverable - pat-tooltips, you could show the text differently via CSS alone.

me

Back to your earlier suggestion of not using aria-label as a source for a custom tooltip but the visually hidden text content of a link - your .icon-link__label example. What are the benefits for accessibility or compliancy of not using aria-label but text content form an anchor.

AI

There’s no inherent WCAG compliance advantage: both aria-label and visually hidden link text can provide a valid accessible name. If my earlier suggestion sounded like using aria-label as the tooltip source was inherently inaccessible, that was too strong. W3C explicitly documents aria-label as a technique for naming links. W3C ARIA8

For example, these can produce the same screen-reader announcement:

<a href="/settings" aria-label="Settings">
  <svg aria-hidden="true">…</svg>
</a>

<a href="/settings">
  <svg aria-hidden="true">…</svg>
  <span class="icon-link__label">Settings</span>
</a>

The second assumes .icon-link__label visually hides the text without removing it from the accessibility tree—so no display: none, visibility: hidden, or hidden attribute.

I prefer text content for a few practical reasons:

• It uses the link’s native naming mechanism. An anchor gets its accessible name from its contents without an ARIA override. W3C recommends preferring native naming techniques where possible. Accessible naming guidance
• The same text can become the visible tooltip. If you reveal that span on hover and focus, the displayed label and accessible name naturally stay aligned. That helps avoid discrepancies for speech-input users. However, generating the tooltip directly from aria-label also keeps those strings aligned; this benefit is not exclusive to text content. Label in Name
• It avoids a competing name later. If someone adds or changes link text but leaves an old aria-label, the ARIA label takes precedence. Using the contents avoids that particular maintenance trap. Accessible naming guidance

The tooltip’s behaviour matters more for compliance than which source supplies its text. A custom tooltip still needs appropriate keyboard access and must meet the applicable dismissible, hoverable, and persistent requirements. Neither naming approach provides those automatically. Content on Hover or Focus

So I’d recommend the hidden-text pattern for simplicity and maintainability, rather than claim it gives screen-reader users a fundamentally better accessible name.

[thet]

@cornae gave his ok in #1298