Some of this might be addressed by the task we are working on in T356899.
It would be a good idea if that doesn't address the issue to disable night mode on file pages (at least to start with)

cc @Mike_Peel

Work for WMF:
Update the following hex codes to design tokens:

• https://gerrit.wikimedia.org/g/mediawiki/core/+/189d41676f27744d650d95caf2334e915a04dabe/resources/src/mediawiki.action/mediawiki.action.view.filepage.less#159
• Add notheme class to https://gerrit.wikimedia.org/g/mediawiki/core/+/189d41676f27744d650d95caf2334e915a04dabe/includes/page/ImagePage.php#772

Work that @Mike_Peel can help us with:

• We need to update https://commons.wikimedia.org/w/index.php?title=MediaWiki:Filepage.css with the following:

table.commons-file-information-table, .fileinfotpl-type-information, .fileinfotpl-type-artwork,
.fileinfo-paramfield {
      color: #202122;
}

• We need to add notheme class to all the elements that appear on https://m.mediawiki.org/wiki/File%3AAt_Wikimedia_Hackathon_Athens_(MP)_2023_001_(cropped).jpg?minervanightmode=1

e.g. <div class="hproduct commons-file-information-table"> should become <div class="notheme hproduct commons-file-information-table">

@Mike_Peel add this code to your user JS to force night mode on file pages:

(function () {
   const c = document.documentElement.classList;
   if ( c.contains( 'skin-night-mode-page-disabled' ) ) {
     c.remove( 'skin-night-mode-page-disabled' );
     c.add( 'skin-theme-clientpref-night' );
     const btn = document.createElement('button');
     btn.textContent = 'restore day theme';
     btn.setAttribute('style', 'position: fixed; bottom: 0; right: 0;' );
     document.body.appendChild(btn);
     btn.addEventListener('click', () => {
          c.add( 'skin-night-mode-page-disabled' );
          c.remove( 'skin-theme-clientpref-night' );
     } );
   }
}());

Do we need design support on this to choose the right tokens, @Jdlrobson ?

Not yet. Right now I'm just waiting on @Mike_Peel 's availability! He said he might be able to have a look this week.

Work that @Mike_Peel can help us with:

• We need to update https://commons.wikimedia.org/w/index.php?title=MediaWiki:Filepage.css with the following:

table.commons-file-information-table, .fileinfotpl-type-information, .fileinfotpl-type-artwork,
.fileinfo-paramfield {
      color: #202122;
}

Edit made, although it doesn't seem to have changed anything? https://commons.wikimedia.org/w/index.php?title=MediaWiki:Filepage.css&diff=prev&oldid=879884269

@Mike_Peel add this code to your user JS to force night mode on file pages:

(function () {
   const c = document.documentElement.classList;
   if ( c.contains( 'skin-night-mode-page-disabled' ) ) {
     c.remove( 'skin-night-mode-page-disabled' );
     c.add( 'skin-theme-clientpref-night' );
     const btn = document.createElement('button');
     btn.textContent = 'restore day theme';
     btn.setAttribute('style', 'position: fixed; bottom: 0; right: 0;' );
     document.body.appendChild(btn);
     btn.addEventListener('click', () => {
          c.add( 'skin-night-mode-page-disabled' );
          c.remove( 'skin-theme-clientpref-night' );
     } );
   }
}());

I generally avoid using the mobile interface, I'm hoping dark mode might come to Vector 2022 at some point soon?

In T357575#9839790, @Jdlrobson wrote:

Not yet. Right now I'm just waiting on @Mike_Peel 's availability! He said he might be able to have a look this week.

I'm happy to help when I can, but please don't let me hold your work up!

Edit made, although it doesn't seem to have changed anything? https://commons.wikimedia.org/w/index.php?title=MediaWiki:Filepage.css&diff=prev&oldid=879884269

Seems to be working. Thanks!

The remaining issues seem to be with the links here in these red boxes which are not accessible:

Could we make those use a different blue with a different color contrast or simply make these black with an underline? Would that be controversial?

I generally avoid using the mobile interface, I'm hoping dark mode might come to Vector 2022 at some point soon?

It's available on Vector 2022 now. You can copy this script into your global.js and it will work on both mobile and desktop on all pages:
https://meta.wikimedia.org/wiki/User:Jdlrobson/global.js

