@Jdlrobson - When can we expect this in production?

In T213778#8168903, @ovasileva wrote:

@Jdlrobson - When can we expect this in production?

I believe this is still correct:

In T213778#8158551, @Jdlrobson wrote:

We're targetting this being live on all the wikis on 25th August.

hence it is being announced in Monday's Tech News as "Changes later this week". :-)

External links’ colors changed in legacy Vector as well, both visited and unvisited (internal links’ didn’t):

Please change them back.

I can confirm that the external link color has changed from #3366BB to #3366CC and visited external link color has changed from #663366 to #795CB2 in legacy Vector. Active has also changed from #bb6633 to #faa700

Change 826303 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Vector legacy no longer imports variables from Vector modern

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

Change 826303 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Vector legacy no longer imports variables from Vector modern

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

Change 826250 had a related patch set uploaded (by Hashar; author: Jdlrobson):

[mediawiki/skins/Vector@wmf/1.39.0-wmf.26] Vector legacy no longer imports variables from Vector modern

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

Change 826250 merged by jenkins-bot:

[mediawiki/skins/Vector@wmf/1.39.0-wmf.26] Vector legacy no longer imports variables from Vector modern

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

Mentioned in SAL (#wikimedia-operations) [2022-08-24T16:51:30Z] <ladsgroup@deploy1002> Synchronized php-1.39.0-wmf.26/skins/Vector/resources/mediawiki.less.legacy/mediawiki.skin.variables.less: Backport: [[gerrit:826250|Vector legacy no longer imports variables from Vector modern (T213778)]] (duration: 02m 52s)

@Jdlrobson Amir has deployed the change. Can you confirm the colors are all appropriate now and if so remove the train blocker? Thanks ;)

Confirming! Thank you @Ladsgroup !

Unfortunately, the new link colors (especially for a:visited) in Vector 2022 are much to light on my screen; the readability is seriously impaired. Please provide a way to choose darker colors! The coding of a link color seems hard to override without using "!important", and without adversely affecting other link colors.

here is what I'm seeing in production:

(expected values above based on this documentation)

follow-up tracked here T316574: [regression] [Visual refinements] Toolbar tabs should not get :visited styling

For completeness, it looks like that's a regression caused by T308344 (so unrelated to this change). Seems like we can move this to sign off now?

@Jdlrobson @ovasileva @Volker_E additional questions related to link styling:

