- From: Doug Gibson <dgibson@dgibson.net>
- Date: Wed, 15 Sep 2004 21:41:09 -0400
- To: <w3c-wai-gl@w3.org>
> On Sun, 12 Sep 2004 18:36:43 -0700, Matt May <mcmay@bestkungfu.com> wrote: > > > > I have published a first draft of the Scripting Techniques for WCAG 2.0: > > > > http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-SCRIPT-TECHS-20040910/ > > The 1.3 example is simply wrong (and dangerously so) it's wrong in the > sense that you shouldn't return false in an onsubmit and then call > submit(), you're risking an endless loop (whilst slightly > under-specified the submit function is not defined to explicitly not > call the submit event) but more importantly the idea that you can use > such a field to announce client-side validation has taken place is > simply wrong! You MUST validate on the server if validation matters > (consider a bank that only validates you have permission to move money > from one account to another on the client, but uses this case!) The security hazard in this example has already been pointed out and seconded. I've seen the same thing done more elegantly (creating a more elegant security hole...) and perpetuated in user groups using something like: <noscript> <input type="hidden" name="validationrequired" value="1"> </noscript> But my point in responding is that I think 1.3 should be reworked and still exist, as there's plenty to say about client-side validation in accessible scripting. The topic is good, the example is bad. Form validation being the most common use for JavaScript, it would be helpful to mention how it can be used accessibly and even point out explicitly that you should NEVER use client-side scripting (or lackthereof) to bypass or short-circuit server-side validation. The improved response time (better user experience, potentially) and server trips saved by client-side validation are often valuable enough despite this small limitation. Does anyone have a good example of good, robust, accessible client-side validation? I'm working on a system now that mimicks my server-side process, but should have looked at what's out there first I suppose. > 2.1 has similar return false problems (especially bad with > window.open, as popup blockers generally silently fail so the window > wouldn't open.) I would agree that it's a good idea to refrain from using window.open in most examples except when discussing popups specifically, because of the complexity (and potential inaccessibility) of the popup blocking issue. My personal mantra is "popups are not reliable, and are not needed." Like frames, clever coding can usually get around the "need" for them. -------------------- Doug Gibson Cold Fusion Web/Application Developer ICQ: 345916 AIM & YIM: dgibson666 http://www.dgibson.net/ http://www.metalunderground.com/
Received on Thursday, 16 September 2004 01:41:29 UTC