Page MenuHomePhabricator

[EPIC] Accessibility settings/preferences
Open, MediumPublic

Assigned To
Authored By
Mar 1 2015, 6:39 PM
Referenced Files
F36372984: Screen Shot 2023-01-20 at 1.40.02 PM.png
Jan 20 2023, 9:40 PM
F36372982: Screen Shot 2023-01-20 at 1.39.45 PM.png
Jan 20 2023, 9:40 PM
F3140697: Screen Capture on 2015-12-23 at 20-13-29.gif
Dec 24 2015, 1:34 AM
F2614037: Screen Shot 2015-09-16 at 23.18.09.png
Sep 18 2015, 12:02 AM
F168938: mediumText.svg
May 25 2015, 10:12 AM
F168937: uniE040 - largeText.svg
May 25 2015, 10:12 AM
F168939: smallText.svg
May 25 2015, 10:12 AM
F168931: smallText.svg
May 25 2015, 10:06 AM
"Mountain of Wealth" token, awarded by Sj."Love" token, awarded by alexhollender_WMF."Love" token, awarded by Demian."Like" token, awarded by Liuxinyu970226."Like" token, awarded by Rdicerb."Like" token, awarded by Fhocutt."Love" token, awarded by Florian."Like" token, awarded by Prtksxna."Like" token, awarded by Quiddity.


Offer a satisfying user-interface experience to as many people as possible.

We have been striving for a one-size-fits-all interface. In contrast this solution offers users with very common disabilities and impairments, which we know the current interface doesn't offer best experience, an easy way to adapt the interface to their needs and to serve them the best we could.

What to offer
We’re talking about flexibility in changing basic settings (still to clarify needs, define and test) like

  • font size,
  • day/night modes,
  • photophobia,
  • grayscale,

For whom
For all readers including not-logged-in ones.
Technical limitation to support it for every user is, that it has to be implemented client-side in JavaScript to avoid cache fragmentation.

Where and how
Some early mockups:

And more recently discussed “reader“ settings (design and location) over at
Related is question to consolidate important reader preferences (appearance, language, accessibility preferences) into one location, which is also a good part of the discussion on the Hovercards preferences.

Separation to other accessibility improvements
In general, with WMF's vision of ”every single human being”, we try to provide broadest-possible support. But with given technical constraints we need to balance the different needs. At T111117 there are for example tasks collected, that can be baked-in per default into our software products, others like above mentioned font-size, day-night modes etc. are better built as preferences and decided on a per-user base, as there's not one solution fits all.

Relevant discussion on: T72879: Simple accessibility preferences
Version: 1.24rc

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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

Volker_E renamed this task from Accessibility settings to Accessibility settings/preferences.Jun 23 2016, 9:47 PM
Volker_E claimed this task.
Volker_E updated the task description. (Show Details)
Volker_E updated the task description. (Show Details)

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.

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

Jdlrobson renamed this task from Accessibility settings/preferences to [EPIC] Accessibility settings/preferences.Jun 1 2021, 7:16 PM
Jdlrobson added a project: Epic.

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

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

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
Replaces the fixed width toggle with a fully blown menu that works for anons:

Screen Shot 2023-01-20 at 1.39.45 PM.png (140×282 px, 3 KB)

Screen Shot 2023-01-20 at 1.40.02 PM.png (754×1 px, 175 KB)

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 ( - 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:

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

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

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

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

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

@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: (click the cog in the bottom right)

I think this solution of building on top of what we have with 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?