In T213778#6217686, @Volker_E wrote:move color special casing for external links and interwiki links and rather have a user stylesheet proposal for power users to re-instate color differences and possibly to add an interwiki icon (f.e. 'logoWikimedia') to the end of such link

The differentiation between .stub (#723) and .new and normal :link is another such problem child. You really have to know the wikis inside out to easily grasp the reasons behind it.

I like this general idea, but not all interwiki links go to WMF wikis, so the specific icon would be misleading. [[Special:Interwiki]] shows that most of our supported interwiki prefixes point to non-WMF wikis (and many non-wikis) so it may be better to just treat interwiki and external links as the same for styling purposes, but allow power users to define custom behavior.

I love the chart on https://www.mediawiki.org/wiki/Design/Link_colors, can we mirror that in the description?
I think what we want from this task is:

Is that correct?

In T213778#6500539, @Wugapodes wrote:

I like this general idea, but not all interwiki links go to WMF wikis, so the specific icon would be misleading. [[Special:Interwiki]] shows that most of our supported interwiki prefixes point to non-WMF wikis (and many non-wikis) so it may be better to just treat interwiki and external links as the same for styling purposes, but allow power users to define custom behavior.

+1. As a reader & as an editor, I also appreciate the subtle hint that a link is going offwiki but within Wikimedia, e.g. from Wikipedia to Wiktionary, such as in the link to "toponym" in the (featured-class) article https://en.wikipedia.org/wiki/Nahuatl#Vocabulary

In T213778#6501778, @Jdrewniak wrote:>

I love the chart on https://www.mediawiki.org/wiki/Design/Link_colors, can we mirror that in the description?

Thank you/you're welcome! :)

In T213778#6506545, @Quiddity wrote:

+1. As a reader & as an editor, I also appreciate the subtle hint that a link is going offwiki but within Wikimedia, e.g. from Wikipedia to Wiktionary, such as in the link to "toponym" in the (featured-class) article https://en.wikipedia.org/wiki/Nahuatl#Vocabulary

I can see how distinguishing between external wikimedia links could be useful for editors, and may even drive some awareness of the different projects for readers. However, there are way better ways to achieve this than an ever-so slightly different shade of blue. Many different types of links have icons associated with them, (like external, or pdfs, or maps) I think that approach could work for external wikimedia links too.

In T213778#6509613, @Jdrewniak wrote:

[...] Many different types of links have icons associated with them, (like external, or pdfs, or maps) I think that approach could work for external wikimedia links too.

Yup, and we used to have many more icons. Monobook & Timeless still use a handful, as can be seen at https://en.wikipedia.org/w/index.php?title=Help:External_link_icons&useskin=monobook#Example -- Vector used to have icons for all of those protocol & file types (hence the long list), but they were removed in 2014. My main related comment at the time (T56604#596469) was that I believe some of those were useful and should have been retained. (Sidenote: This was the era where https was rapidly becoming more common than http, so I believe the padlock icons which were attached to those, was perhaps the main source of frustration, apart from the CSS load).

Relatedly, I noticed a few days ago that Itwikivoyage automatically adds sister-project icons to all Wikimedia-interwiki links, e.g. https://it.wikivoyage.org/w/index.php?title=Wikivoyage:Lounge&oldid=673736#Scopri_il_programma_di_itWikiCon_2020_e_proponi_un_poster (or in the site-sidebar for the "In other projects" section) -- However, adding those by default would be very complicated because of all the use-cases where they shouldn't automatically appear (whether for objective or subjective reasons - e.g. adding unexpected line-wrap to infoboxes, or being a distraction to reading-flow).

Hence I believe the subtle-color distinction is the best compromise available at the moment.

In T213778#6500539, @Wugapodes wrote:

In T213778#6217686, @Volker_E wrote:move color special casing for external links and interwiki links and rather have a user stylesheet proposal for power users to re-instate color differences and possibly to add an interwiki icon (f.e. 'logoWikimedia') to the end of such link

The differentiation between .stub (#723) and .new and normal :link is another such problem child. You really have to know the wikis inside out to easily grasp the reasons behind it.

I like this general idea, but not all interwiki links go to WMF wikis, so the specific icon would be misleading. [[Special:Interwiki]] shows that most of our supported interwiki prefixes point to non-WMF wikis (and many non-wikis) so it may be better to just treat interwiki and external links as the same for styling purposes, but allow power users to define custom behavior.

Thanks for your comment @Wugapodes,
to be clear, I gave an example with a preliminary idea. Given that the current visual treatment of normal and interwiki links results in contrast ratio being very low (1.52:1), the assumption is that it's confusing to the average user, new reader more than helpful. Even for power users, you have to assume perfect sight, perfect monitor settings to identify those links apart. That's why an icon-solution seems easier identifiable, without all the edge cases thought through yet.

I'd propose to provide power users, like @Quiddity, a user style, that is either offering a different color or an icon solution as shared and discussed above. But relief the average user from the confusing color variants, hard to decipher and understand and confusing among each other.

In T213778#6485240, @Esanders wrote:

Weren't contrast ratios tested on foreground vs background colour? Using them to compute the contrast between two foreground colours seems problematic. Given the two comparisons are quite similar we can probably say that there is now greater contrast between text and links, but I'm not sure it makes sense to call it WCAG compliant?

(As discussed offline, the current WCAG calculation is very problematic [1], hence "probably" in the above statement)

If we want to make this change for the sake of consistency we should just be clear that is the main reason.

1. https://github.com/w3c/wcag/issues/695

The compliance comes with higher contrast. The calculation is mostly only problematic – as raised in that thread – in specific color combinations. There's no doubt, even with a different algorithm as proposed in the WCAG issue, that a higher contrast makes identifying links from surrounding text simpler for users in specific circumstances. It's beyond doubt that the proposed colors are in stronger contrast to each other.

Current	Proposed

Further information on 3:1 contrast success criterion “for normal observers”.

In T213778#6547086, @Volker_E wrote:

The compliance comes with higher contrast.

My main point is about comparing text colours with other text colours, not which algorithm is used. In the first line of the doc you link:

The intent of this Success Criterion is to provide enough contrast between text and its background.

Nowhere does it talk about the contrast ratio between two text colours on the same background that never overlap.

We should just be clear that the "target" contrast rations (3:1, 5.37:1 etc.) are only for text-colour:background-colour. There appears to be no WCAG specification for text-colour:text-colour contrast ratios.

In T213778#6645344, @Esanders wrote:

In T213778#6547086, @Volker_E wrote:

The compliance comes with higher contrast.

My main point is about comparing text colours with other text colours, not which algorithm is used. In the first line of the doc you link:

The intent of this Success Criterion is to provide enough contrast between text and its background.

Nowhere does it talk about the contrast ratio between two text colours on the same background that never overlap.

We should just be clear that the "target" contrast rations (3:1, 5.37:1 etc.) are only for text-colour:background-colour. There appears to be no WCAG specification for text-colour:text-colour contrast ratios.

Quite the contrary. It actually is defined as success criteria. Please see https://www.w3.org/WAI/WCAG21/Techniques/general/G183.html

Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them.

Updated description with T213778#6501778 to make things more clearer

Checked in With olga about this today and this is blocked on search deployment. Also sounds like we need a discussion on whether this should apply to legacy vector. Have marked patch with -2 and linked to this comment.

Changing the link color for the entirety of the vector skin would need more thorough conversations across all of the wikis, rather than the more focused conversations with the pilot wikis. This would require a significant time investment from @sgrabarczuk and divert focus away from the immediate needs of the Desktop Improvements project.

That said, I think we can pursue this change after we’ve made the new vector the default, as the changes would have to be discussed and approved by all wikis prior to deployment of the new default anyhow

Should this still be on the board? It was moved to doing in March 16th and there's been very little activity since. Is it blocked? If so, perhaps it shouldn't be on the sprint board given the time frame we're talking about here? cc @LGoto

@Volker_E - any updates on this one? If we're not planning on tackling it in the near future, I'd support moving it back to the backlog for now.

Moving to backlog for now - @Volker_E - feel free to bring this back into the sprint board whenever

As mentioned before, all of the proposed colors fail the WCAG AAA accessibility criteria of a 7:1 contrast ratio for normal text. We shouldn't be sacrificing accessibility in actually being able to read the text to make links stand out more. If you want to make links stand out, there is a standard way that that has been done since the beginning of the internet: underlining them.

In T213778#7228704, @Ahecht wrote:

As mentioned before, all of the proposed colors fail the WCAG AAA accessibility criteria of a 7:1 contrast ratio for normal text. We shouldn't be sacrificing accessibility in actually being able to read the text to make links stand out more. If you want to make links stand out, there is a standard way that that has been done since the beginning of the internet: underlining them.

Quoting the proposal: "2. by updating colors used for links and visited links to ones that are more distinguishable from each other." Underlining does not solve this.

Then use single vs. double underlines, or some other feature that doesn't sacrifice readability in favor of navigability.

Would it be possible to start with just addressing the visited link text color? I found this task because I wanted to address that specific issue, I have a very difficult time visually distinguishing visited links from background body text.

FWIW, the proposed visited color shows a contrast fail for WCAG A https://webaim.org/resources/linkcontrastchecker/?fcolor=0B0080&bcolor=FFFFFF&lcolor=6b4ba1 but going a little lighter shows a pass https://webaim.org/resources/linkcontrastchecker/?fcolor=0B0080&bcolor=FFFFFF&lcolor=5252FF

Also, this task is also about Vector, but maybe the changes should be made in core's resources/src/mediawiki.less/mediawiki.skin.defaults.less?

In T213778#7401220, @kostajh wrote:

...I have a very difficult time visually distinguishing visited links from background body text.

big +1, I have the same difficulty and feel like it's a significant usability issue

This might just be my lack of context, however, just want to confirm that the changes will be reflected in the Design System "tokens" - is that the case cc @Catrope @Volker_E

@iamjessklein The current WikimediaUI Base variables (as predecessor to our new tokens) currently already carry the design team's choice for link colors – Accent50. We've also been talking about defining legacy tokens in T288110.

A note has been added: "The proposed changes outlined here will affect the current/modern version of Vector only (it will not affect legacy Vector)"

A fix is required for legacy [SIC] Vector also.

Summary of issues with WCAG contrast: https://blog.datawrapper.de/color-contrast-check-data-vis-wcag-apca/