Non-hyperlink anchors (a elements) have hyperlink styling

I have attached a patch and added after patch screenshot for same. please review

Verified the latest patch and after applying #4 patch it is working fine. For reference attaching before and after screenshots.

I tested this patch and it's working as expected I attached the screenshot for this after testing.
RTBC + 1.
Thank you

@fgm I have one concern that why it is required to add <a name="foo">Foo</a>: Foo

if we are not using href in anchor tag then what is the use of <a name="foo">Foo</a>: Foo

@shiv_sharma : it makes that anchor addressable with a URL fragment, like https://somesite/somepage#foo, which is useful for in-page navigation with long form content.

@fgm do you have any accessibility links that this is an issue?

@smustgrave: you mean some reference documenting the fact that making a non-clickable item look just like a clickable one is not a good idea ? I'm afraid not, so I asked ChatGPT and it gives a well-articulated explanation similar to what I would have written, just better said:

As of my last update in September 2021, there were no specific WCAG guidelines or official documents that explicitly state that an HTML "a" element without an "href" should not be made to look the same as one with an "href" for accessibility purposes. However, there are some reasons and best practices related to accessibility that can help guide this decision.

Semantic Meaning: The HTML "a" element is used for creating hyperlinks. When you use an "a" element without an "href" attribute, it loses its semantic meaning as a hyperlink. Screen readers and other assistive technologies rely on semantic HTML to provide context to users. Making an "a" element without an "href" look like a hyperlink may be confusing to users who rely on assistive technologies.

User Expectations: Users expect the visual appearance of interactive elements to be consistent across the web. When they see an underlined or differently colored text, they anticipate it to be a clickable link. Inconsistent visual cues can lead to user confusion and frustration, especially for users with disabilities who may rely on specific visual patterns to navigate the web.

Keyboard Navigation: Users who navigate the web using a keyboard (e.g., using the "Tab" key to move through links) may encounter difficulty if an "a" element without an "href" is made to look like a hyperlink. They may find a visual link that they cannot activate using the keyboard, which can be a frustrating user experience.

SEO and Crawlers: Search engines and web crawlers may interpret an "a" element without an "href" as a broken or irrelevant link, potentially affecting SEO and indexing.

While there might not be specific WCAG guidelines that directly address this issue, the concept of providing clear and consistent user interfaces for all users, including those with disabilities, is a core principle of web accessibility. The Web Content Accessibility Guidelines (WCAG) emphasize creating a perceivable and understandable user experience, which aligns with the reasons mentioned above.

In that case I don't see any issue. Will also ask one of the Olivero maintainers to chim in though.

The last submitted patch, 4: 3374889-4.patch, failed testing. View results →

Test failure was a CI fluke: tests pass again, resetting to RTBC.

I'm triaging RTBC issues → .

After reading the IS and comments I don't see anything left to do. Leaving at RTBC.

I don't think we want the blue color or even hover styles for the anchor links because they are not interactable. Styles for these are in base.pcss.css.

#18 makes sense.

Drupal Helsinki Sprints 2023/11 - working on this based on #18

Updated base.pcss.css so styling is applied only to tags that have href attribute. Similar change had to also be made to text-content.pcss.css.

In my not-expert experience, there is a tendency to have non-link A elements visible on hover, sometime with a dashed underline. The goal, again, is to provide information to the user that there is an addressable resource at that point.

On d.o. itself, you can see it on this issue summary: when hovering over the third and fourth items in the list, you will notice that a blue color is applied as well as an underline. No idea whether this is just the same issue or an actual decision.

W3C's "HTML and XHTML Techniques for WCAG 2.0" has an example code for using a-tag without an href attribute and without text content (so obviously invisible to sighted users) - but it does not discuss presentation in case there would be some text. An h-tag linked from an a with href in that document is not styled differently from other headings though. This feels like a contradiction to what is said in #23.
https://www.w3.org/TR/WCAG20-TECHS/html.html#H86-ex2

There is a case of links without hrefs though. It is possible to have an <a role="link">text</a> or more commonly an image or a span. Semantic HTML is however considered best practise.

I could bring this up during tomorrows accessibility office hours if somebody else doesn't want to do it.

When styling anchor elements, it might be better to use the :link pseudo-class instead of styling the a element itself. The :link selector specifically targets anchors containing an href attribute, while avoiding styling anchor elements with just a name.

Using :link improves specificity and avoids inadvertently styling elements that aren't links.

Reference:
https://developer.mozilla.org/en-US/docs/Web/CSS/:link

Nitin shrivastava → made their first commit to this issue’s fork.

Thank you @shaal for your guidance on the best approach to differentiated styling for links and non-links. To style unvisited links specifically, a:link is more suitable as it targets only those links.

Why open a new MR for a small change to the existing MR5328?

believe 5493 should be closed and consolidated into 5328 since 5328 still points to the correct branch too.

Also if we are changing solutions the issue summary will have to reflect that.

@smustgrave Apologies for the noise. I'll address this promptly by updating 5328 with the necessary changes and also revising the issue summary.

@smustgrave, could you possibly take a look? I'm new to MRs, so if I've made any mistakes, I'd really appreciate your guidance

Rebased MR

Reading the issue summary, as a UI change before/after screenshots in the issue summary should be included for quicker reviews.

Added images in IS.

This makes sense to me. It's a simple change, but one that I think can avoid some confusion for users expecting a link.

Thanks! @mgifford

Pinged maintainers in slack for a +1

According to https://developer.mozilla.org/en-US/docs/Web/CSS/:link,

The :link CSS pseudo-class represents an element that has not yet been visited. It matches every unvisited or element that has an href attribute.

My worry on this patch is twofold:

1. The changes will break visited links. There's mention of this in #29, but we definitely want link styling to still apply to visited links.
2. The :link pseudo-class creates extra specificity that might break other styling. Let's use :where() to remove this specificity. Something along the lines of a:where([href]) as the selector.

Thanks for all the work on this everybody. Sorry to set this back to NW.

Reviewed the PR, made a small comment.

In UI everything works as expected.

In Claro though, a link without href has an accent color. Shall we handle the same change for Claro?

The issue is related to Olivero theme only. Maybe you can create a seperate issue for claro @YevKo

Note that the issue is not entirely equivalent in Claro, so the fix might not be the exact same: it has the color change but not the text-decoration, unlike Olivero.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Related to this: https://www.drupal.org/project/drupal/issues/3372666 🐛 D7 Backport: Links with "@" are converted into email addresses even if there is no domain suffix present Needs review from way too long.

I reviewed and tested the current MR. The changes are looks fine to me. the changes are worked for Non-hyperlink anchors only. Adding before and after effects.
Before:

After:

I think this issue has to be in RTBC.

Appears to be 2 MRs both against 11.x one should be closed or hidden.

ahsannazir → changed the visibility of the branch 11.x to hidden.

Hi,
I've reviewed the MR !5328 on Drupal 11.x.

Test Results:
Non link text is appearing without any link styles in the content.

Tested MR !5328 on the Drupal 11
The MR is applied Cleanly...

Test Result:
The No hyperlink text does not show the hyperlink style.

Attaching Screenshots for reference

RTBC+1

Just FYI for everyone uploading screenshots. Only the first set get credit. Re-uploading additional sets is just duplicative work.

This one has bounced around a few months. Saving credit for those who have worked on the MR but not for the duplicate screenshots.

Left a comment on the MR.