Re: Scripting (was RE: Accessible road maps)

On the time out request, it is possible to do this quite effectively by a
pre-log in.  The server can time out if it chooses and then accept an update
when it is shown to have a valid header.  That valid header could be
generated before the fact so that if the need arises and the request is
returned, the header opens the door like a key does.  I'm not saying that
client side scripting should not be used, I am saying though that there are
other ways of achieving this and they don't necessarily tie up bandwidth nor
do they have to be insecure or inaccessible.

Noscript can be quite helpfull if done correctly as can noframes.  The
problem with scripting is that you have to get it right for everyone.  The
nice thing about html and some other goodies is that you don't because if
the ua is up to the job, it is handled correctly.

The text vs html issue was not so much due to a lack of willingness to have
html as it was an understanding that it was more edittable and still is.
There are still many situations today in which plain text is the best thing
for the job but people will use html now quite simply because it has become
more ubiquitus and is available in a wider array of applications that
previously.

----- Original Message ----- 
From: "Phill Jenkins" <pjenkins@us.ibm.com>
To: <sdale@stevendale.com>
Cc: <w3c-wai-ig@w3.org>
Sent: Thursday, June 03, 2004 2:12 PM
Subject: RE: Scripting (was RE: Accessible road maps)


> That is an excellent example of why I don't think we should ban
scripting
> either.  But, it is an enhancement of speed in this case, not a
necessity.
>
>-Steve

Depends who the audience is.

If the response time is so slow going back to the server (instead of
client side),  then cognitive and learning disabilities issues come into
play.  In other words, if you click something, and nothing happens, how
long can one wait without being confused?  Client-side scripting solves
this necessity.  It is a disability issues that needed solving.  It is a
usability issue that needed solving.  Client side scripting techniques
need to be added so that developers know how to do it right.  A priority
one checkpoint to "ban scripting" is not the best approach.  A priority
one checkpoint to require that everything done with client side scripting
degrade gracefully is not always feasible.  Some in the past were banning
HTML documents in favor of plain text documents.  Most agree now that
structured documents are better than plain text.  Most agree now that
interactive documents (web based applications) are also better than just
structured documents.  Jim Thatcher explains the argument of how NOSCRIPT
does not provide the functionality of client side scripting. See
http://www.jimthatcher.com/webcoursea.htm

Plus, can you imagine an accessible way of asking a user if they need more
time to complete a secure transaction without using a client side
scripting alert?  This is a situation where the transaction has a physical
time limit with the server.  The server can't wait forever for the client
to respond, so it sets a reasonable time limit, but requires the client to
respond if more time is needed.  Just like in software application, a
dialog box appears alerting the users that time is about to expire and how
to request more time.  I only know how to do this with client side
scripting.  Sure it would be nice, and in many cases one can "wait
forever", but in many cases with secure financial and private data
transaction one can't wait for ever.

Phill Jenkins

Received on Thursday, 3 June 2004 15:17:36 UTC