EASI Archives

Equal Access to Software & Information: (distribution list)

EASI@LISTSERV.ICORS.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Louis Atkinson <[log in to unmask]>
Reply To:
* EASI: Equal Access to Software & Information
Date:
Sat, 14 Jul 2001 02:14:22 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (57 lines)
******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/

ATOM RSS1 RSS2