I don't agree with the proposal of adding the menu items as blue links for the following reasons:

1. We need to differentiate between links and clickable items:
   • Links are clickable text within a paragraph while clickable items are elements outside a paragraph.
     
   • If we use a link for clickable items then just the text would be clickable. If we implement all the item clickable (painting all bg) it's easier for the users to click the item and understand what they are selecting.
     

2. We need to reduce the use of blue in our system since currently it's difficult to highlight something in the page because too many items are already blue (our accent color). I think we should reserve the blue to highlight main actions.

In my opinion, we should use the link (blue text with underlined when hover) just for text links within text paragraphs. For the rest of clickable items (menu items, menu triggers, tabs...) we should use other components (not links) and create for them a different behavior in which the whole item is clickable (painting all the bg as we have in our current menu items). If we start to use links for menu triggers and menus items, it will be difficult to understand in a page what elements are text links and what items are simply clickable items.

@bmartinezcalvo I don't think people using the website make a distinction between "links within text paragraphs" and "links within the interface". I believe a link is a link. And I think if we are going to make a decision to override the default styling of a link (which would be a big change) we need to have a strong argument for how this makes the website easier for people to use.

regarding your point about hover area, I don't think this is an issue because you can have both blue links and a large hover area:

2. We need to reduce the use of blue in our system since currently it's difficult to highlight something in the page because too many items are already blue (our accent color). I think we should reserve the blue to highlight main actions.

where is the evidence for this?

