- From: Kerstin Goldsmith <kerstin.goldsmith@oracle.com>
- Date: Thu, 26 Jun 2003 13:07:45 -0700
- 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>
- Message-ID: <3EFB5291.4090500@oracle.com>
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 UTC