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
image.png (550×824 px, 88 KB)
image.png (548×816 px, 88 KB)

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:activenewnew: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
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
image.png (52×48 px, 1 KB)

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.

Screen Shot 2020-10-01 at 6.53.35 PM.png (654×428 px, 77 KB)

(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
image.png (52×48 px, 1 KB)

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
image.png (1×1 px, 441 KB)
image.png (1×1 px, 443 KB)

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

Jdlrobson added a subscriber: LGoto.

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.

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?

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

Jdlrobson added a subscriber: Sgs.

@Volker_E @ovasileva where did we get to herE?

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

I agree with this, so I'm not 100% sure what we got blocked on. In fact I was surprised we hadn't globally changed the link colors.
As T308700 points out the red links are not accessible for example