RE: SC 3.2.2: Keyboard Events and Changing the Setting of an Input Field

The character doesn't show in the field.  But the user did enter data into
the field.

It would be similar to a custom control (radio button) where the person
clicked on a button but instead of reflecting the input with a change in
visual appearance of the control you just jumped to a new page.

There was no visual effect but the person still provided input to the
control.

Unless I'm not seeing something here - I don't think this is a loophole. I
think it is clear that the user entered data into the field even if it
wasn't reflected or even if it didn't actually get to the field.    It is
what the user experiences that rules here I think.


Gregg
 -- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: w3c-wai-gl-request@w3.org
> [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Christophe Strobbe
> Sent: Thursday, February 15, 2007 6:59 AM
> To: WCAG
> Subject: RE: SC 3.2.2: Keyboard Events and Changing the
> Setting of an Input Field
>
>
> Hi Gregg,
>
> At 05:21 15/02/2007, Gregg Vanderheiden wrote:
> >Hi Christophe,
> >
> >(...)
> >For the script to get any content the content would have to at least
> >instantaneously go to the input field - no?    So that would
> be a change to
> >the state of the field.  It would go from nothing yet
> entered to one that
> >had a character sent to it.  Or some such.   Or did I miss something?
>
> In the example at http://tinyurl.com/3btmhm the focus changes
> at the first keypress inside the input field. The character
> you type is never visible in the input field, so one might
> argue that the setting of the input field was never changed,
> and that, consequently, SC 3.2.2 does not apply.
> (In the example above, this behaviour is rather useless, but
> I don't have a better example at the moment.)
>
> I hope this clarifies the issue.
>
> Best regards,
>
> Christophe
>
>
>
> >Gregg
> >  -- ------------------------------
> >Gregg C Vanderheiden Ph.D.
> >
> >
> >
> > > -----Original Message-----
> > > From: w3c-wai-gl-request@w3.org
> > > [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Christophe Strobbe
> > > Sent: Wednesday, February 14, 2007 8:08 AM
> > > To: WCAG
> > > Subject: SC 3.2.2: Keyboard Events and Changing the Setting of an
> > > Input Field
> > >
> > >
> > > Hi,
> > >
> > > During a review of WCAG 2.0 test cases in the BenToWeb
> project, we
> > > ran into the following issue.
> > >
> > > Success criterion 3.2.2 requires: "Changing the setting
> of any form
> > > control or field does not automatically cause a change of context
> > > (beyond moving to the next field in tab order), unless
> the authored
> > > unit contains instructions before the control that describe the
> > > behavior." "How to Meet Success Criterion 3.2.2" explains: "The
> > > intent of this success criterion is to ensure that
> entering data or
> > > selecting from a control has predictable effects.
> (...)"[1] This is
> > > straightforward enough at first sight: for example, when a user
> > > enters text into an input field, browses a menu or checks a radio
> > > button, browsers should not change the focus or load a new page.
> > > However, if a client-side script captures the keyboard
> events on an
> > > input field and changes the focus or loads a new page (i.e.
> > > instead of displaying the user's input), so that the
> user's input is
> > > never visible in the page, does that constitute a change of the
> > > setting of an input field? [2] The intent of the success
> criterion
> > > is to prohibit this behaviour, but the letter of the success
> > > criterion appears to leave a small loophole. Possibly, a
> definition
> > > of "changing the setting of a form control or field /
> user interface
> > > component" that includes input events could stop this loophole.
> > >
> > > [1]
> > > http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/Ove
> > > rview.html#consistent-behavior-unpredictable-change
> > > [2] There are currently examples at
> > > http://www.bentoweb.org/ts/XHTML1_TestSuite2/testfiles/sc3.2.5
> > > _l3_010.html
> > > (change of viewport: moving the browser window [browser-dependent
> > > behaviour)]) and
> > > http://tinyurl.com/3btmhm
> > > (change of focus). Note that these test cases are
> currently mapped
> > > to SC 3.2.5 instead of 3.2.2.
>
>
> --
> Christophe Strobbe
> K.U.Leuven - Departement of Electrical Engineering - Research
> Group on Document Architectures Kasteelpark Arenberg 10 -
> 3001 Leuven-Heverlee - BELGIUM
> tel: +32 16 32 85 51
> http://www.docarch.be/
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
>

Received on Thursday, 15 February 2007 16:12:56 UTC