RE: Automatic submission of forms and screen changes

I think Loretta's right-- this issue sounds like it has to do with
things like onChange events, where the script fires the instant focus
moves to an item in a select list.  (Kirsten, is this right? Or when you
mentioned menus etc., were you thinking of other elements?)

onChange events might come under the checkpoint, however.  They can be
successfully operated from the keyboard provided that (a)the user knows
the keystrokes for opening a pulldown menu (alt+downarrow), and (b) that
the user uses that keystroke *before* trying to arrow down into the list
without opening it first.  (This doesn't work if the list is already
open, for example if it's a 5-line list with only 5 items in it; then it
fires the instant the downarrow is pressed.)

John

John Slatin, Ph.D.
Director, Institute for Technology & Learning
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.ital.utexas.edu
 


-----Original Message-----
From: Loretta Guarino Reid [mailto:lguarino@adobe.com] 
Sent: Thursday, June 26, 2003 1:46 pm
To: Wendy A Chisholm
Cc: Kerstin Goldsmith; w3c-wai-gl
Subject: Re: Automatic submission of forms and screen changes 



Wendy,
  I thought that the issue was with forms that would automatically
submit 
themselves when the last field was filled in. This is different from
making 
sure things can be activated via the keyboard.  And I'm not sure any of
the 
current checkpoints covers this situation.

	Loretta

> 
> Hello Kerstin,
> 
> I think that checkpoint 2.1 (All functionality is operable at a 
> minimum
> through a keyboard or a keyboard interface) [1] and its required
success 
> criterion address part of this issue - "Ensure that menus and other 
> navigation controls can be operated." I'm not sure about the other
piece, 
> "without causing form submission or screen changes."  I think it is
implied 
> that if you design something to work with a keyboard or keyboard
interface 
> it ought to work *well* but we might want to be more explicit. Perhaps
a 
> second success criterion that says, "operating the functionality
through a 
> keyboard or keyboard interface works in a way that is logical for the 
> keyboard user."  I'm not sure how to make this less subjective ("is
logical 
> for the keyboard user" is not testable), but here's a starting point
if we 
> think we want to go in this direction.
> 
> Are these [2] the NFB guidelines you are referring to?
> 
> Thoughts?
> --wendy
> 
> [1] http://www.w3.org/TR/WCAG20/#keyboard-operation
> [2] http://www.nfb.org/tech/webacc.htm
> 
> At 12:31 AM 6/26/2003, Kerstin Goldsmith wrote:
> 
> >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
> 
> --
> wendy a chisholm
> world wide web consortium
> web accessibility initiative
> http://www.w3.org/WAI/
> /-- 
>

Received on Thursday, 26 June 2003 14:59:01 UTC