Talk:Reading/Web/Accessibility for reading/Archive1

font-size 1em

originally posted on Talk:Reading/Web/Desktop Improvements

Hi

Thanks a lot for your work!

Comparing vector-2022 with minerva I think vector-2022 is much more mature and better. But there are some details in minerva which I prefer. Most of all the font and font size of the text.

So: Why not to change font-size in .vector-body to 1em (or 100%)?

I think that would be a uge improvement in readability and look. Even headings would still be fine with the current size.

But I have not tested it in different devices, browsers, screens etc. so maybe there is a reason why the font size is reduced in default vector-2022? Bwana.elias (talk) 14:58, 27 September 2023 (UTC)

Hello @Bwana.elias. It's interesting that you reach out to us about this now! I'd like to encourage you to read the project page this very talk page is connected to. On it, we explain why and what we would like to change. (Spoiler alert, it's not just about font size, but also information density, so for example line height!) SGrabarczuk (WMF) (talk) 15:23, 27 September 2023 (UTC)

Hi @SGrabarczuk (WMF) thanks for pointing me here. Sorry, I have just registered at wikipedia/mediawiki for the first time and thougt I start discussing immediately :)) Will have a look at the project page. BR Bwana.elias (talk) 16:03, 29 September 2023 (UTC)

"Share my preferences"

A question about translation: This text mentions the possibility to click the "share my preferences" button. Where is the label of this buttion translated? Amir E. Aharoni {{🌎🌍🌏}} 14:56, 6 October 2023 (UTC)

Hey @Amire80, it's in the translatable, although hidden, part of Reading/Web/Accessibility for reading/Community prototype testing. SGrabarczuk (WMF) (talk) 15:01, 6 October 2023 (UTC)

How do I close the "Wikimedia reading tool" window?

I just wanted to have a look at this when I saw the banner in en.Wikipedia. Now I cannot close the window, because there is no "cancel" option. A look at "Preferences" did not help either. There must be a way to cancel the survey and to close the window! Kallichore (talk) 14:34, 9 October 2023 (UTC)

I have the same problem. Jc3s5h (talk) 15:25, 9 October 2023 (UTC)

Me too! I was happy to try it, but I would really appreciate being able to remove it! Lajmmoore (talk) 13:49, 10 October 2023 (UTC)

Hey @Kallichore, Jc3s5h, and Lajmmoore: thanks for reaching out to us :) In the widget, right above the buttons, there's a sentence "Click here to remove this tool." In addition to that, soon we'll disable this tool on English Wikipedia because we have plenty of replies already. I hope this helps! SGrabarczuk (WMF) (talk) 17:00, 10 October 2023 (UTC)

Thanks, the button worked for me. --Kallichore (talk) 18:09, 10 October 2023 (UTC)

Why not add customizable appearance?

In the text it says "In particular, we're not planning on providing sliders or individual settings for font size, line height, or spacing.", and I just can't help but wonder why? Wouldn't this benefit people who would want to customize it to their needs? Projects like wikiwand do it and it works pretty well for them, so I can't see the reason why not. But other than that Vector 2022 is awesome, thank you for the work you do. WanderingMorpheme (talk) 22:21, 12 October 2023 (UTC)

Hello @WanderingMorpheme! I'm sorry for not answering earlier! At first, I wasn't 100% sure how to answer, and it took me too long to ask my colleagues. I'm embarrassed because it's a very good and a very basic question 🤦

So the answer is:

We will change the default to improve the basic state of things. We will add some customizations for people to adjust the text to their needs. But there's a limit. By introducing options, we're adding permutations, and we should be careful about those.

(Just in case anyone reading this is not familiar with the term, a permutation is a specific arrangement of options. If there are three font sizes, three font families, and three colors for each, there are "all of the sudden" 27 permutations.)

We have adjustable interface with lots of possible permutations already. Everything we do, we need to test against all the permutations we're responsible for. Adding too many options to choose between results in, for example: 1. difficulty of maintaining what already exists, 2. reluctance to add more features. So it's a matter of some balance, how many great permutations do we really want to be responsible for.

I hope this helps! SGrabarczuk (WMF) (talk) 02:08, 8 November 2023 (UTC)

This was a great answer, thank you. WanderingMorpheme (talk) 02:14, 8 November 2023 (UTC)

Dark mode setting retrieved from system

Hello,

I red this article https://diff.wikimedia.org/2023/11/24/dark-mode-is-coming/ and I would just like to mention that I would like an automatic dark mode if the user’s operating system is configured on dark mode. So it would automatically follow the system’s setting.

This way, any logged-out user would have a setting that would most probably be his/her best choice. Having to log-in or even worse create an account to set a dark mode is not satisfying in my opinion.

In the article, a "toggle" is mentioned but I would prefer an automatic setting without user action. Therefore, no "white flash" would be displayed at the loading of a web page.

I think technically it would use this but I am not an expert: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme

Thanks a lot

Sensas817 (talk) 19:03, 27 November 2023 (UTC)

"Night mode" is a poor choice

I saw someone say this somewhere else, and I wholeheartedly agree. I associate "night mode" with the ability to adjust the hue to warmer colors and reduce blue light (whose efficacy in reducing eye strain is disputed but which Android/macOS/iOS/Windows nonetheless provide). What you're building is a dark mode. Calling it a night mode is at best ambiguous and confusing. Nardog (talk) 00:38, 29 November 2023 (UTC)

@SGrabarczuk (WMF): Where/how was the decision to use "night mode" in lieu of "dark mode" made? What is the rationale? Nardog (talk) 13:25, 30 November 2023 (UTC)

Hi there,

Thanks so much for your feedback. I agree that using the label "Night mode" would create some confusion with "night shift"-style colour shifting features in other programs. The actual term "night mode" is only something that we're using in project documentation. Those words don't appear anywhere in the UI that we're working on, as you can see in this Phabricator ticket for implementing the appearance settings interface copy. We call it "Color: Night/Day" in the interface.

The reason we chose Night/Day instead of Dark/Light was primarily for translation reasons. Based on languages spoken on the team, Night/Day is more translatable and has fewer potentially problematic value connotations that we were aware of. I hope that helps to clarify the rationale behind the decision. Thanks again for your feedback! JScherer-WMF (talk) 22:30, 5 December 2023 (UTC)

Color vs. colour

It's interesting to see "colour" in the new theme menu prototype. It'd be cool if it followed w:Template:Use British English or other English varieties templates. Or maybe better to just find another word that sidesteps the issue. {{u|Sdkb}} ^talk 17:54, 15 December 2023 (UTC)

Hey @Sdkb! Thanks, this spelling may indeed be confusing. I doubt it will make it on production, though. The reason why it is in the prototype in the first place is because our designer is based in Canada :) But the spelling on prod seems to be AmE. SGrabarczuk (WMF) (talk) 19:29, 15 December 2023 (UTC)

Wonderful update!

For years, I've been using the Chrome browser zoom feature at 150% or so, in order to comfortably read content on Wikimedia sites. Now that you've added the built-in accessibility features for text size and page width, I am able to reset Browser Zoom to 100% default, and the native tool works God's miracles! Hooray! Elizium23 (talk) 00:44, 17 December 2023 (UTC)

Cog

I like the old "Cog in the bottom right" design much better, especially when logged out and unpinned, where this looks quite jarring. Is there a way to combine the two designs, like make a cog styled like the width toggle in the lower-right that brings up this menu which can be pinned, plus the width section is disabled with a relevant help message when it wouldn't do anything? Aaron Liu (talk) 22:01, 12 January 2024 (UTC)

Unfurl all links

also New Vector sucks for screenreaders. However, there's a beta feature for New Vector called Accessibility for Reading. Right now it is really basic, but I really wish that an option to display all links will be available there.

— @CactiStaccingCrane, Reply to @Moxy

Aaron Liu (talk) 14:24, 14 January 2024 (UTC)

Thank you so much for putting my comment here :) CactiStaccingCrane (talk) 14:25, 14 January 2024 (UTC)

Pure-black dark mode

Very excited to see that dark mode will be coming eventually - I read about it in the enwiki Signpost today. One concern, however: Too many dark modes on websites use pure black as the background colour. This also causes eyestrain and personally causes headaches, especially with pure white text on top. One solution could be to have two different dark modes, one with pure black and one with a shade of dark gray - that then accomodates those who prefer the pure black. Suntooooth (talk) 21:32, 24 December 2023 (UTC)

Hey @Suntooooth, thank you for your comment. I haven't talked about this with the team, but I guess you're very right and this is a known issue. I believe the plan is to use some very dark color, most likely from an existing palette, but not   black. Anyway, I've let Justin, our designer, know that you've raised this point. SGrabarczuk (WMF) (talk) 18:50, 3 January 2024 (UTC)

Pure black has theoretical advantages for OLED and other emissive displays where black pixels draw little power, if any. But I agree with Suntooooth that it can look harsh. I think you should offer both. The Wikipedia iOS app has white, sepia, and two blacks. As does Reading Mode in iOS Safari. – Pelagic (talk) 22:03, 1 February 2024 (UTC)

Thanks for the feedback @Suntooooth! We do not intend to use #000000 as the dark background in the new Night colour palette. I agree that it's harsh and results in a poorer reading experience. JScherer-WMF (talk) 20:40, 6 February 2024 (UTC)

TOC numbering

