Accessibility settings/preferences
Open, NormalPublic


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.

Merged from T72879
Version: 1.24rc

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
Nirzar added a subscriber: TheDJ.Mar 3 2015, 5:22 AM
Quiddity edited the task description. (Show Details)Mar 4 2015, 7:47 PM
Quiddity added a subscriber: violetto.

@FreedomFighterSparrow, will you be joining us at hackathon in May?

Qgil added a subscriber: Qgil.May 18 2015, 11:12 AM

It is time to promote Wikimedia-Hackathon-2015 activities in the program (training sessions and meetings) and main wiki page (hacking projects and other ongoing activities). Follow the instructions, please. If you have questions, about this message, ask here.

Descriptions for mock ups can be found here.

Nice :-)
The textsize buttons are very clear, but do you feel that the contrast buttons are self-explanatory? I'm not sure.

Nitpicking: the cheveron in the first two mockups should be flipped upside down, for consistency with mediawiki's mobile web.

Fixed them both @FreedomFighterSparrow

Hoping this works better.

Mockup for accessibility settings inside user preferences.

Great, @violetto! Very clear now, IMO.
@Nirzar, is this also the "advanced" screen for the sidebar widget?

violetto added a comment.EditedMay 25 2015, 9:27 AM

Qgil added a comment.EditedJun 4 2015, 10:43 AM

We are trying to help all open tasks listed under "Work continues after Lyon" at the Wikimedia Hackathon 2015 workboard finding their best way forward.

  • If you are participating in Wikimania, consider adding the #Wikimania-Hackathon-2015 project to get this task in that loop, which is about to start.
  • If you think this project could welcome help from a dedicated Google Summer of Code or Outreachy intern, or from an Individual Engagement Grant, add the Possible-Tech-Projects project.
  • If you would like to receive some other type of support (organizing a Tech Talk, establishing contacts with existing developer teams in Wikimedia or elsewhere, travel sponsorship for a related activity... you name it), please create a subtask explaining your request and associate it with Developer-Relations (or you can start by commenting here if you prefer).
  • Keeping the description, priority and assigned fields up to date always helps. :)

For some context about this message, see T101151: Evaluate which projects showcased at the Wikimedia Hackathon should be supported further. It is the last communication related to Wikimedia-Hackathon-2015 that we will post here.

Qgil triaged this task as "Normal" priority.Jul 3 2015, 11:19 AM
Qgil added a comment.Jul 7 2015, 2:12 PM

Who is the owner of this #Wikimania-Hackathon-2015 project?

@Nirzar, since you're no longer very active in this project (totally understandable!), would you mind if I become the owner for this project? I'll be continuing the work @Prtksxna @Quiddity and I have done at Lyon hackathon at Wikimania.

What is the status of this task, now that Wikimania 2015 is over? Did this hacking project take place and was successfully finished? If yes: Please provide an update and potentially summarize findings / provide a link to anything relevant (and if the task is not completely finished yet, please move the project to the "Work continues after Mexico City" column on the #Wikimania-Hackathon-2015 workboard). If no: Please edit this task by removing the #Wikimania-Hackathon-2015 project from this task. Thanks for your help and keeping this task updated!

violetto edited the task description. (Show Details)
Qgil added a comment.Sep 16 2015, 10:17 AM

A message to all open tasks related to the #Wikimania-Hackathon-2015. What do you need to complete this task? Do you need support from the Wikimedia Foundation to push it forward? Help promoting this project? Finding an intern to work on it? Organizing a developer sprint? Pitching it to WMF teams? Applying for a grant? If you need support, share your request at T107423: Evaluate which projects showcased at the Wikimania Hackathon 2015 should be supported further or contact me personally. Thank you!

Have you taken into account people with photophobia ? These people need light colors for the text, and dark background. But no pure white or anything too bright.

Some people have it on a very severe scale where they feel blinded by sunlight, and they might already have specialized software or assistive tool to solve some of their problem. Some of them don't have assistive technologies and are struggling, I've seen a few editors in such cases. I've made a light gray on dark skin for them.
Either way, it's much more comfortable to view a website made with the right color scheme, than to compensate with assistive technologies, the result is nowhere near as good.

Lots of people have a sensitivity to brightness, and are able to endure it for some time. After, say, 30 minutes they start to have a migraine. There people would be more comfortable with a light gray on dark color scheme.

Here is a screenshot of the prototype I made. It's not perfect, especially the top of the page, the tabs, and the search. Those are tricky to override.

@Dodoiste I'm aware of them only because I've received feedback about black text on white background hurting users' eyes. We need to advocate for these users more than we do now. Is there a guideline to the contrast ratio, or a good baseline to follow?

Either way, it's much more comfortable to view a website made with the right color scheme, than to compensate with assistive technologies, the result is nowhere near as good.

+1 Preach! I think these simple accessibility settings should be clearly surfaced for users when they visit the site. They shouldn't need to scour Preferences settings to feel comfortable. Everyone should feel welcomed.

Check out the code below. Take it apart and/or build onto it.

I made a demo video to show you what happened after Hackathon with the above code.

Qgil added a comment.Sep 18 2015, 8:56 AM

@violetto, are there plans to push this task as a team or individual quarterly goal?

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

violetto edited the task description. (Show Details)
RexxS added a subscriber: RexxS.Sep 19 2015, 10:34 PM

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

Qgil added a comment.Sep 24 2015, 9:50 AM

Thank you @violetto. It would be good to define a relationship between this task and T111117: [EPIC] Enhance accessibility of OOjs UI & 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.

Awesome @Qgil, that's what we'll do.

Elitre added a subscriber: Elitre.Oct 3 2015, 10:32 AM
Jay8g added a subscriber: Jay8g.Oct 4 2015, 5:35 AM

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

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!

Qgil removed a subscriber: Qgil.Dec 29 2015, 11:17 AM

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?

WebIntegrity edited the task description. (Show Details)Apr 3 2016, 6:20 AM
WebIntegrity added a subscriber: WebIntegrity.

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

RexxS added a comment.Apr 13 2016, 9:46 PM

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 changed the title from "Accessibility settings" to "Accessibility settings/preferences".Jun 23 2016, 9:47 PM
Volker_E claimed this task.
Volker_E edited the task description. (Show Details)
Volker_E edited the task description. (Show Details)
Volker_E edited the task description. (Show Details)Jun 23 2016, 9:53 PM
Volker_E edited the task description. (Show Details)Jun 23 2016, 10:13 PM
Volker_E edited the task description. (Show Details)Jun 24 2016, 9:14 AM