Page MenuHomePhabricator

[EPIC] Accessibility settings/preferences
Open, MediumPublic

Assigned To
Authored By
Mar 1 2015, 6:39 PM
Referenced Files
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
F168930: smallerText.svg
May 25 2015, 10:06 AM
F168928: smallerText-rtl.svg
May 25 2015, 9:59 AM
"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

@Qgil, @Dodoiste suggested over email that we should consider this as part of the team's goal, I think my team (UI Standardization) should seriously consider this given the feedback and requests we've gathered through the years that prove the importance of this task. We'll be looking at this question more closely next Monday. Will report back.

The team talked about it, the outcome is that this is a relatively huge task that needs to be broken down into smaller pieces. We'll be focusing on all things accessibility in Q2 (T111117) and this would fit right into it, but we would definitely need more help in terms of engineering resources to make this happen, which we're currently looking into.

cc @Qgil @Dodoiste

Thank you @violetto. It would be good to define a relationship between this task and T111117: [EPIC] Enhance accessibility of OOUI & MediaWiki UI library / LSG / MediaWiki General to screen readers and color-deficient users. Is it one of the blockers, should be merged...?

In terms of Engineering resources, if you define subtasks that would take about two weeks to an experienced developer, the such tasks could be good candidates to become Possible-Tech-Projects, and from that point they would be candidates for i.e. Outreachy-Round-11 , the next Google Summer of Code round, a Wikimedia Individual Engagement Grant... If you could define at least one of these tasks and propose it for Outreachy (starting soon), that would be great.

A couple of weeks ago @Volker_E spotted LinkedIn's execution in skip navigation link:

Screen Capture on 2015-12-23 at 20-13-29.gif (578×1 px, 2 MB)

In the future, we would like to have an "accessibility setting corner" where you can change your text size, contrast, background color, toggle between day and modes. Currently it is found within the left side bar, but this is less discoverable.

With a dedicated "corner" or space, we can make sure that it is:

  • Mobile-friendly
  • One-stop space to make accessibility setting changes *and* be able to see changes live for users to see how the settings change the interface
  • A place for users to find a link to give us feedback on what we can do to make improve the tool

These are some early thoughts and notes. What do you guys think?

As a side note, I haven't had the chance to break this task into smaller pieces for what Qgil mentioned here. Any interest out there in getting this done with me?

[...] These are some early thoughts and notes. What do you guys think?

IIUC, this is along the lines of the examples I was pointing out in M17 (FLOE, NYTimes, Gmail, Southampton Uni). So, yes please!

For newcomers...
To see how this works in your account, just copy&paste these 2 lines, into your [[Special:MyPage/common.js]]

// Accessibility menu - alpha - developed in
mw.loader.load(' (WMF)/common.js&action=raw&ctype=text/javascript');
mw.loader.load(' (WMF)/common.css&action=raw&ctype=text/css', 'text/css');

Thanks, quiddity :-)

@violetto, any obvious next steps you can think of?

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