W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2001

Re: [media] Making Sites Accessible Makes Sense For All Customers

From: Kynn Bartlett <kynn@reef.com>
Date: Tue, 13 Feb 2001 18:16:53 -0800
Message-Id: <>
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 Bartlett <kynn@reef.com>
Technical Developer Liaison
Customer Management/Edapta
Reef North America
Tel +1 949-567-7006
Received on Tuesday, 13 February 2001 21:07:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:11 UTC