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

Hi Christophe,

I'm not sure I understand.

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?


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://www.bentoweb.org/ts/XHTML1_TestSuite2/testfiles/sc3.2.5
> _l3_011.html
> (change of focus). Note that these test cases are currently
> mapped to SC 3.2.5 instead of 3.2.2.
>
> Best regards,
>
> Christophe
>
>
> --
> 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 04:21:29 UTC