Some might want this to also be able to add section numbers to the TOC.. Aaron Liu (talk) 15:44, 23 January 2024 (UTC)

Tracked in Phabricator
Task T307316

Thanks @Aaron Liu. Do I understand correctly that you're pointing at the known request for a change in the TOC in Vector 2022? SGrabarczuk (WMF) (talk) 16:50, 21 February 2024 (UTC)

As a person who doesn't like TOC numbering, I'm saying that a toggle for it could be added in Accessibility for reading. Aaron Liu (talk) 16:54, 21 February 2024 (UTC)

Font size not working in Chinese/Japanese wikipedia

Tried this feature, but found that the font size adjustment doesn't work in Chinese wikipedia. This is because the font size of Chinese wikipedia is designated as 15px, and the designation has higher priority than the font size adjustment.

I think the default 15px of Chinese wikipedia is an optimization for hanzi, so I checked Japanese wikipedia which also uses kanji (=hanzi). It turns out, the same applies to Japanese, the default font size is also 15px, and font size adjustment doesn't work as well. Tcbbd (talk) 16:08, 21 February 2024 (UTC)

Thanks @Tcbbd for this message, I'll let my team mates know! SGrabarczuk (WMF) (talk) 16:11, 21 February 2024 (UTC)

@SGrabarczuk (WMF) and Tcbbd: Hello, the reason why it is not working is because of the conflict between the default gadget "大字體 (large font)", which increase the font size, and the beta feature. You can disable this gadget in your preference. I will pass this issue to Chinese Wikipedia community. Thanks. SCP-2000 (talk) 17:14, 21 February 2024 (UTC)

Line height in Larger size (iPad)

First thing I noticed after turning on the beta is that Larger size feels very dense on an iPad.

Haven't yet tried it on other platforms to find out if this is the general issue that Nclm posted above, or if it's more pronounced on the tablet because of V2022's lack of responsive scaling.

I agree that there should be less relative leading at larger point sizes; the current Larger needs just a little more.

Perhaps there could be a separate selection for tight / medium / loose.

– Pelagic (talk) 21:54, 1 February 2024 (UTC)

On desktop Large doesn't seem tight, just really big. Also on tablet, setting the reading size to larger doesn't help with font size in the classic wikitext editor. Pelagic (talk) 09:54, 9 February 2024 (UTC)

Thanks for your feedback here @Pelagic! You're not the only one who has been giving feedback along these lines. As I mentioned above in the conversation with @Nclm, I've refactored the designs to have more breathing room going forward. Keep an eye on the phab tickets and please try it out again on your iPad when they've been released (should be next week or the week after). I'd love to hear what you think of the refactored designs. Thanks again! JScherer-WMF (talk) 13:32, 1 March 2024 (UTC)

Line height

Testing now the version on the French Wikipedia. Great feature, thanks!

For the font size option however, the line height for “standard” and “large” is far too tight. I would love to set it to “standard” for my own use, but the readability is affected by that low leading, so I switched back to “small”.

By the way, there is a major translation mistake for the “type size” label (“type” translated as if to mean “a kind”, not as “typography”). I fixed it, I think, on TranslateWiki (not sure it is the right place for that), but I don’t know when it will be updated on the live wiki? Nclm (talk) 19:50, 8 December 2023 (UTC)

More specifically, I see it is set to 1.5 in “standard”. After trying out, I think values around 1.75 are much more pleasing typographically. Nclm (talk) 20:12, 8 December 2023 (UTC)

Thanks so much for your feedback! And thank you for catching that translation mistake! The decision to have the line-height at 1.5 was made for several reasons:

1. This is the recommended ratio that we saw in the academic literature on readability that we reviewed.
2. In the prototyping exercise we did with community members, line heights tended to get relatively denser as the font increased in size.
3. We wanted to make sure that the increased font-size wouldn't increase the height of articles too much and create a lot more scrolling for folks who are scanning for specific information.

If you're a frequent reader, any change to the typography will probably feel a bit strange at first because it's different that you're used to. That effect should also become less prominent with time.

Thanks again for your feedback and for reaching out! JScherer-WMF (talk) 22:14, 14 December 2023 (UTC)

Hi, thanks for your answer!

I have now been reading in “Standard” for a couple of weeks and it is still very tight, and feels more tight than most other content I am reading online.

Line height is only one factor, and the exact design of the typeface used (and its x-height, opening of lowercase letterforms, etc) also has an effect here. Since you don’t have, I think, control on the exact font (I believe you are using the default system sans-serif), it might be that text can appear tighter on some systems than others.

If you could still consider setting it a tiny bit higher, possibly 1.6, that would already make a lot of difference already.

1.6 is for instance what Medium is using. I had a look at a few newspapers and blogs, and I see ranges between 1.5 and 1.8. Again, it depends on the type family :) I think 1.5 could work if you had control over the font and it was the right one for this leading size, but you’ll be a bit safer with something a little more generous.

It would also be interesting the consider different line heights depending on the column width: the longer the lines, the harder it is to “catch” the next line.

Nclm (talk) 10:25, 20 December 2023 (UTC)

Thank you so much for your collaboration on this. I've reviewed your feedback, as well as lots of feedback on the recent changes in Minerva along these lines. I think I over-applied the "maintain or increase density as a scanning affordance" insight from the research, and I've refactored the designs in Vector and Minerva to have more breathing room. In the case of the Large size on Vector, to your original comment, the changes are especially beneficial. So thanks again for your feedback! JScherer-WMF (talk) 13:27, 1 March 2024 (UTC)

Sounds great, thank you very much! :) Nclm (talk) 19:10, 2 March 2024 (UTC)

Nocny/ciemny

@SGrabarczuk (WMF) przyjąć nazwę "ciemny" czy "nocny"? wargo (talk) 09:25, 20 March 2024 (UTC)

(Przeniosłem tu, bo jedną stronę dyskusji każdemu łatwiej obserwować i możemy prowadzić wielojęzyczne dyskusje.)

Dobre pytanie. Wobec angielskiej wersji jesteśmy zdecydowani, że na razie "nocny" i zmienimy to, jeśli testy wykażą, że "ciemny" jest bardziej zrozumiały. Ale w innych językach jesteśmy bardziej elastyczni, nie robimy dla nich testów i godzimy się na "ciemny", jeśli jest standardem. Moje tłumaczenie na "ciemny" jest 100% "na czuja" - bo wydaje mi się, że ta wersja jest bardziej popularna. Ale w Google'u "nocny" ma więcej wyników. Więc ostatnio trzymam się bardziej "nocnego". SGrabarczuk (WMF) (talk) 11:44, 21 March 2024 (UTC)

Signature disabled

My user signature was recently disabled on English Wikipedia (it appears to still be working here, oddly). The preferences page indicates that there's a lint error related to night mode, but the actual documentation page says it's still undergoing testing and has a priority level of zero. I don't plan for my signature to display any differently in night mode — it'll still be white text on a dark background. It's not clear how I could fix this error, especially while staying under the 255-character length limit, so I'd appreciate it if whoever enabled this requirement could please roll it back until it's developed better. Sdkb ^talk 19:37, 21 March 2024 (UTC)

I have filed task T360797 for a related nesting error. Jonesey95 (talk) 16:53, 22 March 2024 (UTC)

@Sdkb: to fix this you need to add "color:inherit" in front of "background:linear-gradient" that should fix the issue (this won't change anything about the appearance). We are recommending that whenever background is defined, color should also be explicitly define so that night mode doesn't alter the color (in a similar way to how the notheme class has been used for apps).

I don't think this should trigger an error for signatures in the way it does so I've raised phab:T360796 to make sure this is reconsidered. Jdlrobson (talk) 16:54, 22 March 2024 (UTC)

This should now be fixed. Thanks for the report!

Note: this will still be flagged by the linter and this is intentional. I have clarified this on mw:Help:Lint_errors/night-mode-unaware-background-color#How_to_fix. Jdlrobson (talk) 18:26, 22 March 2024 (UTC)

Wikilinks in blue

Hello guys! We are also introducing dark mode on the Serbo-Croatian Wikipedia and I am honestly really excited about it. A colleague on our project told me that the wikilinks appear, as usual, in blue but in dark mode blue and black colour tend to blend together and make reading more tiring. Have you encountered the same problem? Is there any way to do something? Maybe, bringing the link to a shade of light blue or even pink... Cheers--Inokosni organ (talk) 22:55, 25 March 2024 (UTC)

Thanks @Inokosni organ. You're not the first one to point at this issue. @Msz2001 noticed that, too. I'll let our designer know. SGrabarczuk (WMF) (talk) 23:55, 26 March 2024 (UTC)

Thank you, Szymon! --Inokosni organ (talk) 00:00, 27 March 2024 (UTC)

@Inokosni organThanks for flagging this! It's a very valid concern. The answer to your question is yes, we have considered it. The links are a different shade of blue to compensate for the dark background. We built a new colour palette to make sure that all of the colour combinations in dark mode have at least a 4.5:1 contrast ratio per Web Accessibility standards. In some cases, the dark mode version of the pages is more accessible than the light mode version. JScherer-WMF (talk) 15:39, 27 March 2024 (UTC)

About Accessibility for Reading

Why doesn't the Japanese Wikipedia write "About Accessibility for Reading" in Japanese? Ghost caterpillar (talk) 22:28, 21 March 2024 (UTC)

Hello @Ghost caterpillar, thanks for this question. I'm not sure I understand you, though. Are you asking about the Japanese translation of the page Reading/Web/Accessibility for reading? Or do you mean something on Japanese Wikipedia? SGrabarczuk (WMF) (talk) 22:37, 21 March 2024 (UTC)

I'm sorry. I'll paste the link so you can move it.[1] Ghost caterpillar (talk) 22:48, 21 March 2024 (UTC)

Thanks @Ghost caterpillar. It would be good if this was fixed indeed :)

