- From: Kynn Bartlett <kynn@reef.com>
- Date: Tue, 13 Feb 2001 18:16:53 -0800
- To: "Phill Jenkins" <pjenkins@us.ibm.com>, "David Poehlman" <poehlman1@home.com>, w3c-wai-ig@w3.org
At 05:52 PM 2/13/2001, Phill Jenkins wrote: >Last I checked [1][2] > Lynx was less than 1% of browsers > JavaScript was used on 37.45% of sites >Sounds like a lynx problem to me. >[1] BrowserWatch at internet.com >[2] http://www.securityspace.com/s_survey/data/man.200101/techpen.html Yikes. Browser stats are dangerous. It's very easy to get the wrong results, and it's _very_ easy to marginalize small groups of people and say "oh, they don't count." How many people use Home Page Reader or JAWS, as a fraction of the total web users? I get very nervous when stats and percentages are tossed around as the justification for making someone, essentially, a second class web user based on the fact that their browser isn't popular enough. If you want to argue that Javascript should be considered a required technology to supported, that's fine, I might even go there with you. But when you say that Lynx doesn't matter because X percentage says Lynx is worthless, that kind of numbers game doesn't float my boat. I'd much rather talk about user agent baseline assumptions -- a topic that's arisen on WCAG working group recently as well. What should any good web user agent be assumed to support, or is that question even worth asking? Me, personally, I don't know if it's a worthwhile question. I'd rather deliver divergent content streams and user interfaces based on the user agent's capabilities, than to say that certain user agents MUST meet my requirements. For example, HTML browsers on Palm may not be fully Javascript-enabled, and yet I'd still like to send an edapted interface down the line to them. Someone said in another post that he preferred the Section 508 approach of "allow Javascript since it's necessary" rather than the WCAG 1.0 approach of "disallow Javascript for anything useful." I think this is an example of "black-and-white" thinking, reducing the problem to an either-or binary choice. By having edaptive user interfaces, you're not locked into an either-or choice; you don't have to say "well, we can do it THIS way and screw THOSE users, or we can do it THAT way and screw THOSE OTHER users." You really can have it both ways. It just takes some more work on the back end -- but since web servers these days are moving away from pure "static content" anyway, it becomes a natural progression path to have an intelligent, edaptive server (likely understanding something like CC/PP). --Kynn -- Kynn Bartlett <kynn@reef.com> Technical Developer Liaison Customer Management/Edapta Reef North America Tel +1 949-567-7006 ___________________________________ BUSINESS IS DYNAMIC. TAKE CONTROL. ___________________________________ http://www.reef.com
Received on Tuesday, 13 February 2001 21:07:43 UTC