@FreedomFighterSparrow We were considering to make a test balloon in a smaller project (MediaWiki theme) and learn from the technical difficulties/challenges and successes.
I am, for my part, still not convinced about the user experience of the current position and layout, nor the functionality coverage, for example:

• Why would font-size buttons in 2016 be a thing, where you have a vast support of browser zooming of all kinds, mobile users are used to pinch-to-zoom mechanisms and assistive technology gives you added zooming support on an operating system level? Adding an extra functionality must address some user needs' beyond their already learnt tasks and fulfill that perfectly. Also, as technical providers we have to consider the maintenance costs for such an added feature.

So I would like to first discuss, what functions we all together would agree being useful and which add real value aside from existing solutions and where affected users would gain satisfaction before going into further early implementation.

Just to answer the question in your example: although all text is related to a font-size setting, images are generally not sized in relation to the base font size. In other words, zoom is not synonymous with changing font size. Of course registered users wanting to change the balance between image size and font size don't need buttons to change font size, as they can set different default image sizes in their preferences.

I'm unaware of any demand from readers (i.e. non-registered users) to change the balance between image and text sizes, so I would assume that implementing font-size buttons would be effort for no actual gain, given the ease with which all readers can change zoom on a page.

Perhaps the first step would be to get some surveys done of what accessibility features readers actually want. I'm guessing that the ability to change skins from dark-on-light to light-on dark would be popular.

I added our collated notes from here to https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Reading/Accessibility_settings_for_everyone - please vote before 30 November. :-)

Note: A related idea was recently suggested at w:en:WP:VPI (permalink) - TLDR: They want a slightly-less-bright background than the current plain white (i.e. not a night-mode, just a pale grey/similar). p.s. I've occasionally used a bookmarklet to achieve this at various websites.

Another mockup idea in https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Wikimania_Stockholm_research_report#/media/File:Sketch_of_reading_preferences_panel_for_the_Desktop_improvements_project.png

T234703: Skin Minerva Neue: do not manually assign fonts highlighted a need to allow users to change the font used to the system default. Some OSes - most notably mobiles - have an option to select a custom system-wide font, that's the closest to the user's expectations.

I'd also add the option to use a modern webfont (Noto Sans - Noto Serif being a candidate as the font supporting the most languages). That would make 3 choices: Font: Skin's font / Noto (webfont) / System default font

Additionally, I'd add a choice between sans-serif and serif fonts, which is usually a subjective choice, that greatly affects the user experience. The system default font depends on this choice. This setting also enables the use of both the sans-serif and the serif font stacks.

Details: T244748: Add client-side skin preferences drop-down

Other than font size, font type should also be cutomizable, for people with different needs

For Wikipeda like Chinese and Japanese Wikipeda, different text orientation option should also be available as these languages can be written in multiple orientations, and some might be more accustomed to one than the other.

There are some wrong design decissions that are against accesibility. For example, hiding the login button inside a menu, instead of showing it from the beginning: T289212

I would like to know how a person with visual impairments will know where the log-in button is. I asked that months ago, there's a ticket open, but no answer from the design team.

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

[mediawiki/skins/Vector@master] Proof of concept: Show case possibilities in client side preferences dropdown

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

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/a522674b0f/w

We think we've found a way to do this with some constraints. Chatting on Monday about whether the approach there is viable from performance perspective.

I've built a prototype if anyone is lurking here in case it's useful for community conversation https://patchdemo.wmflabs.org/wikis/a522674b0f/wiki/Mahatma_Gandhi?useskin=vector-2022
Replaces the fixed width toggle with a fully blown menu that works for anons:

I'm really happy this is being looked at again! Thank you.

In case it helps (and as it's easily missed), I want to mention that the "Mock Description" and comments sections at M17 contain a lot more details/ideas/references.

For non-logged-in users (via cookie?) - remember line width/ToC position (show/hide)/etc. (as many preferences as possible - almost everything a logged-in user has, including choosing "vector 2010", etc.) - both a set-by-user "global" setting and set-by-user "specific page exception" settings

Article editors should be able to select "server-side" default for each article - line width/ToC position, and users (including non-logged-in) should be able to select globally/per article whether to follow the Editor/server-side suggestion or not.

History article appears in the vector 2022 format on my browser now (non-logged user). I opened it when reading it's an exception (https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features/Limiting_content_width#Constraints) - and it really appeared as vector 2010, but after fiddling with the toggle and other settings on other pages - now even History appears as vector 2010?

If there are any concerns with the line width toggle position, overlap with content, user confusion if it doesn't do anything on small screen, etc. - just put it in any of the collapsible menus at sandwich/three-dots/footer/etc. Important is to be possible to trigger it at ANY resolution by ANY user.

Line width toggle - even when expanded leaves more space on the right than in vector 2010. Can we have an "extra wide" mode where content occupies even more of the space (same as vector 2010 or even till the window border)? Or even user selectable length. Similarly, on the left side in vector 2022 there is blank space between ToC/service menu and article - can its size become user-selectable as well?

I would show the line width toggle always, regardless of window width - but on smaller than some threshold (1400px per T326887 ?) - the toggle should ALSO hide the ToC menu.

Always having the option for expanded line width is the best, so I'm glad adding it permanently in a menu is being worked upon.
Much more important than the specific threshold (and toggling together with ToC) is for both settings to STICK for all articles for non-logged-in users. Currently having to click on every page refresh/open is getting annoying fast. So, I hope that's considered here.

Background colors and widths to be user-selectable for each of the vector 2022 spaces:

• article
• small vertical empty bars on left/right (equal in size to the toggle icon)
• left bar - ToC/service menu (see https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements#Lack_of_left_border)
• right bar - mostly empty with account/login on top
• left unused - to the left of the left bar
• right unused - to the right of the right bar (toggle icon goes here)

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/5512c1ca5b/w

Test wiki on Patch demo by Jdlrobson using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/5512c1ca5b/w/

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/cb775d9677/w

Test wiki on Patch demo by Jdlrobson using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/cb775d9677/w/

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/10b47eaaa5/w

@Quiddity not thinking about design right now but thanks for the mock!
@Anteraf we have to be careful about how many different variants we support, so I don't think we'll be able to cater for such exact fine tuning, but hopefully we land on some preferences that make sense. Thanks for the feedback here, I'll definitely pass it on to my peers as we talk through this.

@Mooeypoo so now we have a solution for fixed width I've been battle testing this against other types of preferences including one close to your heart.. dark mode.
You can check it out here: https://patchdemo.wmflabs.org/wikis/10b47eaaa5/wiki/Space?useskin=vector-2022 (click the cog in the bottom right)

I think this solution of building on top of what we have with https://gerrit.wikimedia.org/r/c/mediawiki/core/+/883243 is very viable, but obviously we should explore others (I can't think of any right now). How do you recommend we proceed with working out the long term solution?