@Mvolz, why has this been given a low priority?

I imagine editors would only notice this in 50-70% of cases (as the title will partially match), meaning that this bug has the potential to lead to a lot of mistakes with source-text integrity.

This no longer seems to be an issue with Firefox 128.0 and the current version of the Wikimedia software 🎉. Tested on two computers without problems.

One accessibility aspect that hasn't been discussed much is accessibility to those with mild cognitive impairment. If you avoid both red and green in diff colours, you create a barrier for these editors. A better strategy is to stick close to the red-green, for instance orange-teal. Or pinkish red vs blue.

The same error occurs on a Galaxy S23, latest version of the Wikipedia app, using the OneUI version 6.0.

If it's useful, I frequently experience the same bug using Firefox on Android mobile (can't reproduce it today, but this has been nagging me for ages, I think the last time on November 25). I'm not using landscape or desktop mode.

I'd like to add my voice to the choir: zebra 9 is much calmer and easier to read than the white background, or having only the menus framed in grey. I personally prefer the version where the top is the same colour. I don't think the TOC will be used less.

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.

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

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

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

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.