(Logistics side note: This proposal is still being evaluated and therefore shouldn't be considered a blocker for the first release of TypeaheadSearch. Any needed changes resulting from the evaluation of this proposal would be applied to the relevant component(s) in subsequent tasks. Pinging @DAbad for visibility.)

@Sarai-WMDE @bmartinezcalvo @Volker_E in case it is helpful for our meeting tomorrow:

during our current round of feedback on Vector 2022 (link to feedback) we asked about the color of links within menus (link to specific question). the current responses are:

This caught my attention because I have also been thinking about the use of blue vs black/gray for a particular use case and also in general evaluating the amount of blue on the page. There seem to be a lot of inconsistencies with the way we use blue right now for links/CTA which you clearly highlighted above.

Here are a few of my thoughts on bringing some structure around these rules or the lack of rules in this case.

• Blue links work well on the page itself along side other content because it really helps differentiate between links and content.
• However, when the links are within a menu or a dropdown they do not necessarily need to be blue. The fact that those links are in a menu/dropdown indicates that they are clickable. I personally find the menus and dropdown with all the blue links very heavy because there is a lot of blue packed in a tight space and it somewhat hinders the reading and scanning of content.

And so I would propose to have text links as blue when they are on the page with other content and have text links as black/grey inside menus/drop downs that are triggered by user action.

My two cents:

• Regardless of if we land on blue vs black/base10 links, if the navigation menu has an icon, then the icon should be the same colour as the text lab
• Clarifying with @alexhollender_WMF that this is only talking about navigational menus only for links (and not selection dropdowns) then I do lean towards the default colour of blue links.
  • However, I wonder if it is ever a (common?) case that there could be a mix of links and actions? If so, then having this mixture of blue & black/grey items might be quite strange, and where it may be better to err on the side of black/base10.

thanks for adding feedback @Sneha

In T311270#8038023, @Sneha wrote:

I personally find the menus and dropdown with all the blue links very heavy because there is a lot of blue packed in a tight space and it somewhat hinders the reading and scanning of content.

are there examples you can provide regarding this comment? are you looking at something like this?

Yes I was particularly referring to all the examples in the description above. As I have not come across many such examples on internet. Usually on other websites menu link/dropdown links are not blue but links on the page are.

Like in this example on apple's website the link on the page is blue but within the menu its all black.

Also on google the drop down and menus don't use blue but the results have a lot of blue links.

@Sneha thanks for clarifying. to note: the items in the search results menu on google are not links in the same way. it is almost like a select menu with suggested searches(?).

also, as a general note, when evaluating any kind of design decision, I think we should start from the default. The default (both in terms of HTML, and our style guide) is that links are blue. So the burden of proof is not on defending why links should be blue...they already are blue. The burden of proof is on defending why we should deviate from the default, i.e. do we have a strong argument for the usability of menus increasing by making the links a different color?

yes I agree we should evaluate it from the usability point of view. And since we don't have a default style right now because as you pointed out it's very inconsistent sometimes we use black sometimes we use blue in menus. It goes back to my original comment - links in a menu already look like links because of the nature of having them in a list in a menu. And so is it necessary to make them all blue? Same goes for autocomplete and I am assuming there are no usability concerns so what is the purpose of making them blue? Especially in the search autocomplete list I find the blue distracting in terms of scanning content.

P.S. I read Barbara's comments about not using blue in menu and agree with that as well.

In T311270#8038412, @alexhollender_WMF wrote:

@Sneha thanks for clarifying. to note: the items in the search results menu on google are not links in the same way. it is almost like a select menu with suggested searches(?).

also, as a general note, when evaluating any kind of design decision, I think we should start from the default. The default (both in terms of HTML, and our style guide) is that links are blue. So the burden of proof is not on defending why links should be blue...they already are blue. The burden of proof is on defending why we should deviate from the default, i.e. do we have a strong argument for the usability of menus increasing by making the links a different color?

I'd like to question the framing a bit. The default for links is blue, however the default for options in a context of selection is not blue (e.g., the select element). I think the expectation can be different depending on whether options are perceived/presented as places or actions (even if the underlying element to implement them is technically an <a> element, that is, a link). Places have a strong sense of navigation and the blue link metaphor works well. For actions instead it feels less appropriate.

The particular menus the task is about can be a bit tricky since some actions are supported by separate pages, leading to navigation, so there may be a blurry line. While I agree that users may not make a strong distinction between content and UI, I think that UI options are more perceived as actions users can perform. The expectation when opening a menu for tools may be more close to finding actions than having a list of places to visit (as blue links communicate). However, for something more connected with the content (e.g., the table of contents), the notion of place seems to fit more and links work more naturally.

This is something I was thinking about in the context of the language selector (T253303). In terms of consistency it used blue text on desktop and black text on mobile. For the new language selector we considered showing the options in black across both platforms. Moving from the concept of a list of links to a selector to switch the language, since the selection aspect was more relevant that whether the Japanese version of the article is hosted on a different site and a navigation has to happen to reach there.

For reference this is how the current mobile language selector would look with black and blue links:

Current language selector on mobile web	Modified version to show options as blue links

@Pginer-WMF thanks for adding these thoughts. I think they are helpful in continuing to evaluate this challenge.

To summarize my understanding of your main point: sometimes links are less like destinations/places, and more like actions, and when they are more like actions it might make sense to style them differently than their default styling. You also bring up the example of the <select> element, which is similar in ways to the navigational menus we're discussing.

<select> menus vs. navigational menus

While these are similar in ways, I think it's helpful to clarify the distinction between an <option> (which is found in a <select> element), and a <link>, from the perspective of the person using the website. I think the two main differences are:

• links can be opened in new tabs
• links can be copied and shared

I think these are important qualities/attributes of links from an experience/usability perspective. Maybe these differences (and others) are part of the reason why in native HTML a <link> and an <option> look different. I understand your comparison, because when we present a bunch of links in a navigational menu it is similar to a select menu with a bunch of options, but again I think these are functionally distinct, and as such should not necessarily be styled the same.

links as "actions" vs. "places"

I understand your point, and agree that often there are links that might be understood by someone as both a link and an action. However I think that trying to come up with a design system rule that relies on this distinction is problematic for two reasons: 1) it relies on us trying to guess how people will understand things, and 2) it creates a third thing (links, buttons, and links-that-are-actions), which I believe we ourselves will have a difficult time defining and discussing. I think your comment here illustrates why trying to make this distinction is problematic:

Moving from the concept of a list of links to a selector to switch the language, since the selection aspect was more relevant that whether the Japanese version of the article is hosted on a different site and a navigation has to happen to reach there

How can we know that they think of it more of an action or a link? Are we sure that we don't want to communicate that, in fact, Japanese Wikipedia is a different website? What if it's equally a link and an action? What if it's a link, but then at a smaller resolution it gets collapsed into a menu, does it then become an action-link? Could we apply this same logic to an article link: imagine someone searches for "X" and then there is an element on the page that says: did you mean "Y"? (where "Y" is a clickable element). Are they just selecting an "option" which they meant to select instead of "X"? Are they thinking about the fact that they will navigate to a different page/URL? These things seem difficult to know and/or make assumptions about.

