RE: Submit Event: RE: Automatic submission of forms and screen changes

> What I don't understand why it is desirable to have the Submit event
> fire when they ENTER key is pressed even if the SUBMIT button does not
> have focus.

I think it's not desirable, either, but the most important is that it is a
convention (I guess pressing <Return> to submit forms is very common). From
Usability view, conventions are useful because many (or most) people know them,
and you don't (and shouldn't) overstrain them by introducing a new
implementation every day.

> The SUBMIT button could even be off the screen, yet pressing
> the ENTER key causes an action to occur. Accidentally submitting a form
> is an error that I have observed quite often, and not only with JAWS
> users.

That is what's not desirable, but you cannot prevent this (beside using e.g.
JavaScript to validate the form without sending a request; this might be a
workaround).

By the way, an automatic form submission seems to me like a Usability
'holocaust' -- me, I maybe want to check my entries, and maybe I even want to
cancel because I think it's nuts registering or buying (!).


Regards,
 Jens Meiert.



> What I don't understand why it is desirable to have the Submit event
> fire when they ENTER key is pressed even if the SUBMIT button does not
> have focus. The SUBMIT button could even be off the screen, yet pressing
> the ENTER key causes an action to occur. Accidentally submitting a form
> is an error that I have observed quite often, and not only with JAWS
> users.
> 
> Chris Brainerd
> Instructional Designer
> Real Choices ACCESS
> Center on Disability Studies
> University of Hawaii
> Chris.brainerd@cds.hawaii.edu
> 808-956-9356
> 
> 
> 
> -----Original Message-----
> From: Charles McCathieNevile [mailto:charles@w3.org] 
> Sent: Sunday, June 29, 2003 3:57 AM
> To: Chris Brainerd
> Cc: Kerstin Goldsmith; w3c-wai-gl
> Subject: Re: Submit Event: RE: Automatic submission of forms and screen
> changes
> 
> 
> I think this is a bad approach - the submit input is specifically
> designed so even simple systems know what to do with it.
> 
> This seems the interactive equivalent of using a font tag to specify a
> heading, because a few browsers had a bad way of handling heading
> elements.
> 
> I agree that there is a general problem here, because usability for some
> is compromising other people's ability to rely on their systems. It is a
> software issue, and it is to some extent addressed in UAAG.
> 
> If JAWS really does this I think that is a grave mistake in their
> interface programming (or in the discussions of it they have had with
> browser makers, who admittedly they don't control).
> 
> my 2 cents worth
> 
> Chaals
> 
> On Thu, 26 Jun 2003, Chris Brainerd wrote:
> 
> >
> >This raises an issue I have struggled with pertaining to the Form 
> >Submit button. Pardon me if this has been discussed previously.
> >
> >The default behavior of the Form Submit button is to fire the Submit 
> >Event when the ENTER key is pressed.
> >
> >This interferes with the JAWS screen reading program, in that this 
> >program requires use of the ENTER key to activate "forms mode", which 
> >allows JAWS users to complete Forms. The default behavior of the Submit
> 
> >button hinders JAWS users entering "forms mode." Often the Form is 
> >unintentionally submitted. Admittedly, this is a JAWS software issue.
> >
> >However, there have also been studies that show users who are 
> >unfamiliar with the Web and some with cognitive disabilities press the 
> >ENTER key after typing in a text box, again unintentionally submitting 
> >the Form. This could be considered an "unexpected action" and "change 
> >of context".
> >
> >My solution is to not use the Form input type "submit" but rather to 
> >use type "button" and add script to fire the Submit Event.
> >
> >Comments?
> >
> >Chris Brainerd
> >Instructional Designer
> >Real Choices ACCESS
> >Center on Disability Studies
> >University of Hawaii
> >Chris.brainerd@cds.hawaii.edu
> >808-956-9356
> >
> >
> >-----Original Message-----
> >From: Kerstin Goldsmith [mailto:kerstin.goldsmith@oracle.com]
> >Sent: Wednesday, June 25, 2003 6:31 PM
> >To: w3c-wai-gl
> >Subject: Automatic submission of forms and screen changes
> >
> >
> >
> >Hi,
> >
> >Question: the NFB put together a list of guidelines for the web, and 
> >one
> >
> >of them seems quite pertinent;  I know that we have run into it in 
> >several ways, and it's definitely disorienting for a vision-impaired 
> >user.  I am wondering where similar language is found in the current 
> >WCAG 2.0 draft, if at all.  If it's not there, does anyone have any 
> >thoughts on the requirement?
> >
> >"Ensure that menus and other navigation controls can be operated 
> >without
> >
> >causing form submission or screen changes."  For us, there has to at 
> >least be some warning to the user, or there has to be some kind of user
> 
> >action required before form submission or screen change.
> >
> >I tried to find this under Guideline 2 somewhere, but maybe it's too 
> >late at night for that?  <smile>
> >
> >Thanks for any guidance/thoughts,
> >
> >-kerstin
> >
> >
> 
> -- 
> Charles McCathieNevile  http://www.w3.org/People/Charles  tel: +61 409
> 134 136
> SWAD-E http://www.w3.org/2001/sw/Europe         fax(france): +33 4 92 38
> 78 22
>  Post:   21 Mitchell street, FOOTSCRAY Vic 3011, Australia    or
>  W3C, 2004 Route des Lucioles, 06902 Sophia Antipolis Cedex, France
> 
> 


-- 
Jens Meiert

Steubenstr. 28
D-26123 Oldenburg

Mobil +49 (0)175 78 4146 5
Telefon +49 (0)441 99 86 147
Telefax +49 (0)89 1488 2325 91

Mail <jens@meiert.com>
Internet <http://meiert.com>

Received on Tuesday, 1 July 2003 07:49:45 UTC