This is in English because it hasn't been translated into Japanese yet. Any Japanese speaker can add the translations here. Translatewiki is not a Wikimedia wiki, so a new account needs to be created first. SGrabarczuk (WMF) (talk) 16:33, 22 March 2024 (UTC)

Does translatewiki mean translation software (?)? Ghost caterpillar (talk) 23:23, 22 March 2024 (UTC)

Translatewiki is a wiki where the interface is translated. SGrabarczuk (WMF) (talk) 23:47, 22 March 2024 (UTC)

I got off topic. sorry.

Should I ask that it be written in Japanese after all? Ghost caterpillar (talk) 23:57, 22 March 2024 (UTC)

That's absolutely ok :) If you are a Japanese and English speaker, you can create an account on translatewiki, and add the translations yourself. Another way would be to ask someone else to do that. These translations are done by editors. SGrabarczuk (WMF) (talk) 00:05, 23 March 2024 (UTC)

Who should I ask? Ghost caterpillar (talk) 00:12, 23 March 2024 (UTC)

I made a mistake in the letters. sorry.

Because I'm using translation. Ghost caterpillar (talk) 00:15, 23 March 2024 (UTC)

Should I ask the administrator to fix it? Ghost caterpillar (talk) 00:12, 26 March 2024 (UTC)

Hey @Ghost caterpillar. No, anyone can create an account on translatewiki, not only administrators. So anyone speaking both Japanese and English could help. SGrabarczuk (WMF) (talk) 23:57, 26 March 2024 (UTC)

yes. Understood. Ghost caterpillar (talk) 09:33, 28 March 2024 (UTC)

I'll fix it someday. Thank you very much. Ghost caterpillar (talk) 09:35, 28 March 2024 (UTC)

Why 'night mode' when it's called 'dark mode' everywhere else?

Hello

@SGrabarczuk (WMF): moved page Recommendations for dark mode compatibility on Wikimedia wikis to Recommendations for night mode compatibility on Wikimedia wikis with the reason "change of the term", but otherwise it is called Extension:DarkMode, Manual:Dark mode, Category:Dark mode, etc.

Also the HTML class is named "skin-night-mode-1", while "light" and "dark" seem to be normalised : W3C and MDN.

This is a bit confusing, and without a good reason, it should be avoided.

Regards, Şÿℵדαχ₮ɘɼɾ๏ʁ 01:48, 27 February 2024 (UTC)

Please see Reading/Web/Accessibility for reading/Frequently asked questions. Jdlrobson (talk) 01:56, 27 February 2024 (UTC)

Ah ah ah, I was expecting that it was because some people were afraid of the term "dark". Stop cringing, "dark" is neutral and just means "lack of light". Od1n (talk) 02:02, 27 February 2024 (UTC)

Meanwhile, "day" and "night" sound inappropriate to me, as there is no strong relationship between the color theme and the time of the day. Most people set a theme and stay on it, whether it's day or night. And more simply, colors can be "light" and "dark", but colors are certainly not "day" or "night"… Od1n (talk) 02:23, 27 February 2024 (UTC)

@Jdlrobson : how many people decided that? You are the author of the page you quote, and I cannot find a single mention of this alleged issue anywhere.

If W3C, Firefox, Google [2], Microsoft [3], etc. choose "Dark", it is not likely to be a problem.

Why shouldn't Wikimedia follow the norm, given the confusion it will create?

A wider consultation needs to be carried out, because I think this is the decision of only a few people.

Regards, Şÿℵדαχ₮ɘɼɾ๏ʁ 03:30, 27 February 2024 (UTC)

Hey @SyntaxTerror and @Od1n, thanks for your curiosity! I think you're right, "dark mode" is sort of a standard. But we wanted to try the day/night option (see the updated answer to the question What is the difference between night mode and dark mode?). We're currently testing the night/dark labels' discoverability and usability. If the results are conclusive, I guess we'll just follow them. So bear with us, we'll let you know when we get them! SGrabarczuk (WMF) (talk) 22:40, 28 February 2024 (UTC)

@SGrabarczuk (WMF) thanks for your patronising tone! But where is the discussion leading to this choice ?

Give a link to it instead of posting the same link as above, leading to a page that seems to have been written only by Jdlrobson.

Or prove me that a single black/brown person has already found this offensive, in good faith ? Şÿℵדαχ₮ɘɼɾ๏ʁ 23:46, 28 February 2024 (UTC)

@SyntaxTerror, I didn't mean to sound patronizing, my apologies.

Taking two steps back, I know you're experienced, but I'm not sure how much you know about the Accessibility for reading project (A4R). In your first message, you pointed at an extension, so perhaps you're new to our little world (or context) of the Web team and its projects.

In general, from our perspective, the situation is as follows: this page and A4R are related because both belong to the Web team. Jon is in fact the tech lead for this team (Jon (WMF)), and when he's editing this page, he's doing his job. We update and refer to the recommendations for the purposes of the A4R project. If I'm not mistaken, the night mode built as part of A4R will marginalize the extension. (Edit: at least on the Wikimedia wikis; I'm not talking about third-party wikis using skins other than Vector 2022 and Minerva.) So the word in the page title follows the decision made for A4R.

But wondering how you may have found this page made me think: maybe the recommendations pertain to the concept of dark mode and may work just equally well with gadgets, the extension, browser plugins, and our latest feature, the only official night/dark mode for MediaWiki for desktop and mobile web. If that's true, I might move this page back.

But I wouldn't be doing that just yet because right now, we're trying to limit confusion. The team made a decision ("night" instead of "dark") solely for the purposes of A4R. We're not tied to it. We're now working on the FAQ for that project, and the (updated and corrected) direct answer to your question was given by our designer. In the FAQ, I've linked to the relevant Phabricator task, too.

Does this address your concern better? Thank you, SGrabarczuk (WMF) (talk) 00:35, 29 February 2024 (UTC)

There is no discussion taking place in that Phab link, so I doubt it. Let me ask this from me too: Where can I see the discussion that led to this decision? Nardog (talk) 04:35, 29 February 2024 (UTC)

I think that accessibility implies "understandable by the broadest audience", so I would still opt for light/dark, as these terms are the most common (and even the "canonical" ones), and those that describe the most exactly (day and night being just a visual comparison). And again, there is no problem with the word dark, the fear of using is what causes the fear actually. Od1n (talk) 06:37, 2 March 2024 (UTC)

Also, if it's problematic in some languages, why not just let the translators for those languages choose whatever is more appropriate just in those languages? Why bend over backwards and retroactively change the English term, at the sacrifice of that which is more intuitive and easily understood? Nardog (talk) 07:59, 2 March 2024 (UTC)

@Jdlrobson, Nardog, Od1n, SGrabarczuk (WMF), and SyntaxTerror: Note: I moved this discussion from Talk:Recommendations for night mode compatibility on Wikimedia wikis to here, since it is unrelated to "recommendations for night mode compatibility". Thanks. SCP-2000 (talk) 04:41, 6 March 2024 (UTC)

FYI The relevant discussion #"Night_mode"_is_a_poor_choice. SCP-2000 (talk) 04:43, 6 March 2024 (UTC)

As a native Chinese speaker, I fully agree that "night" mode is more translatable compared to "dark" mode. However, from the readers' point of view, "night" mode may cause confusion for them as it is not a common term and has other meanings, such as dim light and blue light reduction. Since "dark mode" has already been used in several browsers and even in our Wikipedia apps, which have multiple language versions, I believe there will not be excessive difficulties in translation.

Weighting up the benefit and disadvantages, I would prefer to see "dark" mode rather than "night" mode in the interface. Thanks. SCP-2000 (talk) 07:07, 6 March 2024 (UTC)

Agreed with @SCP-2000: "dark/light" mode seems to be standard across my OS, browser, other website preferences, and most desktop and mobile apps that I use (which is independent of how that is translated in other languages!). I realize that the mobile app has has a 'night' mode for some time, but that's definitely non-standard :) . Sj (talk) 22:58, 31 March 2024 (UTC)

"void" displays on translated pages

hej @SGrabarczuk (WMF):  ! Forma void jakos dziwnie wyskakuje na stronie FR oraz inne strony tlumaczone. Mozna poprawic ? Dzieki.

..wasze pomysły wdź i podziel się z nami swoimi przemyśleniami! 2 Wprowadzenie# {{void|1= === Dlaczego nasza praca nad tym jest ważna ===}} W ciągu ostatnich kilku

--Christian 🇫🇷 FR (talk) 17:45, 17 April 2024 (UTC)

Automatic image adaptation

There is a site called https://invertornot.com/ that could be useful in automatically adapt images. It uses a small neural network (16MB) to classify images into whether they should have their hues inverted (for graphs or images of text, for example) or instead just be slightly darkened (for photographs of people or natural landscape). The API and model are open source and can be self-hosted - see https://github.com/mattismegevand/invertornot.