• I just noticed that the visited link styling is also getting applied to the [ reply ] buttons on Talk pages. As far as I can tell this was previously happening (in Legacy Vector) but was less noticeable because the visited link styling was so similar to the normal link styling. It might not matter much for [ reply ] because the Editing team is switching that to a button, however it makes me wonder if there are other link/buttons out there that are also getting visited link styling, but shouldn't be? This is more or less the same issue we're addressing in T316574: [regression] [Visual refinements] Toolbar tabs should not get :visited styling
• @stevenwalling has pointed out that all many links on Watchlist and Contributions pages have visited link styling (because any page that appears there is a page you've visited). This raises the question of whether it makes sense to use visited link styling on these pages or not. There might be other places, such as the User menu and/or Main menu, where visited link styling is more distracting than helpful as well. (link to discussion)

In T213778#8209079, @alexhollender_WMF wrote:

• @stevenwalling has pointed out that all links on Watchlist and Contributions pages have visited link styling (because any page that appears there is a page you've visited). This raises the question of whether it makes sense to use visited link styling on these pages or not. There might be other places, such as the User menu and/or Main menu, where visited link styling is more distracting than helpful as well. (link to discussion)

@stevenwalling wrote that the majority of links on watchlists and own contributions pages is visited, not all links and not all users’ contributions pages. And even this is not necessarily true, it depends on one’s watchlist usage—I, for example, usually visit changes to my watched articles from watchlist emails, so neither the article link nor the diff link on Special:Watchlist gets visited (the diff link in the email is a different URL), causing the majority of the links on my watchlist to be blue, not purple, and purple links highlighting mostly articles I recently edited (as after editing, I get the canonical URL).

Generally, I think overriding the color of visited links on a per-page basis is more confusing than helpful (why is this link marked as visited on this page but not on that one?). Maybe the visited link style could be changed to be more similar to the unvisited style (but still different enough from normal text color and background color, of course)?

Tacsipacsi is correct. I also pointed out in the discussion what they say about per-page inconsistency also being potentially confusing. I personally find it useless/annoying to have the purple visited style on my watchlist and contributions page but others could feel differently. I leave it up to the team to decide how to approach it—the largest audience here is readers, who generally can’t customize the style for themselves as easily as an editor/logged in user, so I think optimizing for them and giving editors tools to customize to their preferred needs is probably fine.

I prefer consistency as well. I think the visited link colour on the watchlist/main menu/contributions wouldn't be that annoying if the purple colour is closer to meeting the WGAC AAA standard (or even meets it, but there is only one colour that meets both accessibiilty requirements).
I suggested the two colours that fit with the criteria ((#3344dd for blue, and #804180 for purple)). If the blue is a given, #6550A5 may be a prettier option for the purple. It almost meets the AAA standard on a white background and comfortably meets the AA standard on a lightgrey background, which is common across the site. Happy to test if it still poses me trouble if somebody could explain how.

I hadn't realised that the black isn't 'pure black'. Now that I've ran the numbers, I see there is no colour that meets the AAA standards with background and the link standards. The purple can be made ever so slightly darker while still meeting the link standard, but that won't resolve the accessibility issue on white/light grey text. The best solution is probably not meeting either standard, but coming close to both.

Proposed colours on light-grey background

Proposed colours if WCAG AAA to white background is met

Proposed compromise colours

@ppelberg @nayoub @Esanders: it seems that on Talk pages, in both Legacy Vector and Vector 2022, the [ reply ] and [ unsubscribe ] links/buttons are able to get :visited styling. I never noticed this until recently, when we made the :visited styling more distinct from the normal link styling. I wonder whether or not it makes sense for these links/buttons to be able to get :visited styling (my initial thought is that it doesn't make sense)? What do you all think? And if you agree that it doesn't make sense, should we prioritize changing this? I believe this will no longer be an issue with the updated Talk pages, since they use buttons instead of links for Reply and Unsubscribe, though I don't know how soon that will be rolled out everywhere.

(Technical note: it’s because they use href="", so all the ‘links’ reference the current page.)

In T213778#8210178, @Femkemilene wrote:

I prefer consistency as well. I think the visited link colour on the watchlist/main menu/contributions wouldn't be that annoying if the purple colour is closer to meeting the WGAC AAA standard (or even meets it, but there is only one colour that meets both accessibiilty requirements).
I suggested the two colours that fit with the criteria ((#3344dd for blue, and #804180 for purple)). If the blue is a given, #6550A5 may be a prettier option for the purple. It almost meets the AAA standard on a white background and comfortably meets the AA standard on a lightgrey background, which is common across the site. Happy to test if it still poses me trouble if somebody could explain how.

We're aiming to achieve full WCAG AA support in our (new) product developments. It doesn't make sense to have a limited amount of interface elements AAA compliant, it doesn't provide affected humans added value when they could only interact/read half of our interface. On the other hand the contrast requirements for AAA would negatively impact color options and make our interface inharmonious and imbalanced.
Therefore we're unblocking additional software solutions catering to these needs (like Windows High Contrast Mode) without requiring AAA for WikimediaUI's color palette.

Change 622763 abandoned by VolkerE:

[mediawiki/skins/Vector@master] [modern][styles] Use default Design Style Guide link color choice

Reason:

Superseded by I8a309eedd70b9a82f

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

Has underlining been considered? The new colours still pose two accessibility problems

1. It's too light for about 10% of people. Many people who indicate it's too light indicate an accessibility issue (difficult to read) rather than aesthetics.
2. For people that are colour blind, the contrast between visited links and unvisited links may not be clear (see for instance Iritscen's feedback).

Contrast can be improved by a better choice of colours for #1 (grey/greyish purple at 4.5:1 looks fainter than bright pink at 4.5:1), but this does not resolve the second issue and there is a trade-off between aesthetics and contrast. To solve both issues, you need underlining. I've been trying out a subtle underlining, and that looks reasonably good in prose.

We're supporting to always underline links in user preferences underneath “Appearance” as MediaWiki feature.

Apologies for not being clear. Has underlining been considered as a default to allow the use of darker colours, and resolve the two accessibility problems above? I hope you agree with me that these do pose a problem, and that 4.5:1 contrast (or 5:1) is not a guarantee for sufficient contrast (as WebIAM says: "For many of us, some of these combinations are not very readable. That is why 4.5:1 is the minimum required by WCAG.." )

The standard underlining is intrusive given the density of links on Wikipedia, so we would have to go for something more subtle, as the example above in my css.

In T213778#8274592, @Volker_E wrote:

We're supporting to always underline links in user preferences underneath “Appearance” as MediaWiki feature.

Link colors affect all readers, logged-in or logged-out. User preferences are for logged-in users only. Unless and until you make this particular preference available for logged-out readers, this is not a solution.

In T213778#8218136, @alexhollender_WMF wrote:

@ppelberg @nayoub @Esanders: it seems that on Talk pages, in both Legacy Vector and Vector 2022, the [ reply ] and [ unsubscribe ] links/buttons are able to get :visited styling. I never noticed this until recently, when we made the :visited styling more distinct from the normal link styling. I wonder whether or not it makes sense for these links/buttons to be able to get :visited styling (my initial thought is that it doesn't make sense)? What do you all think? And if you agree that it doesn't make sense, should we prioritize changing this? I believe this will no longer be an issue with the updated Talk pages, since they use buttons instead of links for Reply and Unsubscribe, though I don't know how soon that will be rolled out everywhere.

Thanks, filed as T319019

Underlining all links by default is not a good usability choice for Wikipedia, and there is a reason why most sites with a high density of links (like Google search results pages) have moved away from underlining by default for all users. There is solid evidence that when there is a high density of links, underlining negatively impacts readability.

I very much agree that normal underlining (same colour, normal width, directly under words) would not work for Wikipedia. The study linked gives two reasons why readability is negatively impacted by that type of underlining

1. The underlining interferes with letter like q, p, j. This can be solved by giving the underlining a grey colour, and moving it down, for instance with something like "a:visited { text-decoration: none; padding-bottom: 1px; border-bottom: 1px solid #DCDCDC ;}"
2. The underlining makes the links stand out. The same is however true with the new colours, that are chosen explicitly to stand out better against the prose with a 3:1 contrast. This problem is unavoidable if we also want to make sure people can properly recognise links. Why not make it stand out in a way that does not pose a problem for 5-10% of people based on the respondents? Making the line thin further helps readability compared to standard line width.

And yes, in line with other places like Google, we can safely omit underlining for links where it's obvious they are links (watchlist, contributions, menus). These are the places where the new link colours cause the largest problems for me, and it's not even necessary to use the faint colours there.

Google uses #681DA8 for its visited links, and #1a0dab for its unvisited links. Neither colour comes close to the 3:1 criterion. Britannica also uses a blue colour that meets the AAA standard against the background (#14599D), and fails the 3:1 criterion. I'm not sure the 3:1 criterion was made for link-heavy websites.

JFYI: the study’s point on avoiding descender elements of q/p/j is outdated by now, all modern browsers already do that for underlined links.

I've reanalysed the feedback, to quantify the accessibility problem, classifying it in 4 categories (new, no objection to new, old, neither). I classified 135 responses, but have skipped some of those where there was a language barrier / machine translation didn't help me. The question was slightly steering the respondents to support. I think that is the correct way to deal with accessibility problems, as we're trying to solve a problem for a minority of editors, but that should be taken into account now that it has become clear the new colours also pose an accessibility problem.

Not all of those who object to the new colours indicate they have accessibility problems. Many people don't give an explanation or mention prettiness. The respondents note two accessibility problems with the new colours, their contrast with the white background, and their contrast with each other. Some people supported the change, but also noted that it was less easy to read for themselves.

Attached the raw data. I've done this somewhat quickly, so I wouldn't be surprised if there are a few misclassifications. I've taken a broad definition of accessibility, which includes those with only minor problems. If I only categorise those with a clear accessibility concern, the total group of people with problems halves to 11%.

During the office hours, I heard that you're in contact with a charity for people with visibility problems :). Thanks for taking this problem seriously, and I hope they will be able to provide us with a more accessible set of colours. Would it be an idea to contact WebAIM direclty?

Another aspect that I wonder if worth considering if how much we want to look forward to updates to the WCAG in the proposed changes to colour contrast accessibility calculations proposed in future in a new "APCA algorithm (Advanced Perceptual Contrast Algorithm)". It seems far off implementation, but worthwhile noting some of the inadequacies in the current calculation that it is intended to address.