Page MenuHomePhabricator

Update link colors in Vector for improved UX (and consistency)
Open, MediumPublic5 Estimated Story Points

Description

NOTE: The proposed changes outlined here will affect the current/modern version of Vector only (it will not affect legacy Vector)

Proposal

Improve default user-experience* in Vector

  1. by updating colors used for links and visited links to ones that are more distinguishable (higher in contrast) from running text color. This will make links stand out better from normal text.
  2. by updating colors used for links and visited links to ones that are more distinguishable from each other. This will make visited links easier to distinguish from non-visited links.
CurrentProposed

Detailed description

  1. Update links and visited links colors to better distinguish from the color we use for running text (Base10 #202122).
colorstatushex value∆E (from #202122)contrast ratio (from #202122)
linkcurrent#0645ad29.771.89
linkproposed#36c31.263
:visited linkcurrent#0b008028.731.01
:visited linkproposed#6b4ba131.142.41
  1. Update links and visited links colors to make them more distinguishable from each other. The table below compares the current and proposed visited link colors with the proposed link color (#36c):
colorstatushex value∆E (from #36c)contrast ratio (from #36c)
:visited linkcurrent#0b008028.372.95
:visited linkproposed#6b4ba120.211.24

Note: the results in the table above are confusing when you compare them with the before/after demonstration image in the Proposal section below. Visually it appears that the proposed colors are more distinguishable from each other, but the Delta E and contrast values are lower.

(*) Identifiability of links for users in alignment with Web Content Accessibility Guidelines 2.1 level AA contrast ratio requirements.

The determination of how close/far apart two colors are can be made by measuring the Delta E value between the two colors (using this tool), and the contrast radio between the two colors (using this tool). The table below suggests two colors that perform better than our current colors. These colors are also currently being used in Minerva (see T204081), and are part of the Wikimedia Design Style Guide, so there is a win for consistency as well.

Proposed Final state

link type:localinterwikiexternallocal:vistedinterwiki:visitedexternal:visitedlocal:activenon-local:activemissingmissing:visited
current:#0645ad#3366bb#3366bb#0b0080#663366#663366#faa700#bb6633#ba0000#a55858
proposal:#3366cc#3366cc#3366cc#6b4ba1#6b4ba1#6b4ba1#faa700#bb6633#ba0000#a55858

Acceptance criteria

  • Update the link color to #36c
  • Update the :visited link color to #6b4ba1

Resources to align

See also

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Volker_E added subscribers: iamjessklein, Mainframe98.

From @iamjessklein on merged-in duplicate T255188: “during recent round of usability testing T246190 we had a vision-impaired tester unable to complete any of the tasks because they were unable to differentiate a link from text.”

What @Schnark said,

  • external links in 'elements.css' are defined to follow same color styling as interwiki links. External links are already additionally carrying an icon in Monobook, MinervaNeue and Vector.
  • interwiki links. The concept has never convinced me, specifically as the color differences are very subtle between them and normal links, making it for new or non-power users of Wikimedia projects very hard to grasp what this should be about and confusing.

I'd propose to remove 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.

@Jdlrobson @nray @Jdrewniak Would you accept Links as a style component aka Links.less in latest Vector? The links are not components in the conventional manner, but with our current CSS architecture I don't know where to fit them in best-possibly.
The other way would be to address this in core's 'elements.less' and I just don't feel that we've got enough time on our hands to get into the conversations with community about taking away special link treatment for power users, even though it's from design and newcomer perspective badly implemented to the point of being confusingly unhelpful.

The Editing team isn't planning to work on this, the direction we are going will make this a moot point on our end. If you feel this is incorrect feel free to let us know.

@JTannerWMF is there a place I can read more about the direction that the Editing team is going?

@Huji Are you thinking in context of link colors, I'd assume? This would apply to work done in Desktop Improvements project. Please also consider T153043 as related task.

@Volker_E yes, I am just curious to know what the general direction is. Passing no judgements here; just being curious.

Change 622763 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/Vector@master] [modern][styles] Use default Design Style Guide link color choice

https://gerrit.wikimedia.org/r/622763

ovasileva raised the priority of this task from Lowest to Medium.Sep 10 2020, 3:45 PM

From @iamjessklein on merged-in duplicate T255188: “during recent round of usability testing T246190 we had a vision-impaired tester unable to complete any of the tasks because they were unable to differentiate a link from text.”

So this change would fix that? (This isn't clear for me from the comments' history.)

@Elitre Without wanting to speak for another user's experience, it would provide a stronger, Web Content Accessibility Guidelines compliant contrast ratio between links and surrounding text.

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

We refrained from estimating this today for the following reasons:

  1. We weren't sure where these link colors are defined, and if this change will require a change in core,
  2. If it's just in Vector, we weren't sure how to separate the color variables for legacy and modern vector
  3. We weren't sure how to change the colors of the related "external link" icon (or any similar icon that appears as part of a link).
  4. We think this change requires some community consultations.

to @Volker_E 's earlier point about treating links as a component, I say yes. My oversimplified definition of a component is "anything that is clickable", so I think links count. Also, given the complexity and different types of links we have, with their various states, and how they can be combined with an icon sometimes, is enough complexity IMO to justify treating them as a component.

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:

link type:localinterwikiexternallocal:vistedinterwiki:visitedexternal:visitedlocal:activenon-local:activemissingmissing:visited
current:#0645ad#3366bb#3366bb#0b0080#663366#663366#faa700#bb6633#ba0000#a55858
proposal:#3366cc#3366cc#3366cc#6b4ba1#6b4ba1#6b4ba1#faa700#bb6633#ba0000#a55858

Is that correct?

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

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! :)

+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.


(this topic is a bit out of scope of this task but I couldn't help myself writing the user style )
https://en.wikipedia.org/wiki/User:JDrewniak_(WMF)/common.css

[...] 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.

Volker_E updated the task description. (Show Details)
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.

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.

CurrentProposed

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

Volker_E updated the task description. (Show Details)

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.

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.

ovasileva added a subscriber: ovasileva.

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