Found out about it on https://news.ycombinator.com/item?id=39821632 today, which also has other useful tips, including using the CSS `filter: hue-rotate(180deg) invert();` for inverting images instead of having the API invert them for you. Telotortium (talk) 21:48, 26 March 2024 (UTC)

Thanks for sharing! I imagine this will be useful at some later date.

For the first release we will not be altering images in the night theme and deferring to editors as our concern is that any kind of image alteration could lead to misguiding readers by changing meaningful colors. There is more on this can be found on Reading/Web/Accessibility_for_reading/Frequently_asked_questions. Jdlrobson (talk) 03:25, 2 May 2024 (UTC)

Extension:Score

Another thing I noted: music written with the score extension (Lilypond) is unreadable in night mode, see e.g. en:99 Bottles of Beer. XanonymusX (talk) 07:30, 29 April 2024 (UTC)

thank you for the report! Phab:T363964 Jdlrobson (talk) 03:19, 2 May 2024 (UTC)

Fixing w:en:Module:RoundN

Out of ideas for fixing this. Most of the colors can be inverted, except for the gold, silver and bronze colors of the 1st, 2nd, and 3rd place boxes that can be enabled. Is there a way to determine with Lua whether night mode is enabled? If that's possible it could be used to set bgColor.head andbgColor[4]. Snowmanonahoe (talk) 20:33, 1 May 2024 (UTC)

This dark mode stuff has made me despise modules that throw all their CSS straight into the Lua. Snowmanonahoe (talk) 20:34, 1 May 2024 (UTC)

thanks for flagging! I (and others) can take a look over the next few days! Jdlrobson (talk) 03:28, 2 May 2024 (UTC)

With regards to detecting night theme: Associating the module with a stylesheet and adding classes to difficult to style elements will probably give a lot more control here. Jdlrobson (talk) 03:30, 2 May 2024 (UTC)

@User:Snowmanonahoe I was going to suggest adding the notheme class but the template doesnt seem to be accessible in the standard theme (e.g. blue links on gold background). Is fixing this in the normal theme also a goal here? Jdlrobson (talk) 10:28, 2 May 2024 (UTC)

• Where is the notheme class added, the whole template? What would that do?
• I wasn't aware of the blue-on-gold being inaccessible. It seems like fixing the problem would require making the gold quite a bit lighter so I'm unsure. Does #FFED7A still look like "first-place gold" to you?

Snowmanonahoe (talk) 11:37, 2 May 2024 (UTC)

Well actually, the link color could be changed to Vector's #0645ad. Surprising that makes so much of a difference. Color contrast is weird. Snowmanonahoe (talk) 11:44, 2 May 2024 (UTC)

appearance sidebar keeps popping up every time i refresh or open a new page

it used to not do that, i would hide the sidebar once and never see it again Brawlio (talk) 01:27, 3 May 2024 (UTC)

You can click "hide" next to appearance to collapse it. That should then close it for future page views. Jdlrobson (talk) 07:19, 3 May 2024 (UTC)

that's how it used to work, but not anymore, it reappears every time i open a new webpage or refresh the current one Brawlio (talk) 17:58, 3 May 2024 (UTC)

Zebra tables

Hi! I’m working on improving some templates on dewiki for the night mode. I was wondering: tables using the class ‘zebra’ seem to automatically get a zebra scheme also in dark mode, but templates using individual variations of zebra (through TemplateStyles) with different class names don’t. Is there an easy way to imitate the dark mode zebra styles also for templates? XanonymusX (talk) 06:49, 29 April 2024 (UTC)

Hey could you file a ticket on Phabricator with an example? If you can I will look at this over the weekend but right now am not 100% sure what you are referring to. Jdlrobson (talk) 03:20, 2 May 2024 (UTC)

I think I have figured it out (there is no universal solution, as we are talking about individual TemplateStyles). Basically, Zebra in night mode switches between --background-color-base and --background-color-neutral-subtle. I am using those variables for my night mode styles now. XanonymusX (talk) 15:25, 4 May 2024 (UTC)

Extension:Math

Tracked in Phabricator
Task T360691

...doesn't work with night mode (example). Snowmanonahoe (talk) 02:38, 8 May 2024 (UTC)

phab:T360691 (still need to open a dedicated ticket for this one. Jdlrobson (talk) 00:11, 17 May 2024 (UTC)

Night mode checker not updated for non-en wikis

Hi, it seems like the night mode checker hasn't been updated since a week, for example for dewiki, and is only showing 50 pages. hgzh 09:58, 15 May 2024 (UTC)

Thanks for flagging! I will look at this today! Jdlrobson (talk) 18:11, 15 May 2024 (UTC)

I am still looking into this. I got a new request to run the checker for all wikipedias which is proving more difficult than expected :) Jdlrobson (talk) 00:09, 17 May 2024 (UTC)

How to disable the dark mode

How can I disable the dark mode, without disabling Vector 2022? Vestrian24Bio (talk) 02:42, 16 May 2024 (UTC)

@Vestrian24Bio: Hello, you can change from dark mode to light mode from the "Appearance" menu on the right (it look like this). Thanks. SCP-2000 (talk) 03:11, 16 May 2024 (UTC)

Okay, Thanks! Vestrian24Bio (talk) 03:24, 16 May 2024 (UTC)

Night Mode issue on "Accessibility for Reading (Vector 2022)"

Hello,

I was using the beta version of Vector 2022. But today when I was checking Wikipedia (main page and some internal pages) I noticed that "night mode" is activated there, without the option of night mode (or dark mode) being activated in Preferences/Gadget!

Regards Mrt.rahimzade (talk) 08:20, 16 May 2024 (UTC)

Hello @Mrt.rahimzade. That's correct. Yesterday evening European time, we introduced the color options (Automatic, Light, and Dark) as part of the Accessibility for Reading beta feature. Anyone who was using the beta feature was supposed to see the new color options.

Originally, our intention was to make Light the default (and anyone who'd want to change that could select Automatic or Dark). But apparently, we made Automatic the default. This got many people confused, and we'd like to apologize for that.

At the same time, we encourage everyone to try out dark mode on different pages. Here you will find detailed instructions on how to make templates and other community-written code dark mode-friendly. (In particular, focus on the part "If you want to identify problems beyond the top 100 articles.")

Thanks, and apologies again! SGrabarczuk (WMF) (talk) 13:22, 16 May 2024 (UTC)

Thank you, Mr. Grabarczyk, for taking the time to explain this matter, your work is wonderful and I hope you will do well! Regards. Mrt.rahimzade (talk) 17:25, 16 May 2024 (UTC)

Night mode checker: "mobile" and non-default vector skin

Starting today, the night mode checker seems to be using the vector dark mode and not the minerva night mode. This has two problems. First, the section header still reads "Mobile", and it should either be changed to "Desktop", or there should be a separate section for mobile. Second, pages are opened with ?vectornightmode=1, but that doesn't do anything if vector22 is not the default skin, which is the case for (at least) itwiki, ruwiki, and dewiki. Adding &useskin=vector-2022 to the query string should be enough to fix this. Daimona Eaytoy (talk) 21:30, 16 May 2024 (UTC)

Thanks for flagging the legacy Vector default skin. I am overhauling a few things with the checker here and hopefully will be up and running again by the end of the week. Jdlrobson (talk) 00:07, 17 May 2024 (UTC)

Reading/Web/Accessibility for reading/Updates structure change?

It was unusual to see new updates being added to the Reading/Web/Accessibility for reading/Updates itself rather than transcluded as before. Is it how it will be from now on? I rather like to have chunks of news on separate subpages. Ата ^(talk) 17:18, 16 May 2024 (UTC)

Thanks @Ата. Some updates were put on separate pages because we were posting them as messages on village pumps. The latest update is directly on the /Updates page because we didn't meant to post it on village pumps, and we have posted/will post other (longer) messages instead. I hope this makes sense. What makes you think sticking to the subpage "model" is better, though? I'm curious. Thanks! SGrabarczuk (WMF) (talk) 17:47, 16 May 2024 (UTC)

It's a pleasant moment when the page reaches 100% of translation, and if there is new content added later, percentage falls and it feels as if someone has just ruined my achievement 😅

Thank you for explanation, I'm ok with any model. Ата ^(talk) 11:51, 17 May 2024 (UTC)

Night mode on mobile and desktop

Why there is different options of night mode on mobile and desktop? KuldeepBurjBhalaike ^(Talk) 06:38, 16 May 2024 (UTC)

Hello @Kuldeepburjbhalaike, thanks for reaching out. What difference between night mode on mobile and desktop do you mean? SGrabarczuk (WMF) (talk) 13:13, 16 May 2024 (UTC)

thanks for the reply @SGrabarczuk (WMF): if i turn on dark mode on desktop it applies only for desktop site of that wiki and i need to turn on the dark mode for mobile web in settings and vice versa for turning it off. will it be good option to turn on/off at once from desktop site or mobile site? KuldeepBurjBhalaike ^(Talk) 13:23, 16 May 2024 (UTC)

Hello @Kuldeepburjbhalaike. Our team has discussed this and this is what we think:

First of all, we do see the value in making connections between different options. See #Global preferences for dark mode.

Mobile and desktop devices may be used in different environments and in different ways. For example, mobile devices are sometimes used in very low-light environments. It makes sense not to assume that best settings for mobile would be best for desktop and vice versa. Alternatively, if we did connect those, the user would have to switch the color scheme each time they would refresh a page on a different device. That's where the team sees the core problem with that scenario.

Yes, it may be painful to change settings for mobile and desktop separately. But according to the team, this is less painful than having to change the settings back on either device.

Tell us what you think. Thank you! SGrabarczuk (WMF) (talk) 23:04, 20 May 2024 (UTC)

hi @SGrabarczuk (WMF): , i have been using dark mode (gadget) on pawiki, enwiki, and wikidata for a long now and i think this thing is very useful to turn on or off dark mode from a single button across devices and sites (desktop and mobile). it's very handy to me maybe not to other users. yeah, i know the dark mode works different on different sites (desktop and mobile) but it could be turned on and off from a single click thats what i'm thinking :) KuldeepBurjBhalaike ^(Talk) 01:16, 21 May 2024 (UTC)