Back to the initial framing, I think it's important to start by asking, what user experience problems are presented by displaying the language links in blue (which is what happens by default)?

@Sarai-WMDE @Volker_E yesterday during our meeting you each brought up the question of scope, and mentioned questions about other components following this pattern of a link is a link. Can you specify which components (including implementation examples of those components in production) that you are thinking about? It would probably make sense to eventually put those examples in a separate task, but maybe for now it's okay to include them here as it might help further evaluate this challenge.

Here is one such example, from the Newcomer Hompage:

current	default link styling

@Volker_E @Sarai-WMDE @bmartinezcalvo based on our recent discussions, and the input from the community, we've decided to move forward with blue links in navigational menus. To summarize our reasoning:

1. As a principle we will use the default style unless a different style has been shown to work better and is clearly documented in the style guide
2. Blue links offer consistency with other links in the interface, allowing for people to easily understand how they work (e.g. clicking will navigate to a different page, can be opened in a new tab/window, can be copied & shared, etc.)
3. Blue links make navigational menus with section headings easier to understand
   
   
4. Blue links make navigational menus with compound items easier to scan
   

I am unassigning myself from this task as it is resolved as far as Desktop Improvements (Vector 2022)/vector 2022 is concerned. Feel free to use it for further discussion and evaluation if you would like.

In T311270#8041577, @alexhollender_WMF wrote:

@Pginer-WMF thanks for adding these thoughts. I think they are helpful in continuing to evaluate this challenge.

Thanks for the reply, Alex.
I think the conversation in this ticket helped to surface important considerations for the future standardization of menus (beyond this specific project).

links as "actions" vs. "places" (and expectation of side-effects)

Regarding the distinction of "actions" and "places", I agree the distinction can be often blurry. However, the concept of a link comes with the assumption of not having side-effects (i.e., the idempotent concept for the GET method in terms of HTML). That makes clicking links safe, and gets people used to move around from place to place freely (without fear to mess things up). Under that perspective, it is unexpected to see actions such as "log-out" presented as a link (where is the user going? what does it mean to open in new tab or keeping a bookmark to it?). Technically, clicking the "log-out" option navigates to a special page to log-out (which happens automatically as you land to that page), but that is a technical means to support the action of logging-out (which is what is more relevant to the user, and what the label rightfully communicates). A similar example could be "Download PDF", where the expectation, I think, it is to get a PDF document downloaded. Not to navigate to the download tool page where I can then ask again for the PDF. In this case the place seems more of a workaround to support the action.

Based on the above, presenting menu options as links comes with some assumptions that are useful, but also others that we may be breaking for some of the options. In contrast, presenting menu options as a more neutral set of options makes less promises about those assumptions (also losing some of the positive aspects that we could communicate such as being able to open on a new tab).

On defaults and prominence

Regarding the concept of default, I think that defaults are relevant mainly because they are expected to be what most people encounter and get used to (i.e., setting their expectations on how things work). For example, technically links are underlined by default. However, many places avoid the underline style to make them less prominent and avoid too many elements shouting for the user attention. I don't think it is a problem that we deviate from the underlined links even if they are the default on HTML since it is a common practice and it is done for a good reason.
In the case of menus I think it is a valid consideration for menus with multiple options to determine which is the right level of prominence. Especially considering that those menus are part of the UI/chrome that we don't want to be distracting users from the content according to the "Content-first" principle.

In T311270#8054763, @Pginer-WMF wrote:

...it is unexpected to see actions such as "log-out" presented as a link (where is the user going? what does it mean to open in new tab or keeping a bookmark to it?)...
...A similar example could be "Download PDF", where the expectation, I think, it is to get a PDF document downloaded. Not to navigate to the download tool page where I can then ask again for the PDF. In this case the place seems more of a workaround to support the action.
...Based on the above, presenting menu options as links comes with some assumptions that are useful, but also others that we may be breaking for some of the options. In contrast, presenting menu options as a more neutral set of options makes less promises about those assumptions (also losing some of the positive aspects that we could communicate such as being able to open on a new tab).

thanks for the continued thought partnership...great points and well explained.

links as "actions" vs. "places" (and expectation of side-effects)