In T357575#9840333, @Jdlrobson wrote:

Could we make those use a different blue with a different color contrast or simply make these black with an underline?

I think black-with-underline would make it much less discoverable (maybe even for people who currently have difficulties reading it due to the contrast issues): underlining is often used to highlight important text (e.g. in the made-up example you must attribute the author), so people wouldn’t understand it as a link. Therefore I think the only good solution is playing with different shades of blue – the question is only which ones.

Since the link color is the default one and the background color is custom, I’d rather change the background color in the template.

Using Minerva, Firefox’s accessibility inspector says that the color contrast is 5.1 (AA compliant, not even borderline). Which skin/accessibility check tool do you use?

This is the same as the first one, except that the background color is, while not default, a quasi-standard one, so I’m more reluctant changing it (this one would likely be controversial).

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

[mediawiki/core@master] Disable non-standard colors in dark mode

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

Using Minerva, Firefox’s accessibility inspector says that the color contrast is 5.1 (AA compliant, not even borderline). Which skin/accessibility check tool do you use?

I'm using WCAG color contrast checker. Are you perhaps checking the :visited link color (which is AA compliant)?

Change #1038434 merged by jenkins-bot:

[mediawiki/core@master] Disable non-standard colors in dark mode

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

In T357575#9857012, @Jdlrobson wrote:

Using Minerva, Firefox’s accessibility inspector says that the color contrast is 5.1 (AA compliant, not even borderline). Which skin/accessibility check tool do you use?

I'm using WCAG color contrast checker. Are you perhaps checking the :visited link color (which is AA compliant)?

Your screenshots show the (Reusing this file) link; that’s highlighted as a violation by Firefox as well. What isn’t highlighted, is the link in the {{Extracted from}} template. As far as I remember, I tested it both in before and after clicking it. (Although what I do remember, is that toggling the :hover pseudo-class didn’t change the results, not even the colors displayed next to the contrast ratio… But evaluating the visited color before I’ve clicked the link would be another level of being buggy.)

What isn’t highlighted, is the link in the {{Extracted from}} template. As far as I remember, I

The links in extracted is working now after a template change: https://commons.wikimedia.org/w/index.php?title=Module:Information&diff=prev&oldid=881177359 - note this issue was only occurring in the night theme where the link colors are different (so I can see why that was a confusing comment I posted). Before that the color contrast was 3.03.

This ticket is ready for estimation on the understanding that some changes will still be required by editors after the deploy, and that the update to OOUI to support dark mode, needs to be deployed in production first (hence why this ticket is stalled).

In T357575#9877867, @Jdlrobson wrote:

note this issue was only occurring in the night theme where the link colors are different (so I can see why that was a confusing comment I posted).

I see. Your screenshot showed so little of the page that I didn’t notice it’s night mode (it has only a tiny black line on the right) – and the next screenshot is clearly day mode, adding to the confusion.

The links in extracted is working now after a template change: https://commons.wikimedia.org/w/index.php?title=Module:Information&diff=prev&oldid=881177359

Thanks, but I’m not sure if it’s the right place for this.

• On the one hand, {{Extracted from}} can appear outside of the information, so it should definitely have notheme on its own and not rely on being embedded in any particular template (until it’s made actually night mode compatible). So far clear.
• On the other hand, the content of the information template may (or may not) already be night mode compatible. If it is, unconditionally adding notheme to the embedding template worsens the situation. If it relies on a mix of CSS variables and skin-theme-clientpref-*-dependent custom styles, adding notheme worsens the situation a lot.

In T357575#9894120, @Jdlrobson wrote:

This may need a fix for images with transparent background e.g. https://en.wikipedia.org/wiki/Gas_flare

I don’t see any image with transparent background on that page. If you mean https://commons.wikimedia.org/wiki/File:FlareStack_System.png, it has an opaque gray background.

Test Result - PROD

Status: ✅ PASS
Environment: PROD
OS: macOS Sonoma 14.3
Browser: Chrome 126
Device: MBA
Emulated Device: NA

Test Artifact(s):

Test Steps

1. https://en.wikipedia.org/w/index.php?title=File:At_Wikimedia_Hackathon_Athens_(MP)_2023_001_(cropped).jpg&vectornightmode=1

Appears in dark mode: