https://bugzilla.wikimedia.org/show_bug.cgi?id=4901
--- Comment #36 from Aryeh Gregor <[email protected]> 2011-05-19 18:22:13 UTC --- (In reply to comment #34) > I don't accept that there's a useful concept of regular browser. The concept of a regular browser is essential, because the ones who create and maintain site content, and MediaWiki developers and sysadmins, are overwhelmingly people who use regular browsers almost exclusively. Any feature whose purpose is to change how pages work in regular browsers is easy for all of us to reason about. If something doesn't affect regular browsers, it's far more likely to be used improperly, because whoever's using it probably won't see the effect. Thus we need to be more careful when deploying it, to take care that it's actually useful. > People using > screen readers use them to operate (“regular”) desktop browsers. Is the Google > search indexer a regular browser, or is Google Language Tools? Or Mobile > Safari > on an iphone used by a blind person? What about the screenscrapers used by the > countless sites that syndicate wikimedia sites? None of these are "regular" in the sense I mean. That doesn't mean they're unimportant, but it means that it's much more important that we be careful about targeting features at them, because it's hard for almost all of us to directly evaluate the effects. Look at how much snake oil is marketed at SEO, or how often people provide alt text that's useless or even worse than useless (e.g., unpronounceable numeric filenames that screen readers will read out at length). Adding features that you haven't tested on the theory that they might be useful and probably won't hurt is not a great strategy for software development. > We're not experts, and we don't have a detailed comprehensive survey of > accessibility software and hardware capabilities, nor are we ever likely to. > The best we can do is follow accepted, unchallenged standards. If you do have > information that disputes them, I would be interested. But grumbling about > them > is unhelpful. I've argued in the HTMLWG with some of the people who write these standards. My (admittedly biased) take is that they know a lot about accessibility, but often don't fully appreciate the requirements of authors, browser implementers, or non-disabled users. A huge percentage of disputes about HTML5 that had to be adjudicated by Working Group survey, on the order of half, are about accessibility: http://www.w3.org/html/wg/#events That's because it's the browser implementers who edit the HTML5 standard, and the accessibility people are regularly unable to convince them that the requirements they want are reasonable, so the dispute essentially has to be arbitrated. Specs like WCAG are written by a11y experts with relatively little involvement of non-a11y-focused web experts, and IMO should be viewed with a healthy dose of skepticism as a result. (Which is not the same as saying they should be disregarded.) Even aside from that, many standards have a tendency to be impractical or theoretical. Lots of stuff in HTML 4.01 didn't match what any browsers did or intended to do, for instance. The XHTML line of standards after 1.0 was basically never implemented at all. Trusting that what standards say makes sense is maybe a reasonable first guess, but you definitely shouldn't assume it very strongly. -- 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