I've also identified "Log out" as an item in that menu that is different from the others, and agree that from the perspective of someone using the website it's an action (which is incidentally a link as well, though it's easy to imagine it not being a link...just logging you out and leaving you on the same page). "Download PDF" is another good example, as is "Dark mode" (which appears in that menu if you've enabled the gadget). I think, as you've explained, there are tradeoffs with both approaches, and I agree that these are the tradeoffs we should be exploring. To summarize two approaches:

1. making links and buttons explicit...trying to communicate what you can expect from clicking on something
   • this comes with the difficulty of having to decide what a thing is (e.g. is it a link or a button)
   • this might also result in a more clunky/disharmonious look, particularly for menus or areas of the interface that include a mixture of links and buttons
2. a more "neutral" approach, that "makes less promises" what will happen (i.e. less explicit)
   • this means people have less information about what clicking something will do (and possibly confusion around what they are able to click on, especially for more complex menus that have section headings, or other non-clickable elements within them)
   • this means we have variations of things (e.g. there isn't just one styling for a link), which introduces a certain amount of complexity both for the people using the website, and for the design system

more explicit	less explicit

(maybe something we start to question through this exploration, is whether our menus are getting too large and/or complex...I imagine other useful questions would arise if we looked at different menus at this level of detail)

here is another example of a menu that is a bit more complex, but in a different way. if the "learn more" link was styled in black I imagine people might not realize they can click on it. if "learn more" was blue, but the other menu items were black, that seems oddly inconsistent (which again requires more thinking & complexity on the design & engineering sides).

On defaults and prominence

I agree that there are situations where it is beneficial to modify the default styling of an element. My main point there is that we should a) start with the defaults in all cases, and b) have clear reasoning (and ideally test results) that guide our decisions whenever we are modifying the default styling. In other words I think it's something we should take care around, because I assume (and maybe take it for granted) that the defaults are good. To your specific point, regarding underlining links, I think it's interesting and important to take a look at the default, and be able to clearly articulate and demonstrate why a modification is beneficial:

A lot of good points were already brought up here, but I wanted to chime in from an accessibility and technical perspective.

As I understand, it the default styling of links is important because it allows users to quickly differentiate links in a body of text. So while it is generally recommended for accessibility, the context and reasoning for that guidance is aimed towards text links in paragraphs. The WCAG guidance for additional visual cues (i.e. underline) specifies links in a paragraphs and the WCAG 1.4.1 failure description acknowledges some links are visually evident from page design and context. Navigation, headers and footers are common cases where it's less important to follow this rule, as the elements are usually all links or are already clearly differentiated as actionable items. Nielson Norman Group also lists navigation menus as an exception with similar reasoning, it's safe to remove "when the page design clearly indicates the area's function".

While I think being “explicit” is generally a good thing to strive for, I think it's more complicated than just relying the default style. On it's own, this approach starts with the technical implementation as the basis for the design, which rarely always aligns with the intended design and expected outcome. Nowadays it's fairly common for buttons/links styles to be used according to visual weight rather than its technical function (i.e. "Proceed to checkout" is often a link styled as a button to be the primary CTA). There's plenty of examples of this across Vector, including quirky ones like the "log out" link, where it's implementation as a link is arguably unexpected.

We should definitely be thinking about how to best align our design with expected functionality, but I’m wary of a situation where it supersedes other considerations like the context of a particular link/button within a component or the page design. Especially considering the broad scope of this change, and the reality that technical implementations are so inconsistent across WP.

In T311270#8088896, @bwang wrote:

Nielson Norman Group also lists navigation menus as an exception with similar reasoning, it's safe to remove "when the page design clearly indicates the area's function".

@bwang thanks for bringing in this additional context. Just to clarify what the Nielson Normal Group says (because not everyone will click through to read it in full):

Assuming the link text is colored, it's not always absolutely necessary to underline it.
There are two main cases in which you can safely eliminate underlines: navigation menus and other lists of links. However, this is true only when the page design clearly indicates the area's function. (Remember: your design might not be as obvious to outside users as it is to your own team members.) Users typically understand a left-hand navigation rail with a list of links on a colored background, assuming it resembles the navigation areas on most other sites.

For completion, the user setting of always underlining links results in mixed treatment in our current interface: