RE: Accessible road maps

> > also useful.  For example, checking the required fields in a form on the 
> > client before sending the data to the server is common and creates no > > disability issues.  Scripts that add interactive visual highlighting 
> Except it does in practice, as it is common for the form actually 
> submitted not to be the form that is completed by the user or for the
> control that triggers the submission not to be a control that would
> naturally trigger the submission.  Basically this is complicated because
> it tends to be associated with a desire to re-write the browser's user
> interface behaviour.

I have read this several times and am unable to make any sense out of it.
Are you simply trying to find ANY reason to dislike scripts?  It is this
attitude that inhibits, not promotes, good designs and coding practices.
What does "...as it is common for the form actually submitted not to be
the form that is completed by the user..." mean?  What happened to the 
form the user completed?  What is actually submitted?  On what basis in 
fact are you able to state "...as it is common..."?  If it is common, 
perhaps a long list of examples would be helpful?  

I am also confused by the idea that submitting a form to a server and
having it sent back to the user due to an error/omission on the form is
a better, faster, or more accessible approach.  There is a significant 
amount of discussion about load times, this approach requires doubling
the load time.  Triggering an alert dialog box on the client side is not 
unique to browser applications, yet when this technique is employed via 
a browser objections are raised.  Please help me to understand the 
difference between a word processing program and browser rendering an alert.


Kurt Mattes
Application Development Analyst - Lead Developer
Kurt_Mattes@BankOne.com



-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
Behalf Of David Woolley
Sent: Wednesday, June 02, 2004 2:35 AM
To: w3c-wai-ig@w3.org
Subject: Re: Accessible road maps



> also useful.  For example, checking the required fields in a form on the > client before sending the data to the server is common and creates no 
> disability issues.  Scripts that add interactive visual highlighting 

Except it does in practice, as it is common for the form actually 
submitted not to be the form that is completed by the user or for the
control that triggers the submission not to be a control that would
naturally trigger the submission.  Basically this is complicated because
it tends to be associated with a desire to re-write the browser's user
interface behaviour.

> (onMouse over's) improve usability and benefit the learning disabled. 

Except when the home page is a browser sniffing page that comes up blank
without scripting.  Moreover, there are declaritive ways of doing 
reasonable mouseover effects on text, and if they are desirable feedback
cues, they ought to be built into the browser's standard behaviour.
(Image mouseovers tend to slow down load times on pages that are already
too slow to load.)

> ease of use, etc. then client side processing is the answer.  In other 
> words, that is why it was invented, to reduce the burden on the server. 
I'm not convinced that that is why Netscape invented it.  I'm pretty
certain that the IE extensions to the original Netscape scripting aren't
intended for that purpose.  Certainly only a small proportion of scripting
in the field is for validation.  Most of it is to create user interface
behaviours, i.e. to extend or replace the browser's user interface.

I'd believe the server loading issue more if sites didn't do things that
made static images and pages uncachable, as a matter of policy.



**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************

Received on Wednesday, 2 June 2004 07:12:40 UTC