- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Wed, 2 Jun 2004 16:56:01 -0400
- To: <Kurt_Mattes@bankone.com>, <w3c-wai-ig@w3.org>
> 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, What happens if the user agent does not render the alert? What if it is incapable of doing so, even if the rendering agent is otherwise standards compliant? This is a judgment call, and has an answer that can never be codified, as the real answer is "it depends..." The danger is assuming that there is a base level user agent which you can state with absolute certainty that all of your clients are using. In an Intranet setting, this may in fact be possible, but once you release to the world, all bets are off. As a conscientious developer, why would I put my total reliance on an unknown? Don't get me wrong, I like client side scripting, I use it occasionally, but I am also aware of the potential issues of accessibility I may be introducing and develop accordingly. I also have stated, on more than one occasion, that relying on client side scripting for *Mission Critical* functionality is foolhardy, and even potentially crippling to a site. If it is your personal blog or vanity site, no problems, have at it. But if you (I) am being paid by a client to produce a working web site, why would I take a chance that it doesn't work - no matter how remote that chance is? As for your question regarding comparing a word processor vs. a web browser - word processors generally are installed on tower or laptop computers, whereas web browsers now are being installed in car dashboards, cell phones, refrigerators, you name it (see: http://www.icesoft.com/), not to mention accessing web content via alternative browsers such as WebTV. None of this is directly related to users with disabilities per se, but rather only alternative user agents. It reaches a point where either you accept the randomness of the user agent stew and develop accordingly, or you forge on knowing that you are potentially causing access issues, but are willing to take the risk. The WCAG currently cautions on the conservative side, to be safe, and I for one agree with them. If you believe that it's a non-issue, if you cannot accept the arguments being presented which attempt to explain why some users would prefer to not have to rely on client side scripting, which have attempted to illustrate the potential dangers here, then ultimately, your mind has already been made up - you have reached the point of dogma. But I believe that there are currently enough of us in the accessibility community which will continue to speak out against the use of client side scripting in Mission Critical applications that it will probably never be an accepted component of "universal web accessibility". If you are mandated to be compliant to WCAG now (or in the future) then you will need to accept this point regardless of your personal point of view. JF -- John Foliot foliot@wats.ca Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca 1.866.932.4878 (North America)
Received on Wednesday, 2 June 2004 16:56:08 UTC