I typically use dark mode on my phone but not on my computer, because they have different types of display and I use them under different lighting conditions. An ability to toggle it across sites makes some sense but not across devices. Nardog (talk) 10:38, 23 May 2024 (UTC)

Dark mode clashing with Preferences > Gadgets > Appearance > Dark Mode Toggle and Utilitiy modules > Core styling for dark mode gadget

I think there's been a lot of dark mode discussions and here's another one.

A few weeks ago I started having problems with dark mode. I have dark mode in preferences enabled. Since then all the article pages are inverted - showing white background with text links showing dark mode colours.

Watchlist and other wiki pages remain in black. it was driving me crazy.

I restored all preferences back to default and then was able to isolate the problem to the accessibility for reading beta feature. it appears that the two dark modes are clashing with each other.

i have since disabled this feature and dark mode now works perfectly in wikipedia. there is no dark mode in other wikimedia sites enabled. Adenosine Triphosphate (talk) 22:18, 27 May 2024 (UTC)

Hey, thanks @Adenosine Triphosphate for reporting this. You're right, the gadget and our beta feature are in conflict. On English Wikipedia, our team member and technical editors are discussing the ways forward. SGrabarczuk (WMF) (talk) 01:26, 28 May 2024 (UTC)

In the meantime you can just disable one or the other... Nardog (talk) 04:29, 28 May 2024 (UTC)

Thanks! I should also add that disabling the preferences dark mode does not appear to work, it still shows the inverted colours. only disabling the accessibility for reading beta feature works. Adenosine Triphosphate (talk) 08:20, 28 May 2024 (UTC)

@Adenosine Triphosphate: Hello, did you both untoggle the "Dark mode toggle" and "Core styling for dark mode gadget" option? After you untoggle, maybe you need to clear the browser cache. SCP-2000 (talk) 08:36, 28 May 2024 (UTC)

yes I did, it was really weird. i noticed the problem was on the server side, i tried in incognito mode as well and still had the same problem, i then proceeded to delete my browser history, cache and cookies completely and still had the problem.

basically if you enabled dark mode, the watchlist appeared fine but inverted for normal articles. Adenosine Triphosphate (talk) 10:34, 28 May 2024 (UTC)

Expansion icons invisible in dark mode

Tracked in Phabricator
Task T365951

I didn't see anyone report this issue, so I figured I'd put it in. The new font sizes are very useful, but the new dark mode appears to break some things. The expansion icons on the table of contents (the little ">" symbols) are black in the new dark mode and are invisible. It's also inconvenient to change the font size while reading if you have the controls moved to the goggles symbol, because you have to scroll all the way back up, but that's probably intended (unavoidable) behaviour. I'll likely use it anyways for the font sizes but hopefully this get fixed as the feature moves out of beta. Mrfoogles (talk) 06:01, 28 May 2024 (UTC)

Thanks @Mrfoogles for reporting the problem of the expansion icons. We'll be working on it soon.

As for the controls being moved to the goggles symbol, yeah, we are giving two options: you have a narrower content area but you can change the settings at any time, or you have a wider content area but you need to scroll to the top. Users can choose depending on their personal preference, width of their screen, etc.

We'll be working on dark mode for some time, and definitely, with the help of editors like you, we'll move the feature out of beta within a few months :) (The font options may be released sooner: for more details, see this announcement, and the paragraph below the line "Our works so far and next steps".) Thanks! SGrabarczuk (WMF) (talk) 23:31, 28 May 2024 (UTC)

I think considering Standard font size as a default is a good idea: I turned it on a while ago leaning back from the computer and haven't switched it back since. May move the goggles back down, but I legitimately don't need to adjust things that much and it attracts attention with the solid-color radio buttons when it's on the bottom. Glad the dark mode is getting worked on: it works but will definitely be better fully functioning. Sounds like it might be a while. Are you also planning to change the font size of the UI elements in the sidebars, along with the content, eventually? It works, but it's a bit odd to have them different font sizes, and I think they would be easier to read. Thanks for the response. Mrfoogles (talk) 06:47, 29 May 2024 (UTC)

Dark mode is broken on Ukrainian Wiktionary and partially on the Wikisource

The side panels are partially in black, but all of the main text on pages is still in the light mode. Black colored text becomes white while the background is still white, so basically it is unusable. I've also tried viewing pages on Ukrainian Wikisource, it works better, but there are still issues with some templates display.

Browser: Firefox 125.0.2

OS: Linux Mint 21

Pages from Ukrainian Wiktionary to try: https://uk.wiktionary.org/wiki/%D0%9A%D0%BB%D0%B8%D0%BC%D0%BE%D1%87%D0%BA%D0%BE

https://uk.wiktionary.org/wiki/%D0%93%D0%BE%D0%BB%D0%BE%D0%B2%D0%BD%D0%B0_%D1%81%D1%82%D0%BE%D1%80%D1%96%D0%BD%D0%BA%D0%B0

Wikisource https://uk.wikisource.org/wiki/%D0%A2%D0%B2%D0%BE%D1%80%D0%B8_%D0%93%D1%80%D0%B8%D0%B3%D0%BE%D1%80%D0%B8%D1%8F_%D0%9A%D0%B2%D1%96%D1%82%D0%BA%D0%B8-%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8F%D0%BD%D0%B5%D0%BD%D0%BA%D0%B0/I/%D0%9C%D0%B0%D1%80%D1%83%D1%81%D1%8F Bicolino34 (talk) 13:32, 26 May 2024 (UTC)

Hi there, given we have hundreds of wikis, it's not possible for us to fix every single wiki. We have provided a page to assist updating these templates to work with the dark mode and we recommend you share it on your wikis community portal to identify editors who can help with these efforts mw:Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis. They can also ask specific questions here. For the Ukrainian Wikitionary page you point to for example there looks like there are various site styles defined in https://uk.wiktionary.org/w/index.php?title=MediaWiki:Common.css#L-23 that are conflicting with dark mode. It looks like User:Ahonc was the last editor of that page so they would be a good person to reach out to!

Rest assured, we will not be promoting dark mode on any wikis where the content becomes unusable. We also recognize for some wikis this may take longer to adapt to then others. Jdlrobson (talk) 01:30, 29 May 2024 (UTC)

@Bicolino34 anything I can help with here? Jdlrobson (talk) 05:25, 31 May 2024 (UTC)

Thank you for the help. I thought that this was the bug with the dark mode, but didn't even think about local setting of wikis Bicolino34 (talk) 06:27, 31 May 2024 (UTC)

Icon is too weird

The icon is too weird. With the lines to the side, it looks like a pair of swimming goggles, not a pair of reading glasses. This makes it stand out, which is a problem for scannability. This button is emphasized but not important, and distracts from the actual article.

It is not important because it duplicates browser features. You can just zoom in normally, or use Firefox/Chrome's Reader Mode for the other settings.

It would be better for the collapsed icon to be moved to the Tools menu, together with the Print/Export display options. When I click hide, I want the menu hidden, not converted into an icon, and I am having to use AdBlock until the button is changed. 184.146.170.127 19:44, 11 June 2024 (UTC)

Dark mode parity with Android app

