Last modified: 2014-10-25 02:11:54 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T72879, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 70879 - Simple accessibility preferences
Simple accessibility preferences
Status: NEW
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
1.24rc
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: accessibility
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-16 03:21 UTC by Matthew Flaschen
Modified: 2014-10-25 02:11 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
wireframe idea (51.87 KB, image/png)
2014-10-12 18:32 UTC, Quiddity
Details

Description Matthew Flaschen 2014-09-16 03:21:39 UTC
There should be easy to use accessibility options.  A couple things to consider:

* Options to change the main colors (e.g. regular links, visited links, "red" links, button colors, etc.) easily, targeted for color-blind users (I'm not saying our colors are particularly bad for color-blind users, but this still might be a useful option.

* Font size

Based on suggestions by George Barnick on the design list.
Comment 1 Quiddity 2014-09-16 03:41:30 UTC
There's a wireframe mockup idea, and some notes, at 
https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Redesign_user_preferences#The_Appearance_menu

Ideally it would Not be in Special:Preferences, but would instead be a menu that all users, even readers who are not logged-in, can use. Saved in cookies/localstorage, if the user isn't logged-in.

I included "Appearance" as well as "Accessibility", partially because they often overlap, and partially because FLOE and GPII do the same, eg http://www.floeproject.org/prefsEditors.html (both the top-right live-example of "Show display preferences", and the video).
Comment 2 Matthew Flaschen 2014-09-18 04:24:48 UTC
(In reply to Quiddity from comment #1)
> Ideally it would Not be in Special:Preferences, but would instead be a menu
> that all users, even readers who are not logged-in, can use. Saved in
> cookies/localstorage, if the user isn't logged-in.

If it's available to logged out users, that means it probably has to implemented client-side in JavaScript (to avoid cache fragmentation).  That may make sense for certain limited settings, like font size, but probably won't work for everything.

See bug 20151.
Comment 3 Quiddity 2014-10-12 18:32:50 UTC
Created attachment 16750 [details]
wireframe idea

I've simplified the wireframe* to just show: controls for Font-size, Line-height (density), Text-Contrast, and Fixed-width. 
Matthew, are all of those possible to implement client-side in javascript, whilst avoiding FOUC (flash of unstyled content)?

(If this is likely to lead to a complicated discussion (?), perhaps we should take it onwiki, or to the design-list. :)

*(old versions accessible at https://commons.wikimedia.org/wiki/File:Wireframe_of_Appearance_menu.png )
Comment 4 Matthew Flaschen 2014-10-25 02:11:54 UTC
(In reply to Quiddity from comment #3)
> Created attachment 16750 [details]
> wireframe idea
> 
> I've simplified the wireframe* to just show: controls for Font-size,
> Line-height (density), Text-Contrast, and Fixed-width. 
> Matthew, are all of those possible to implement client-side in javascript,
> whilst avoiding FOUC (flash of unstyled content)?

Not sure.  I think the most straight-forward way to implement variants within a skin is to have a class name on the body (e.g. mw-accessibility-fixed-width) that affects the behavior of the skin's LESS/CSS. (This is facilitated by the fact that you asked for fixed variants, not arbitrary values).

This could be added in JavaScript, but I'm not sure if there's a way to do so without a FUOC.  Even if the CSS and JavaScript is top-loaded, I don't know if the class can be put in place at the top, or would have to be added at the bottom (e.g. in a document ready event).

Adding it in PHP using a preference would not be an issue, and shouldn't cause a FUOC.

We should bear in mind we don't want too many, or non-superficial, variations within a skin.  At some point a new skin may become appropriate.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links