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)

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?

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!

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

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

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

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

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.

This looks good to ship from my perspective, with the caveat that many issues will still need to be fixed on wiki.

Likewise please let us know what date you want to deploy this!

We can do this one this week. Leaving in the sprint for now.