Hello! I want to ask a question about the dark mode that A4R is implementing. Currently, the A4R Minerva dark mode looks different to the Wikipedia Android app's dark mode. For example, A4R dark mode's background color (#101418) looks darker than Wikipedia Android dark mode's background color (#212121). Would the planned dark modes for Minerva and Vector 2022, when they are finished, resemble the dark mode for Wikipedia Android/iOS? If not, why? LightNightLights (talk) 16:30, 14 May 2024 (UTC)

I hope the apps then finally stop doing their own (undocumented) thing and use the same styles as the website. hgzh 10:00, 15 May 2024 (UTC)

From an engineering perspective, the approach taking in apps is actually very consistent with the web implementation, and the web implementation took a lot of inspiration from it and challenges it encountered. Fixes to dark mode in the web version for content will also apply in the app. The apps team actually kicked off the first version of our documentation for how to integrate with dark mode.

I'm not a designer, but for user interface, there are different design considerations which need to be taken into account in relation to the different platform so I imagine this is why some colors may vary in the UI. Jon (WMF) (talk) 02:08, 12 June 2024 (UTC)

Always enable the dark mode for all namespaces

Is there someway to enable the dark mode just always regardless of namespaces? I'm interested in fixing issues on namespace currently not marked for the dark mode myself and have fixed some in my home wiki so probably it's better to see them first even before other beta users. ebrahim^talk 19:25, 11 June 2024 (UTC)

I've been using this temporary global script to this. Is there any namespace in particular you want to fix? I can look into seeing if we can speed up the roll out of dark mode on that namespace if helpful. Jon (WMF) (talk) 02:00, 12 June 2024 (UTC)

Thank you so much, not any particular namespace for now 😊 Thanks ebrahim^talk 11:40, 12 June 2024 (UTC)

Jon (WMF): The code doesn't work in main page of d:Wikidata:Main Page but in a userpage like d:User:Ebrahim but I totally understand give the complexity of the work and Wikidata not being in a priority and I don't expect otherwise either so just consider that as a bug report for the particular script. Using that script I've done some edits in Wikimedia Commons, Wikidata and Persian Wikipedia where I had interface edit access. I will be careful to not add a new concern for you but just to fix things before other beta users have to deal with them. Thanks 😊 ebrahim^talk 12:48, 12 June 2024 (UTC)

Feel free to send a token or write on either phab:T366368 and phab:T366364 where we are tracking this. I think the main concern is we don't want to overwhelm editors with templates to fix. Jon (WMF) (talk) 19:32, 12 June 2024 (UTC)

Font size slider

Would you please consider adding a font size slider (see how wikiwand.com did it) with a few more values between small (0.88rem) and what you call "standard" (1rem), and save the values separately for m.wiki. 1rem on all my devices looks way too big. Something around 0.93rem would be perfect - for me. Large is ridiculously large, esp. when it comes to infoboxes and alike, I don't understand what made you go that high. pon_or (talk) 12:25, 10 May 2024 (UTC)

The more customization options are added for you the reader, the harder it becomes for you the editor to make a well-formatted content page. Snowmanonahoe (talk) 20:24, 13 May 2024 (UTC)

SGrabarczuk (WMF) and OVasileva (WMF). The more font sizing options, the happier people will be. A well-formatted content page can be made regardless of the font size. As long as the font slider only effects text, and not images. Images are placed in proximity to text. Either below, or beside, a particular paragraph. So the image moves with the text. Regardless of the text size.

The font slider could operate continuously, or in stops. The more stops the better. 1, 5, or 10 percent increments. My Firefox zoom that I put on the toolbar has jumps that are too big if using the plus and minus buttons. But ctrl-scroll changes the text size in 10% increments. --Timeshifter (talk) 14:28, 14 June 2024 (UTC)

Accessibility text size not available in Special space?

I noticed that the text size options for the new accessibility module are grayed out for any page in Special:. What's the reason behind that? Tenryuu (talk) 17:49, 11 June 2024 (UTC)

phab:T360092 and phab:T366334#9866382 are the appropriate tasks for the discussions that led to this. @SGrabarczuk (WMF) perhaps this could be summarized on the FAQ since it seems like a question that has been asked a few times now? Jon (WMF) (talk) 02:02, 12 June 2024 (UTC)

Thanks for the question @Tenryuu - the idea here was that we would prioritize scannability for pages that did not generally include long-from text. Thus, we leaned towards displaying these pages in the local "small" version so that the page would have higher information density. However, as we receive feedback from the community, we are also open to iterating on this decision. If you have a minute, could you can give more detail on why you would prefer these pages to appear in the larger text size? We can use this to help us in making a decision for the future. Thank you! OVasileva (WMF) (talk) 10:59, 12 June 2024 (UTC)

Hi @OVasileva (WMF), thanks for responding. My reason for asking is because I frequently switch between my watchlist and other namespaces, and the switch between text size becomes jarring and strains my eyes; I've had to increase Wikipedia's text size in the past using my browser so that I could reduce fatigue. Would it be possible to enable the Accessibility toolbar in all the namespaces? It doesn't sound like it'd be taxing on the servers to allow such a thing. Tenryuu (talk) 13:34, 12 June 2024 (UTC)

OVasileva (WMF). I like larger text sizes in general. So I like this initiative by Wikimedia. I have the zoom bar on my toolbar in Firefox. With the plus and minus buttons, and the zoom percentage. Like Tenryuu, I switch often between the watchlist and other pages, and wikitext edit windows. I edit almost exclusively in wikitext windows. I have been editing since 2005. I use the Visual Editor sometimes for some particular types of table editing.

The more text sizing choices the better. I suggest a text-size option just for watchlists, and another just for wikitext editing. I like large text size in general, but slightly less large for watchlists and wikitext editing.

Windows made a huge mistake when it removed its many text sizing options. Its current system is chaos. As I have yet again experienced when I recently moved from Windows 10 Pro to Windows 11 Pro on another PC. I have a 1440x2560 resolution 27-inch monitor. And for some reason this combination is maybe the most exasperated I have ever been with the tiny text in many parts of Windows and apps. I have written much about it here trying to figure it out (much more to do):

https://weedwiki.fandom.com/wiki/User:Timeshifter#Firefox_bookmarks_text_size,_sidebar_width,_menu_text

That section and a few that follow deal with text sizing.

There are text sizing discussions concerning text in maps too. See:

https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Accessibility#Text_in_images

By the way, I wish you had allowed the "expand all" button in the table of contents. See my latest comments here:

https://phabricator.wikimedia.org/T302426

--Timeshifter (talk) 13:45, 14 June 2024 (UTC)

Tooltip for icon

Right now on English Wikipedia, I can see the icon for the Accessibility for Reading menu, but it has no tooltip upon hovering. To help users be aware of the function of the icon without selecting it, could a tooltip be added? Isaacl (talk) 15:48, 11 June 2024 (UTC)

Agreed, tooltip would be useful, specially while the function is new and unfamiliar. 105.225.48.130 06:30, 12 June 2024 (UTC)

SGrabarczuk (WMF) and OVasileva (WMF). Tooltips are essential for icons.

Apple assumes all users of their iphones are fanatics, and so they make the same mistake of not putting labels below the icons in the control center, app library, and elsewhere. I don't use my cheap iphone SE 2020 much since there is a home phone here. And I don't feel as much need to do so, since it is the least expensive iphone. So I don't remember what many of the icons do when I come back to it.

Iphone home screen pages have labels below all the icons. Tooltips wouldn't work there of course since it is a touch screen.

The point I am making is that Wikimedia shouldn't assume people will know what icons do either. At least put a tooltip please. --Timeshifter (talk) 11:41, 15 June 2024 (UTC)

TOC is really distracting

Moved to Talk:Reading/Web/Desktop Improvements#TOC is really distracting

SGrabarczuk (WMF) (talk) 19:11, 17 June 2024 (UTC)

Translating contents

It seems it works sometimes in Special pages such as translating content, but there are times it doesn't. LEILA FERRAZ (talk) 22:34, 12 June 2024 (UTC)

Every page needs optimizing for night mode. We are aiming to enable all pages, but this takes time because of legacy code.

A list of known issues on these pages can be found by going to https://phabricator.wikimedia.org/project/view/6717/ and scanning the "Excluded experiences" column on the far right. I hope this is helpful! Jon (WMF) (talk) 16:38, 18 June 2024 (UTC)

Is it possible to install this on my own Wiki?

I can't find anywhere whatsoever to enable this on my own wiki. What version do I need to get this on my own wiki? Is it something I need to install? 81.154.143.12 16:10, 13 June 2024 (UTC)

Yes but with the caveat it's still not stable (we are hoping to release as default in a future MediaWiki version). You need the following LocalSettings configuration:

:$wgVectorAppearance = true;
:$wgVectorNightMode = true;
:$wgMinervaNightMode = true;
:

Jon (WMF) (talk) 15:57, 18 June 2024 (UTC)

"Powered by MediaWiki" image at the bottom right in desktop view is incompatible with dark mode

Tracked in Phabricator
Task T256190

The "Powered by MediaWiki" image at the bottom right in desktop view is incompatible with dark mode. It appears to be a transparent image containing black text, so when the background is black, the text is not visible. The "a Wikimedia project" image next to it contains dark gray text, so the contrast with the black background probably fails accessibility guidelines.

I'm guessing that this will be a significant problem for any transparent images that assume a white background. It may need a systemic fix. Jonesey95 (talk) 03:09, 18 June 2024 (UTC)

task T256190 Jon (WMF) (talk) 15:53, 18 June 2024 (UTC)

Many icons that are black in light mode wikipedia don't invert to white

For example the subcategories in the contents tab are black and therefore hard to see, especially if you're visually impaired.

Next, the powered by mediawiki is also based on dark text and it is also hard to see

And some facts widgets are white instead of black.

Billv22 (talk) 00:03, 19 June 2024 (UTC)

These issues are all being tracked and in the process of being fixed. Jon (WMF) (talk) 22:23, 20 June 2024 (UTC)

"This page is always in light mode"

Edit: I now see that dark mode for all pages has been discussed under other topics, and it's being worked on.

With dark mode turned on, pages such as the Preferences page, and my user homepage, still show up in light mode, with the message "This page is always in light mode" next to the toggle.

The other dark mode gadget (which has to be disabled to use this project's dark mode) keeps these pages dark, however, so it seems technically possible, and I would appreciate the ability to keep as many pages as possible in dark mode.

FWIW, this project's dark mode is easier on my eyes than the dark mode gadget, I think because the gadget is closer to a pitch black whereas this project uses a dark grey. Spdou (talk) 15:48, 19 June 2024 (UTC)

Please see answer to #Translating_contents Jon (WMF) (talk) 22:24, 20 June 2024 (UTC)

The blue diff color is too dark

It is hard to see the text as the contrast is so low between the dark blue and the black. Also, the zero left-right padding makes it more difficult to distinguish the first and last character. 0.5 em would be much nicer. Ainali (talk) 21:38, 20 June 2024 (UTC)

If this refers to the change made in Wikidata then I agree. I don't mind the yellow that much, but the purple/black combo don't work as it makes the text difficult to read. Sabelöga (talk) 21:59, 20 June 2024 (UTC)

We plan to share more information to provide background and reasoning behind the reasoning later in the week on phab:T361717. Please subscribe for updates. Jon (WMF) (talk) 22:37, 25 June 2024 (UTC)

Diff color change on mobile web editor

The mobile web editor used to show added and removed text in red and green respectively, making it clear to 97% of editors what is happening in that diff. These colors have now been changed to blue and yellow, so that no one can tell which text was added vs removed. This change will lead to good edits getting mistakenly reverted and contributors driven away from editing. Surely there is a win win possibility that keeps the red green distinction helpful to most while using the different shading so it can be distinguished by colorblind editors. Alternatively, another way of viewing mobile diffs that does not depend on color shading. Buidhe (talk) 23:46, 21 June 2024 (UTC)

The diff colors were changed on February 20th to be consistent with desktop. This was unrelated to this project.

We plan to share more information to provide background and reasoning behind the use of blue/yellow in diffs later in the week on phab:T361717. Please subscribe for updates. Jon (WMF) (talk) 22:37, 25 June 2024 (UTC)

[Bug] Cadre bleu autour des liens

Depuis quelques jours, quand on clique sur un lien, un cadre bleu disgracieux s'affiche autour du lien. Pouvez-vous le corriger svp. Merci. Ayack (talk) 14:21, 25 June 2024 (UTC)

thanks for the report!

Tracked in Phabricator
Task T368137

Jdlrobson (talk) 17:08, 25 June 2024 (UTC)

Global preferences for dark mode

Tracked in Phabricator
Task T365373

As a steward, I'm operating across a lot of different projects. I need to change the color settings on each project individually, because I want to use the light color while using WMF projects, while my browsers settings trigger the automatic color selection (which seems to the default?) to activate the dark mode. There should be an option to globally select light/dark/automatic instead of having to customise it on every wiki I'm using. Johannnes89 (talk) 16:18, 17 May 2024 (UTC)

@Johannnes89, that's a good idea. We don't know yet how feasible it would be, but I've created a phab ticket. Thanks! SGrabarczuk (WMF) (talk) 16:32, 20 May 2024 (UTC)

I agree with you.

I needed to activate the dark mode inside the Spanish Wikipedia and the English Wikipedia individually.

I thought that my preferences inside Wikipedia were the same across the different languages I read the encyclopedia. Because I just use one account in all the projects I visit. Sebastián Arena... 15:45, 2 June 2024 (UTC)

This should now be fixed. Jon (WMF) (talk) 18:35, 27 June 2024 (UTC)

We need a better way to mark images as invertible

class=skin-invert works just fine for thumbnails directly placed into the article, but when you're working on projects with tons of template complexity, it gets real difficult. Here on enwiki we have a couple templates that go 2-3 metatemplates deep, and to invert an image that appears in them, you need to edit all of the templates themselves and add parameters for image classes, and for the metatemplates that usually involves reading hundreds of lines of incomprehensible Lua. Just adding the parameter to w:en:Template:Chembox took me about half an hour.

I have no idea whether this is technically feasible, but might it be possible to set an image as invertible at the image level? Like, add an image to a category or SDC property, and it's always inverted wherever it's used. Snowmanonahoe (talk) 21:58, 24 June 2024 (UTC)

Have you tried the new skin-invert-image class? Jon (WMF) (talk) 18:47, 25 June 2024 (UTC)

How is it supposed to help me? Snowmanonahoe (talk) 21:47, 25 June 2024 (UTC)

> but might it be possible to set an image as invertible at the image level?

Could you elaborate on what you mean by this? Adding skin-invert-image to any element will only invert image tag inside that element, so you should be able to apply it once to the parent element if all you need to do is invert all images in the template.

You can also add a CSS rule to your template to invert all images inside the template if that makes sense and your template has a parent class `html.skin-theme-clientpref-night .template-class img { filter: invert( 1 ); }`

If this doesn't apply to your particular problem, could you perhaps create an example in your sandbox, describing what you are hoping to achieve?

Thanks in advance! Jon (WMF) (talk) 18:35, 27 June 2024 (UTC)

Night mode error report appears to be false positives or not fixable by editors

The recommendation says "Go to https://night-mode-checker.wmcloud.org/" and look at the errors, but when I go to the error list for en.WP, nearly every entry in the list is a link to "Tools" or "show"/"hide". Can these listings either be filtered out or fixed at the MediaWiki level by WMF developers? The error listing is pretty much useless in its current state because it is flooded with these unfixable listings. Thanks. Jonesey95 (talk) 16:27, 26 June 2024 (UTC)

The reports are intended to flag all issues with the page - as some may relate to gadgets/templates/extensions.

It's impossible to filter out these kind of issues, since templates can apply their own CSS but there is a bug fix in the works for this particular issue: phab:T368498. Jon (WMF) (talk) 18:37, 27 June 2024 (UTC)

Wikimedia Commons gets invisible Template:Hidden arrows

This is Template:Hidden, it provides <details> like feature for Commons but on the Main Page of Commons it's arrows are invisible https://i.imgur.com/KIb2hsy.png and I'm puzzled for hours why is that so, the arrow are gray and they are more or less visible right now in Template:Hidden but only in Main Page it get's weird. ebrahim^talk 21:51, 10 June 2024 (UTC)

The main page receives some extra overrides. I'm not entirely sure why... @Jon (WMF) ? —TheDJ (Not WMF) (talk • contribs) 09:56, 26 June 2024 (UTC)

The main page overrides are mostly to disable use of colors andd reduce the amount of work on projects which do not have the capacity to update their main pages.

You should be able to opt out by adding the notheme class to this template or you can copy across and amend the styles for Commons by using the instructions here: https://www.mediawiki.org/wiki/Extension:WikimediaMessages#Disabling_styles Jon (WMF) (talk) 03:36, 28 June 2024 (UTC)

Night mode checker marks standard links for dewiki as noncompliant

[4] currently contains 113 errors for the dewiki main page that uses nothing but just standard links on standard background. It seems like the contrast checker now requires WCAG AAA? hgzh 12:10, 1 July 2024 (UTC)

Thanks for raising this. Did you check to see if the links specifically are being flagged by the contrast checker? We haven't changed the criteria from WCAG AA (4.5:1 contrast ratio), and DE homepage is using the correct CSS variable for links, so links shouldn't be coming up in the contrast checks at all. I suspect most of those contrast errors on the page come from borders and section background colours. The automated checker still flags them even though they don't need to pass contrast checks because you don't need to interact with them to use the site. If that's the case, you can consider those false positives. JScherer-WMF (talk) 21:38, 3 July 2024 (UTC)

Hey the tool wasnt working properly. I just regenerated them and the main page is no longer showing up.

I can confirm we are still testing for WCAG AA.

Let me know! Jdlrobson (talk) 22:12, 3 July 2024 (UTC)

The results look good now, however, the expanding of the sections seems to be broken. hgzh 06:17, 4 July 2024 (UTC)

Thanks for flagging. Should be fixed now (on some pages it may take a little longer for that fix to propagate). Jon (WMF) (talk) 19:51, 5 July 2024 (UTC)

Linter status

Here it says ''As of now, the "night-mode-unaware-background-color" lint is assigned a priority level of none. This means it is not listed in "Page information" and is not visible on the main lint error page, and there are no expectations for editors to address identified issues until further notice.'' Still the error does show up on the Lint error page of Dutch Wiktionary. And instructions to solve this requiring Javascript aren't very useful to me. MarcoSwart (talk) 10:27, 4 July 2024 (UTC)

Hi there! This change went live yesterday. Due to the US holiday, I was only able to update the documentation today. I was worried that it would cause further confusion if it had been updated a day earlier.

I hope the newly updated documentation is clearer now! Jon (WMF) (talk) 19:51, 5 July 2024 (UTC)

Custom namespaces

After the last update dark mode is available in the default namespaces, but not in the custom ones. Many wiki projects have namespaces like "List", "Project", "Portal", etc, and for them, dark mode is also needed for consistency. — putnik 14:53, 5 July 2024 (UTC)

Hi @Putnik we are slowly turning on these namespaces one by one, but the goal is to have all of them enabled. For portal for example,

• Project pages will be enabled on Monday: https://phabricator.wikimedia.org/T366366
• We've had some feedback that editors do not want to fix portal pages so we've been holding of on that (https://phabricator.wikimedia.org/T366380#9943402) - please let us know on the ticket your own thoughts on this matter.
• For list namespace, we don't have a Phabricator ticket so it hasn't been a priority. Please request it and we'll be sure to add that to our radar. It helps us prioritize when we know somebody is asking for it.

Jon (WMF) (talk) 19:55, 5 July 2024 (UTC)

List of municipalities in United States

Hello there, I am a Chinese Wikipedia user who create lists of municipalities in some US States and make them to Featured List. However, it is turned out by some users that the displaying of some colors are problematic when using Dark Mode.

Take en:List of cities in Kansas (Chinese zh:堪萨斯州城市列表, some users told me the green (representing county seats) and purple (representing atate capital) color are still as bright as light mode, which happened in both languages and affect the reading of articles. (The actual display shown in here)

So I would like to ask if it is possible to let the green and purple look like this in Dark Mode, or is it possible to adjust the color in Dark Mode manually by wiki code. If yes, would the problem being fixed?

As I would like to create more similar articles in these two months, I hope that my questions could be answered sooner. SickManWP (talk) 15:12, 5 July 2024 (UTC)

if it is possible to let the green and purple look like this in Dark Mode You are using the dark mode gadget rather than the "Accessibility for reading" dark mode. Thanks. SCP-2000 (talk) 15:51, 5 July 2024 (UTC)

Yes, my meaning is the colors in dark mode gadget is better. If "Accessibility for reading" dark mode is used, that is where the color problem is. --SickManWP (talk) 16:09, 5 July 2024 (UTC)

Hi there, I think the recommendation about using CSS variables applies here.

You have two options here:

1) You can swap out

background-color:#b4ddb4;

with

background-color: var(--background-color-success-subtle,#b4ddb4)

,

color:red;

with

color: var(--color-error, red);

and

color:green

with

color: var(--color-success, green)

for better dark mode support. [recommended as this improves accessibility]

2) You can add skin-invert class to the table itself [short term fix only but is quick - does not improve accessibility of this page].

Please circulate this recommendation with your community and consider making templates to help with its widespread use! Jon (WMF) (talk) 20:00, 5 July 2024 (UTC)

Thanks for your advice! However, there are three problems found during the test of the first option. I've tested the codes in zh:User:SickManWP/沙盒/16 (always welcome to edit!) and take Delaware as example, which is much shorter and contains very few counties.

1) If the b4ddb4 color is changed, despite the color in Dark Mode can be altered, The color of words cannot be change to white. (actual display)

2) The colors cannot be shown when using the template zh:Template:Legend2, which is not sure if it is my mistake of coding.

3) When I tried to change of #CCCCFF (purple) and #F2F2F2 (very pale grey) colors, it still shown dark green color, which are as same as county seat.

