Re: Automatic submission of forms and screen changes

Gregg/John/Loretta/Wendy:

Thanks for the responses - I think Loretta was right, John was right, 
too, and then Gregg found the issue addressed in Checkpoint 3.4 
(predictable). The issue was indeed drop-down lists (or other controls) 
that fire selections when users walk through, or arrow down/up, those 
selections, instead of only firing the event (selection) when the user 
has explicitly finished choosing.  I think there are still ways of 
scripting such lists where the ALT ARROW DOWN does not work in all 
cases, and those cases (I believe) should be discouraged.  From reading 
3.4, I think the issue is addressed by telling users to at least let the 
user know when content/context is going to change.  Thanks, Gregg.

Cheers,
-Kerstin


Gregg Vanderheiden wrote:

>I would think that would be covered by the one talking about predictable
>behaviors.   Not predictable if you cannot see that you are on the last one.
>
> 
>Gregg
>
> -- ------------------------------ 
>Gregg C Vanderheiden Ph.D. 
>Professor - Ind. Engr. & BioMed Engr.
>Director - Trace R & D Center 
>University of Wisconsin-Madison 
>
>
>-----Original Message-----
>From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
>Of John M Slatin
>Sent: Thursday, June 26, 2003 1:59 PM
>To: Loretta Guarino Reid; Wendy A Chisholm
>Cc: Kerstin Goldsmith; w3c-wai-gl
>Subject: 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/
>>/-- 
>>
>>    
>>
>
>
>
>  
>