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

Hi Gregg,

At 17:03 15/02/2007, Gregg Vanderheiden wrote:
>The character doesn't show in the field.  But the user did enter data into
>the field.

If there was nothing in the input field before the user tried to enter data,
and there is nothing in the input field afterward, how can one maintain
that the setting of the input field has been changed? It looks exactly
the same before and after interaction, except that the focus is gone.


>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.

[That may be similar but it is not the same: if the browser loaded a new
page, there is no way of checking if the setting of the radio button
has changed (except if the new page is in a different window or tab).
In this case, we're still on the same page, the input field is visible
and it looks identical (i.e. empty before and after interaction).]


>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.

It is not unambiguously clear from the success criterion that it applies
to this situation. Success criteria are written as functional outcomes,
and the functional outcome in this example is that there is no change
to the input field, but a change of focus.
The SC requires only that actual changes do not cause of context, not that
any "*User actions* to change the setting of any form control ..."
(i.e. user actions, regardless of whether they have the intended effect).

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: 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
> >
> >
> >

-- 
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 Tuesday, 20 February 2007 15:29:46 UTC