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

Fw: Re: Web Access; When the Rubber Meets the Road

From: David Poehlman <poehlman1@home.com>
Date: Sat, 14 Jul 2001 09:54:43 -0400
Message-ID: <003601c10c6c$89453520$2cf60141@mtgmry1.md.home.com>
To: "wai-ig list" <w3c-wai-ig@w3.org>

----- Original Message -----
From: "Louis Atkinson" <louis@HIGHERMIND.ORG>
Sent: Saturday, July 14, 2001 3:14 AM
Subject: Re: Web Access; When the Rubber Meets the Road


Hi, Everyone

As a multimedia artist, with formal training as a painter, I must admit
I enjoy the visual communications abilities that the web enables. That,
fact, was something that caused it to blossom: the ability to have
graphics was a step above what gopher or bbs ascii sigs allowed. That
I am also a long time web design professional, have been watching the
for months, have been working on making accessible sites, and think that
also have some points to make about enabling the easing of providing
suitable computerized interfaces to a wide variety of human interfaces.

I agree that the noscript javascript tag is most useful, I mostly use
javascript as a tool to enable my own development efforts. I have found
one of the most abused functions of javascript is the onmouseover
which has been in many ways rendered moot (in IE5 at least, for text
by the combination of a title in the href and the a:hover element in
The main problems with javascript are that it isn't universally
supported by
clients and can be turned off. The fact that it is a powerful scripting
language that executes *on the client-side* leads to not only
issues, but security ones as well.

>The principle of the lowest common denominator still applies; the goal
is to
>raise the denominator.

I have been trying to partially answer that question, and think I have
a partial solution. I'm sure many have heard of it before, but it is to
abstract the data from the presentation by keeping the data in a
database or
XML file (which is in many ways a text file-as -relational database).
to get the client's USER-AGENT http header (with server-side scripting
preferable to javascript) and serve the data with whichever interface is
relevant back to the client. This causes some headaches during the
development cycle (such as only being able to serve CSS based sites to
certain clients, text based to lynx and search engines), but will get
easier, and shouldn't preclude anyone from being left out.

My main problem with it at this point is that I do have a list of the
variety of USER-AGENT strings used by screen reading and other browsers.
have made a page that will gather that data (again, server-side, not
javascript), and which puts it into a database, which is located here:
so if anyone with screen reading or other non-visual software would care
go to that page, it will help create a list of different clients that
then be filtered into the appropriate directions for easier serving. I
leave this list of clients online for anyone to use, and I hope that you
help me. As a note, though, to anyone using Netscape or IE on a Mac, I
using a javascript to gather the plug-ins names, and if anyone could
a better way to do it, it would be greatly appreciated. Also, I am using
open source tools available by many hosting companies to do this.

Best regards,
Louis Atkinson
n-dimensional artist
Higher Mind Productions
Received on Saturday, 14 July 2001 09:54:52 UTC

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