RE: Test Example for GL 3.2 L2 SC3

Hi Becky,

We just discussed this in the meeting last week.

The concern was that a person could type in the area code  and then ask what
the field contained.  It would say that it was empty (because it had moved
on to the next field).    If the field is announced (by the user agent/AT)
as the field is entered then this would not be a problem.  

We did not conclude the discussion -- but said that if we wanted that
condition to not be a violation- we needed to add something to the
definition like adding the following parenthetical after the word "focus"
(except if focus moves to next entry field).

Even then we talked about the need figure out how to backspace out of the
current field and into previous if the last key was a mistake. 

Thoughts?


 
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] On Behalf
Of Becky_Gibson@notesdev.ibm.com
Sent: Monday, September 19, 2005 9:51 AM
To: WCAG
Subject: Test Example for GL 3.2 L2 SC3

At the September 15, 2005 call we discussed Guideline 3.2.  I had some
concerns about the Level 2 Success Criteria #3, Changing the setting of any
input field does not automatically cause a change of context  [1].  My
concern was that web applications created for data entry  which provide
automatic cursor movement from field to field might not be allowed by this
success criteria. 

I have attached an example which I believe does not violate this success
criteria. This example is a simple form for entering US phone numbers. All
of the numbers have a 3 digit area code followed by a 3 digit prefix and 
finally a four digit number.   This form is set up so that the user does 
not have to tab from item to item. When you complete the entry of one field
and enter the first digit of the next field, the focus automatically moves
to the next field.  You can also press tab to move from field to field and
you can press shift-tab to move between the fields and can edit 
any field.   With this example the user can press tab to move from field 
to field or can just continue to type digits without pressing tab and the
cursor will automatically move to the next field.  I tested this with JAWS
6.2 and WE 5.5 Beta with IE 6 and it works properly.  Due to way that Home
Page Reader works with fields, there is no optimization of movement and the
user must use tab to move from field to field. 

I do not believe that this example violates the success criteria because the
input of data into the field has been completed before the focus is 
changed but would like to clarify that with the group.   I do not wish to 
discuss the particular merits of this example.  I know some people strongly
object to the auto movement of the cursor. I am not advocating this on a
public web site (although I have seen it used).  This type of behavior would
be designed for a specific application where the users 
would receive training in its use.   For a data entry application it could 
be helpful to eliminate extra keystrokes and thus I feel it should not be
prevented by any success criteria.



[1] http://www.w3.org/TR/WCAG20/#consistent-behavior-unpredictable-change

Becky Gibson
Web Accessibility Architect
                                                       
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com

Received on Monday, 19 September 2005 15:43:21 UTC