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 12:59:27 UTC