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

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


******Delurking*****

Hi, Everyone

As a multimedia artist, with formal training as a painter, I must admit
that
I enjoy the visual communications abilities that the web enables. That,
in
fact, was something that caused it to blossom: the ability to have
inline
graphics was a step above what gopher or bbs ascii sigs allowed. That
said,
I am also a long time web design professional, have been watching the
list
for months, have been working on making accessible sites, and think that
I
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
that
one of the most abused functions of javascript is the onmouseover
effect,
which has been in many ways rendered moot (in IE5 at least, for text
links)
by the combination of a title in the href and the a:hover element in
CSS.
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
accessibility
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
found
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).
Then
to get the client's USER-AGENT http header (with server-side scripting
being
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.
I
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:
http://www.highermind.com/design/beta/user_agent/index.html
so if anyone with screen reading or other non-visual software would care
to
go to that page, it will help create a list of different clients that
can
then be filtered into the appropriate directions for easier serving. I
will
leave this list of clients online for anyone to use, and I hope that you
can
help me. As a note, though, to anyone using Netscape or IE on a Mac, I
am
using a javascript to gather the plug-ins names, and if anyone could
suggest
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
http://www.highermind.com/

Received on Saturday, 14 July 2001 09:54:52 UTC