Last modified: 2011-10-14 22:06:04 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 15637 - Hiding categories via CSS violates accessibility
Hiding categories via CSS violates accessibility
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Categories (Other open bugs)
1.15.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: accessibility
Depends on:
Blocks: css
  Show dependency treegraph
 
Reported: 2008-09-18 14:20 UTC by Dan Jacobson
Modified: 2011-10-14 22:06 UTC (History)
6 users (show)

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


Attachments

Description Dan Jacobson 2008-09-18 14:20:41 UTC
Please change everybody's
[ ] Show hidden categories
to
[*] Hide hidden categories (CSS)

Reason: this is the only browser independent solution. Otherwise you
assume nobody uses text browsers, whose users scratch their head and
wonder why they still see the hidden categories.

Also just like you say JavaScript in
[ ] Edit pages on double click (JavaScript)
you should say CSS here.
Actually you should say "requires CSS" etc.
(I would say to also link [[CSS]] but most wikis don't have a [[CSS]]
article.)

Anyway, I bet there are lots of such preferences that assume everybody
uses IE or Firefox and don't mention their requirements that exceed HTML.
Comment 1 Niklas Laxström 2008-09-18 16:57:51 UTC
There is no reason why a text browser could not support CSS, at least partially. I'm not sure we want to bother the majority of users with details they don't care about. There could perhaps be a message shown only to users that don't have CSS enabled.
Comment 2 Dan Jacobson 2008-09-20 23:02:42 UTC
The text browsers (and search engine spiders) I know of don't
support CSS, and one often turns it off in browsers that do if one
doesn't want the visual clutter or extra traffic.

Yes, please make the words "(CSS)" disappear only when you CSS users browse
Preferences, or else other folks using various devices or screen
readers will think something is broken.
Comment 3 Dan Jacobson 2009-03-28 04:38:17 UTC
Allow me to redefine this bug.

Styleshees are for changing style.

Here you are making _information_ depend on stylesheets.

That is crossing the boundary and a clear violation of accessibility
principles.

The hidden categories should appear, or _disappear_, from the HTML,
not via the sytlesheet!

Sure, you could say most users don't need accessibility, but why throw it away for nothing?
Comment 4 Niklas Laxström 2009-03-30 09:25:31 UTC
How is accessibility relevant in this case when all information is there and accessible?
Comment 5 Dan Jacobson 2009-03-31 06:15:12 UTC
But you are unfair to text browser users: there is no way for them to
turn them off!

That's right, the so-called Hidden Categories will never be hidden for
text browser users!

Personally I like seeing the Hidden Categories here in my text
browser, and often read via unlogged-in WWWOFFLE, etc.

So maybe only have the hidden categories disappear if the user is
logged in and has hiding turned on (default=hide) in preferences.

I.e., the question is should unlogged in programs like search engines
see them? Currently the answer is yes and probably should stay so.

And remember stylesheets are for style, not for content, and here we
are very much talking about content, and we text browser users and
search engines don't know what you are hiding...
Comment 6 Andrew Garrett 2009-03-31 06:20:45 UTC
Doing it by any means other than CSS would cause unnecessary cache fragmentation, concerns for which far outweigh accessibility, as they affect a tiny minority of users.
Comment 7 Dan Jacobson 2009-03-31 06:39:14 UTC
I don't get it: if they are logged in you already say "Bob's
contributions", "Bob's user page" etc. custom stuff.
Well, you can also _not_ say the Hidden Category stuff in the HTML you
send, if that's what they have checked in preferences, which of course
should be the default for that preference.
Comment 8 Roan Kattouw 2009-03-31 14:57:59 UTC
(In reply to comment #7)
> I don't get it: if they are logged in you already say "Bob's
> contributions", "Bob's user page" etc. custom stuff.
> Well, you can also _not_ say the Hidden Category stuff in the HTML you
> send, if that's what they have checked in preferences, which of course
> should be the default for that preference.
> 

Because the HTML generated from wikitext is pulled from cache, not the entire HTML page.

Also, decent text browsers should understand basic CSS along the lines of display: none; . I believe Lynx does.
Comment 9 Dan Jacobson 2009-03-31 23:23:51 UTC
> Because the HTML generated from wikitext is pulled from cache, not the entire
> HTML page.

So then when you build the cache, instead of just throwing the hidden
categories into the same element as the rest, just put them into a separate
element, and then when the time comes you can easily just not use that
second element if not desired. Or something like that.

> Also, decent text browsers should understand basic CSS along the lines of
> display: none; . I believe Lynx does.

$ lynx -dump -nolist http://en.wikipedia.org/wiki/Phoridae | grep Hidden
   Hidden categories: All articles with unsourced statements | Articles

Thinking you can change _content_ via _style_sheets is misguided.

There is no boundary in you guys' minds where content ends, and style
begins.

Are you trying to hide the text from people, but show it to searchengines?
Comment 10 Brian Jason Drake 2009-06-26 06:20:29 UTC
The good thing about using CSS rather than HTML to hide items is that if the user changes their preferences, then even pages in the browser cache will reflect that change immediately.

What is the problem here? Just change

[ ] Show hidden categories
to
[*] Hide hidden categories (requires CSS)

in the preferences page. The words "hidden categories" on the preferences page, and the words "Hidden category" or "Hidden categories" on pages that are members of hidden categories, can be made into links that point to an explanation of hidden categories.
Comment 11 Dan Jacobson 2009-06-26 23:49:45 UTC
> Just change...
Just like in comment #1, but better.
Comment 12 Dan Jacobson 2009-06-26 23:50:38 UTC
Did I say comment #1? I meant comment #0.
Comment 13 John Mark Vandenberg 2011-10-14 06:01:33 UTC
It gracefully degrades in text-only browsers.  It is accessible.  Very large portions of mediawiki (inc. other preferences) depend on CSS in order to work properly.  The right 'fix' is to document that mediawiki depends on CSS, but degrades gracefully in most cases.  A report bugs where it does degrade badly.
Comment 14 Daniel Friesen 2011-10-14 22:06:04 UTC
Bug seams to have been closed hastily without an understanding of the issue.

We do rely on css to hide the hidden categories, but this is not documented in the prefs. So we 'should' either add that info to prefs or 'fix' the issue.

I don't particularly see a reason to put categories that are hidden in the markup when we're just going to hide them:
- catlinks is generated by the skin not from cache, anons all have the same prefs, and users aren't targeted by squid caches, so catlinks should be in a spot where we don't have an issue with server caches.
- Search engines generally don't need to see hidden categories. They generally have other ways to find things on the wiki. Tbh, categories are generally hidden because there is no need for people to be browsing them, likewise search engines don't need to bother. We shouldn't be basing whether we insert parts of the ui based on what search engines need anyways.
- Brian's comment on browser caches doesn't really matter. If that's relevant then there are likely other preferences we have which will be affected the same way which we don't do css for so that's nothing new. Anyways such an issue would be fixed when we deal with bug 31639 since a user_touched based ETag would change when a user changes their preferences thus invalidating their caches and making them see the new ui.

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


Navigation
Links