Attributs prop type source replaces token

This would be so nice. Thanks a lot for filing the issue.

I faced an issue with Read more link or Learn more link in a call to action button
My current status is

The optimal target to work with aria-label="[node:field_link:text] about [node:title]" target="_parent"

A common accessibility challenge arises when multiple identical links (e.g., "Read Article") appear on a page. Without additional context, screen reader users may struggle to distinguish between links. ARIA attributes, such as aria-label, allow developers to add meaningful descriptions to links, ensuring clarity and context.

Helpful resource: What the Heck is ARIA A Beginner's Guide to ARIA for Accessibility - Kat Shaw (A11yTalks - Aug 2024)

Thanks to A11yTalks and Kat Shaw for this

Enhancing "Read Article" Links for Accessibility
Replace generic "Read Article" links with meaningful ARIA labels:
<a aria-label="Read the full article of {{ title }}">Read Article</a>

If the link text changes to "Learn more", "Read more", or "Click here", the {{ title }} token will still help maintain context for screen reader users.

First Draft MR - Integration with the Token module

Tested with

aria-label="[node:field_link:title] about [node:title]" target="_parent"

Attached a static ui_patterns--2025-05-16--3496209--mr-378.patch file to this point in MR378
To be used with Composer Patches

Hi Rajab,

Thanks for the MR, it is very exciting.

2 feedbacks:

• Do we really need dependency to the contrib token module? Core Token API is not enough?
• Can you add an automatic test with aria-label="[node:field_link:title] about [node:title]" target="_parent"?

Thanks, Pierre, for the quick review.

1- I will test that - you are right.
2- For sure, we need

• Automated unit testing coverage
• Automated functional testing coverage
• Documentation -- the doc in code is so nice by the way!!

3- We may need to do a small UX/UI designer responsibilities - to help site builders so that they can use a token.

Great plan!

hello,
thank you for your work, indeed this is a nice usecase :)
Today we have some code in Token source, if we plan to generalize it in other sources like Attributes, it would be good to rely on the same code in those sources.
i suggest that factorize some appropriate code about tokens, somewhere.
In a trait or directly in the SourcePluginBase ? @Christian, others, what do you think ?

do we need tokens elsewhere? maybe yes.

Hello rajab natshah,
thanks to your issue, we though to introduce a more deeper support for tokens in ui patterns sources.
so we will introduce a shared code to deal with tokens here : https://www.drupal.org/project/ui_patterns/issues/3540970 📌 [2.0.8] Enlarge the support of tokens in sources Active

Thanks to Florent first
I'm with your direction Mikael, for the deeper support for tokens.

General deep token integration is needed:
1- UI - so important ( for configs )
2- Twig - it will help a lot ( but we are moving to use UI Patterns as the default UI mapper )
3- Auto token change in .component.yml could help in some cases - if we allow for that like ActiveThemeChangeSubscriber.php
4- Tokens like DEFAULT_ACTIVE_THEME , default_theme could help when switching themes with old Views modes being used with the old theme, which has to move to the new theme ( VMI link )