RE: Automatic submission of forms and screen changes

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] 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/
/--