Page MenuHomePhabricator

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

Description

NOTE: this task will affect the current/modern version of vector only (it will not affect legacy vector)

Description

We can improve the readability of our content in Vector in two ways:

  1. by updating our colors used for links and visited links to ones that are more distinguishable (i.e. further apart) from the color we use for running text (Base10 #202122). This will make links stand out better from normal text.
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. by updating our colors used for links and visited links to ones that are more distinguishable (i.e. further apart) from each other. This will make visited links easier to distinguish from non-visited links. It is unclear if the same tolerance should be used here. 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.

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.

Proposal

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

Resources to align

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
stjn added a comment.EditedJan 29 2019, 2:05 PM

#3366cc is a poorly chosen colour for links. While you’re upping contrast level to almost 3:1 with normal text, like WCAG 2.0 tells us, you’re decreasing it almost in two times for the background (while not against AA level, making it against AAA level). What that really tells us is not that we need to have less visible link colour, but we should’ve not used #222 as main text colour because of purely stylistic choices (and fix contrast of the links in regards to pure black text instead of dark grey).

You can use this for debugging it:
https://contrast-checker.glitch.me

@stjn can you clarify what you mean here:

While you’re upping contrast level to almost 3:1 with normal text, like WCAG 2.0 tells us, you’re decreasing it almost in two times for the background (while not against AA level, making it against AAA level)

I'm not sure I understand

stjn added a comment.EditedJan 29 2019, 5:35 PM

#3366cc is almost two times lighter against background compared to #0645ad and doesn’t pass WCAG 2.0 AAA level for text.

I see. To clarify:
#0645AD has a contrast ratio of 8.53:1 against #FFFFFF (passes WCAG AA, AAA)
#3366cc has a contrast ratio of 5.37:1 against #FFFFFF (passes WCAG AA, fails AAA)

I think it makes sense to balance these measurements with the measurements in the task description, regarding how distinguishable these colors are against black text. When considering only how they perform against a white background, I see your point about #0645AD. However when considering both measurements it seems like #3366cc is a better choice.

stjn added a comment.EditedJan 29 2019, 9:26 PM

Yeah, I get that, that’s why I’m saying that reverting back to black and seeking accessible colours next to pure black is better than having pale link colours that still barely come around WCAG 2.0 AA level requirement (3:1, see https://webaim.org/blog/wcag-2-0-and-link-colors/) because of using dark grey.

Volker_E updated the task description. (Show Details)Mar 7 2019, 3:45 AM

I was asked whether T219707, which I created, should be merged here. My reply was that the two tickets are "Related, but not the same".

I am unclear as to why they have been merged nonetheless.

Solving T213778 will not solve T219707.

@Pigsonthewing can you clarify what you mean here?

Solving T213778 will not solve T219707.

Volker_E triaged this task as Lowest priority.May 14 2019, 5:17 PM

@Pigsonthewing can you clarify what you mean here?

Solving T213778 will not solve T219707.

T213778 proposes "updating our colors used for links and visited links to ones that are more distinguishable (i.e. further apart) from the color we use for black text". It says nothing about making colours used for links and visited links more distinguishable from each other, which is the point of T219707.

@Pigsonthewing thank you for the clarification. Not sure why that task got closed. I think you could either edit the description of this task by adding a section about the contrast between links and visited links, or re-open that task.

Quiddity updated the task description. (Show Details)Sep 21 2019, 7:42 AM
Quiddity added a subscriber: Quiddity.

I've updated the description to cover T219707.

@Volker_E @Pigsonthewing the results in the second table in the Description section above are confusing when you compare them with the before/after demonstration image in the Proposal section. Visually it appears that the proposed colors are more distinguishable from each other, but the Delta E and contrast values are lower. What are your thoughts?

There are actually more inconsistencies that could and should be addressed:

  • External links and interwiki links currently use #36c as color, and #636 when visited. But in edit comments (where only interwiki links may occur) they use the normal link colors instead. This means, currently they are barely distinguishable from internal links, not distinguishable at all in edit comments, and won't be distinguishable after the proposed update, except when visited. I actually don't really see the point in having different colors for them at all (for external links the icon after the link should be enough), so it might be best to remove all those special colors and use the proposed ones for all links. But in any case, the colors for these links really should be addressed here, too.
  • Active links (i.e. while you click on them) use #faa700, which has a very poor contrast ratio. Except for external links, which use #b63. (This is also the case for interwiki links, though they have an additional definition with yet another color, but that's overridden a few lines later.) And except for some (but not all) interface links, which don't have a special color. And except for links to missing pages, which don't have a special color for active links, either.
  • While we are at it: Links to missing pages use #ba0000, and #a55858 when visited. Except when the missing link is in a vector tab (e.g. link to missing talk page), there always #a55858 is used, even for links not visited.
Restricted Application added a subscriber: Masumrezarock100. · View Herald TranscriptNov 6 2019, 9:55 AM
Jdlrobson moved this task from Needs triage to Needs Design on the Vector board.Jan 15 2020, 6:11 PM
Jdlrobson moved this task from Needs Design to Technical on the Vector board.Jan 15 2020, 7:54 PM
Jdlrobson moved this task from Technical to Needs Design on the Vector board.
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.”

Volker_E updated the task description. (Show Details)Jun 11 2020, 11:12 PM

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.

Huji added a comment.Jun 30 2020, 7:24 PM

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

Huji added a comment.Jun 30 2020, 10:11 PM

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

JTannerWMF moved this task from Incoming to Freezer on the Editing-team board.
Volker_E updated the task description. (Show Details)Aug 27 2020, 9:54 AM

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
Elitre added a subscriber: Elitre.Sep 22 2020, 7:10 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
ovasileva updated the task description. (Show Details)Sep 23 2020, 4:22 PM
ovasileva set the point value for this task to 5.Sep 23 2020, 4:29 PM

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.

Ladsgroup added a subscriber: Ladsgroup.
Jony added a subscriber: Jony.Tue, Sep 29, 11:45 AM
Volker_E updated the task description. (Show Details)Tue, Sep 29, 12:14 PM

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)Thu, Oct 15, 2:11 PM
Volker_E updated the task description. (Show Details)
Volker_E updated the task description. (Show Details)Thu, Oct 15, 2:14 PM
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)Thu, Oct 15, 5:12 PM