Last modified: 2014-09-24 00:03:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 18465 - Monobook <strong> for accessibility to selected items
Monobook <strong> for accessibility to selected items
Status: NEW
Product: MediaWiki skins
Classification: Unclassified
MonoBook (Other open bugs)
unspecified
All All
: Low minor
: ---
Assigned To: Nobody - You can work on this!
: accessibility
Depends on:
Blocks: css
  Show dependency treegraph
 
Reported: 2009-04-14 18:44 UTC by Dan Jacobson
Modified: 2014-09-24 00:03 UTC (History)
5 users (show)

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


Attachments
patch (1.26 KB, patch)
2009-04-14 18:44 UTC, Dan Jacobson
Details

Description Dan Jacobson 2009-04-14 18:44:44 UTC
Created attachment 6027 [details]
patch

Man it was tough, but I finally succeeded in getting <strong> for
selected, (and even <em> for new) into MonoBook for the most important
items, finally achieving accessibility.

[Below is the justification rant that I was going to send, in order to
badger someone else into fixing it, before I decided to see if I could
fix it myself, which I did, producing the patch, which please apply.]
--Begin rant--
Regarding the $prevent_active_tabs in SkinTemplate.php:
Well, did you know that for text browser users, this is permanently
on.

What I'm saying is the current method of indicating which tab is
active depends on stylesheet elements. This creates a browser accessibility
disadvantage.

Haven't you seen a device or browser where CSS is not supported,
_intentionally_ by the way?

I mean here you even have access keys [c] etc. but fail accessibility
101.

Therefore you should use HTML <strong> to show which tab is active.

That way you would have an even playing field, accessibility-wise.

Turn off stylesheets in your browser to see how some users lose out.

Stylesheets are for prettiness. Here you have crossed the boundary and
are making information to the user depend on them too!

And the there's the concept of "redlinks"... 1) those in the tabs. 2)
those in the text. Well, at least in some browsers one can tell that
the name it links to says redlink in it. But for the aforementioned
active tabs, "only the <strong> will survive" the accessibility test.
--End rant--

Anyway, here I have fixed the accessibility for the tabs, actually the
"Views" one sees with CSS off.

As far as general redlinks in the text, well, we'll leave that for
next episode.

As far as non MonoBook, I'll leave that to other folks...

you might not want to use classes at all, compare bug #18317.

Or you might even want to make the selected item unclickable...not linked.
Comment 1 Siebrand Mazeland 2009-05-17 19:09:24 UTC
Please provide this for all skins. We do not want the functionality of the skins to deviate.
Comment 2 Dan Jacobson 2009-05-18 12:54:28 UTC
What do you know, the same patchfile worked on Modern.php
# patch Modern.php patchfile
patching file Modern.php
Hunk #1 succeeded at 112 with fuzz 2 (offset -25 lines).
Hunk #2 succeeded at 137 (offset -25 lines).

CologneBlue doesn't array content_actions in the first place, so it's
already an even playing field, for better or worse. Same for Standard
and Nostalgia.

Chick, MySkin, Simple all inherit from MonoBook

Be very careful that you are sure that the <strong> and <em> I am
using here are the best choices for the job. As the <em> will then
become the basis for treating all the redlinks in the entire wiki,
upon the day we decide that we should go further and do something to
distinguish them for those whose browsers can't see red, etc., for not
only those links around the edges of the page we are dealing with
today, but for all the page content too.
Comment 3 Sumana Harihareswara 2011-11-24 19:32:40 UTC
jidanni, sorry, but the MediaWiki codebase has changed enough since you submitted your patch that it no longer applies cleanly to trunk.  Would you be interested in updating your patch and including improvements for other skins as well?  Thank you.
Comment 4 Sumana Harihareswara 2011-11-24 19:32:59 UTC
Comment on attachment 6027 [details]
patch

Per automated testing
http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056340.html patch
no longer applies to MediaWiki trunk in Subversion.
Comment 5 Dan Jacobson 2011-11-24 23:27:39 UTC
Let this be a lesson for me. Bye.
Comment 6 Bartosz Dziewoński 2013-04-20 19:39:35 UTC
[Bug metadata cleanup, lowering importance.]

If we want to do this, it should likely be part of the functionality of BaseTemplate::makeListItem() (to automagically happen in all skins). But to be honest, I'm really not sure if it's a good idea in general.
Comment 7 Daniel Friesen 2013-04-20 20:19:27 UTC
Honestly, selected tab IS style. Partially functional style like some other things. But style nonetheless. It is not something that has to be present for things to work.

And every browser we support supports css. Sorry but ancient text browsers are not browsers we support.

Though there might be some aria attributes we may want to apply.

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


Navigation
Links