W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2003

Re: Automatic submission of forms and screen changes

From: Kerstin Goldsmith <kerstin.goldsmith@oracle.com>
Date: Thu, 26 Jun 2003 13:07:45 -0700
Message-ID: <3EFB5291.4090500@oracle.com>
To: gv@trace.wisc.edu
CC: "'John M Slatin'" <john_slatin@austin.utexas.edu>, "'Loretta Guarino Reid'" <lguarino@Adobe.com>, "'Wendy A Chisholm'" <wendy@w3.org>, "'w3c-wai-gl'" <w3c-wai-gl@w3.org>
Sounds good to me.

-Kerstin

Gregg Vanderheiden wrote:

> Of course,  sighted people could think it was entirely predictable.  
> This would be a good candidate for an example in the guidelines.
>
>  
>
>  
> Gregg
>
>  -- ------------------------------
> Gregg C Vanderheiden Ph.D.
> Professor - Ind. Engr. & BioMed Engr.
> Director - Trace R & D Center
> University of Wisconsin-Madison
>
> -----Original Message-----
> From: Kerstin Goldsmith [mailto:kerstin.goldsmith@oracle.com]
> Sent: Thursday, June 26, 2003 2:47 PM
> To: gv@trace.wisc.edu
> Cc: 'John M Slatin'; 'Loretta Guarino Reid'; 'Wendy A Chisholm'; 
> 'w3c-wai-gl'
> Subject: 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> [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 <mailto: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 16:09:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:22 GMT