--SickManWP (talk) 04:15, 6 July 2024 (UTC)

Sister projects

@SGrabarczuk (WMF) @OVasileva (WMF) Last month it was announced that, by mid-June, logged-out users would be able to choose between different font sizes and that the default font size would be increased for them. This happened on Wikipedia but not on sister projects like Italian Wikisource or French Wikiquote, though the change had been announced there as well. Is there any specific reason for this? Erasmo Barresi (talk) 14:54, 7 July 2024 (UTC)

Hi @Erasmo Barresi - thank you for your question. In short - we're running a bit late but it's coming soon. More specifically, we have not yet had the sufficient time to test the appearance menu and text settings across sister projects. We are planning to do this testing over the course of this month, followed by making the feature available across wikis. OVasileva (WMF) (talk) 18:01, 8 July 2024 (UTC)

@OVasileva (WMF) Thank you! The Tech News newsletter was a bit misleading, as it referred to "wikis" in general, implying that the change was coming for all projects at the same time. This feature is a step forward, incorporating into the default interface something used to be done through CSS or local gadgets, so I look forward to seeing it available everywhere! Erasmo Barresi (talk) 14:49, 9 July 2024 (UTC)

CharInsert buttons

When I have the CharInsert gadget enabled on the English Wikipedia (which is on by default), the buttons for individual characters are still white when I also have dark mode enabled (which it is for me because of my operating system settings). -- Beland (talk) 17:17, 11 July 2024 (UTC)

