https://bugzilla.wikimedia.org/show_bug.cgi?id=4901
--- Comment #39 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2011-05-20
18:44:09 UTC ---
As usual, I can't resist arguing just a bit more . . .
(In reply to comment #37)
> Then please define “regular browser,” at least broadly.
>
> Does this include MSIE 9? Safari 4? MSIE 6? Netscape 4? Mobile Safari?
> BlackBerry mobile browser? What about the yet-unreleased MSIE 10, Firefox 5,
> Safari 6, etc?
Yes. Those all display web pages in basically the same way, give or take some
details. Mobile browsers are a bit different, but they're mainstream enough
that they fall into the same category -- a large percentage of people use them
regularly. Thus we can easily make informed decisions about how various
features will affect them. Just try it out.
Search engine spiders and screenreaders work in fundamentally different ways
from the browsers we use, and we don't have experience with how they work.
("We" here means you, me, and the overwhelming majority of
Wikipedians/MediaWiki developers/etc.) We cannot easily know offhand what
effects our decisions will have on such UAs, so we have to be much more
cautious in making decisions based on those effects. Reasoning and evidence
needs to be spelled out more explicitly than for regular browsers.
> Does it include supporting readers who navigate web pages using the keyboard?
Exclusively? No, because almost no one does that. (Which, again, is not to
say that those people are unimportant, but that other people can't easily
evaluate the impact that changes will have on them.)
> Using a touch device?
Yes, many people use smartphones regularly these days.
> Using a text-only browser? A braille display?
Nope.
> (And why would you not include Google's indexer? I'd bet that more people
> access more Wikipedia articles through it than any other way.)
We use the search results. That doesn't give us more than the most minimal
insight into how the indexer works, beyond really basic stuff like "it mostly
doesn't do JavaScript".
> I think it's a mistake to categorize “regular” use of a website as that
> involving a narrowly stereotyped range of technology, especially if we try to
> define assistive technologies as irregular. This risks specifically
> ghettoizing
> a disadvantaged group of people. Design and technical features for
> accessibility have the potential to improve a whole range of uses of a
> website.
I think it's a mistake to try adding features that you haven't tested and don't
intend to test, that no one who reviews your code will test either, and that
you'll probably never receive any real-world feedback on, solely based on
something you read, where you are in no position to personally evaluate the
validity of the source (e.g., have not been provided with info on how exactly
specific real-world UAs will handle the feature). The most likely outcome is
that the feature is useless, and in some cases it could be harmful.
(See bug 15491 for an example of someone making incorrect claims about the
accessibility impact of a particular bug, based on theoretical reasoning rather
than actual testing.)
> > because the ones who create and
> > maintain site content, and MediaWiki developers and sysadmins, are
> > overwhelmingly people who use regular browsers almost exclusively
>
> [Citation needed]
It doesn't need a citation, because it's a tautology -- that's my definition of
"regular browser". Do you argue that more than a small minority (say, 5%) of
the people I mentioned use screen readers regularly, or are personally familiar
with how search engine spiders work (as in writing them and not just reading
the results)?
> Those are't the standards we are using. We are using current, practical,
> accepted standards.
You assume WCAG is practical. It's certainly not as useless as XHTML2, but
it's not such a clearly good standard that I wouldn't prefer real-world info on
how screen readers use the lang attribute. If you're aiming for usability
improvements, give me an actual user study over a standard any day of the week.
Interestingly, this is Google result #5 for "WCAG":
http://www.alistapart.com/articles/tohellwithwcag2
But FWIW, a quick Google search turns up some data that suggests that specific
major screen readers really do use lang, so I'm fine with adding it (although I
never had serious objections to start with):
http://reference.sitepoint.com/html/core-attributes/lang
http://developer.yahoo.com/blogs/ydn/posts/2008/03/yahoo_search_re/
I'd never have objected if that was the original reasoning given for the
change, instead of WCAG. Real-world data is always more useful than standards,
if your goal is to improve user experience instead of adhering to the standards
per se.
> I see no strong argument against using hreflang attributes, but I don't think
> they're absolutely necessary. I support adding a feature that might improve
> the
> experience with assistive technology, but I'm okay with moving that to a
> separate bug listing if it will give us consensus here.
We don't really need consensus. If Brion wants to add it, he can do so, and
I'm not going to object further. I still don't think we should support it
without a clear reason, but it's not up to me to decide.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