Please report this to the gadget author via the gadget talk page. Thanks in advance! Jon (WMF) (talk) 00:04, 12 July 2024 (UTC)

Reported on en:Wikipedia:Village pump (technical)#CharInsert and dark mode. -- Beland (talk) 06:46, 12 July 2024 (UTC)

Use skin-invert in gallery

Apparently I can't use class=skin-invert in gallery for https://en.wikipedia.org/wiki/Kufic#Square_Kufic and guess it will nice to have −Ebrahim^talk 09:25, 6 July 2024 (UTC)

Considering this also happens in https://commons.wikimedia.org/wiki/Category:Square_Kufic also, maybe we need some property to be set in each image instead of tweaking the uses, at least to be used in categories and galleries. −Ebrahim^talk 12:31, 6 July 2024 (UTC)

We provide the 'skin-invert-image' class for this purpose! There's more documentation here: https://www.mediawiki.org/wiki/Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis#Apply_filters_to_dark_images_with_transparent_background

Hopefully this helps, let me know if you have any other questions! BWang (WMF) (talk) 17:57, 8 July 2024 (UTC)

It seems like skin-invert-image does not work for individual images in a gallery. See for example https://en.wikipedia.org/wiki/Kufic#Square_Kufic where only a few of the images should be inverted. Using skin-invert-image on the whole gallery is not a good solution as this messes up the other images. Tholme (talk) 19:38, 14 July 2024 (UTC)

darkmode parameter?

Is there a url parameter (e.g. ?usedarkmode=1) that works with logged out web users users to preview and troubleshoot pages right now? Xaosflux (talk) 13:16, 15 July 2024 (UTC)

I am not aware of a URL parameter that works, but I visit Special:MobileOptions on desktop when logged out to set my mode to Dark. LightNightLights (talk) 15:08, 15 July 2024 (UTC) (stricken LightNightLights (talk) 16:29, 15 July 2024 (UTC))

Yes. For desktop (for now) you can add ?vectornightmode=1 to the URL. Jon (WMF) (talk) 16:04, 15 July 2024 (UTC)

(This did not work for my phone browser in desktop mode, but did work in my laptop. I will strike my earlier comment.) LightNightLights (talk) 16:27, 15 July 2024 (UTC)

hmm - it works for me in desktop mode on my phone

For what it's worth, on the mobile site we supply a similar ?minervanightmode=1 option SToyofuku-WMF (talk) 16:50, 15 July 2024 (UTC)

Thank you, worked for this VRT ticket I'm trying to help with. Xaosflux (talk) 20:25, 15 July 2024 (UTC)

It's safe to append both to a URL.

For example https://en.wikipedia.org/wiki/Dog?minervanightmode=1&vectornightmode=1 will always force dark mode on whether it's loaded on mobile or desktop. Jon (WMF) (talk) 20:27, 15 July 2024 (UTC)

White background instead of inversion for transparent images

Hello! In dark mode, can it be recommended in Recommendations for night mode compatibility on Wikimedia wikis that editors can alternatively add a white background to a transparent image than to invert that image? I think that, at least in some cases, a white background is better than an inversion.

I made a comparison at en:User:LightNightLights/Dark mode white background. In my opinion: you cannot read the text in the first logo, the colors are misleading in the second logo, and none of these problems are present in the third logo. LightNightLights (talk) 15:02, 9 July 2024 (UTC)

Hi there! This is a great suggestion, and I appreciate you taking the time to provide an example. I'm about to edit Recommendations for night mode compatibility on Wikimedia wikis#Apply filters to dark images with transparent background to reflect this suggestion - feel free to take a look and let me know if you have any suggestions for updated wording/if I captured your suggestion well ☺️ SToyofuku-WMF (talk) 20:30, 10 July 2024 (UTC)

Thank you for adding my suggestion! I have some opposition to the phrase "so that it can be seen in both day and night modes", since I think inverting the image does make them visible in both day and night mode. I argue though that inversion is not the best way to make them visible in both modes because they can make the colors of the image misleading.

On that topic, should we mention in the recommendation that image inversion can cause misleading colors? (By "misleading colors", I mean colors that do not match the branding's colors. For example, in the comparison I linked, |class=skin-invert turns red into pink and yellow into brown.)

Other than that, I am wondering what WMF visual designers think of the recommendation. I am not a professional visual designer myself (sorry for not mentioning that in my initial post), and it might turn out that my suggestion contradicts best-design guidelines. If it is possible, notifying them of this would be great! LightNightLights (talk) 23:05, 10 July 2024 (UTC) (edited 23:12, 10 July 2024 (UTC))

Hi @LightNightLights! Good point, I will update the wording a little bit. As for what designers think, I believe this is in line with the recommendation that our team's UX designer proposed - whenever possible we want to preserve semantic colors so that images are not misleading

Thank you again for the suggestion!! SToyofuku-WMF (talk) 20:30, 11 July 2024 (UTC)

There should also be an option to add a white background to thumbs via class like skin-invert. hgzh 07:18, 12 July 2024 (UTC)

I think that would be a good idea. @SToyofuku-WMF, thoughts? LightNightLights (talk) 18:26, 14 July 2024 (UTC)

I think that makes sense! Feel free to make a Phabricator ticket using the form at Reading/Web/Request process, and our product manager can take a look at it for prioritization SToyofuku-WMF (talk) 16:46, 15 July 2024 (UTC)

Do you know what is currently the best way to add a white background to an image? I checked @LightNightLights's example, but it uses a div to wrap around the image. I don't think this will work if the image has a caption. Panangam (talk) 13:36, 18 July 2024 (UTC)

Found a relevant comment here. Panangam (talk) 13:47, 18 July 2024 (UTC)