[action] Reasons for not moving SC 3.2.2 up to level 1

Alex and I took an action item regarding success criterion 3.2.2: 
Alex and Becky provide reasons why moving 3.2.2 to level 1 would cause 
problems for web application development. Due 01/12/06. 

We both have concerns about moving this to level 1 with respect to 
blocking further technologies or that someone will interpret change of 
context more strictly.  Here are some application examples which would not 
be allowed at level 1 if this success criterion was moved: 
  
-automatic movement of focus to the next entry field when entering data 
into a form.  For example, automatically moving the cursor from the area 
code field to the local code field when entering a US phone number.  See 
the example that I posted to the list in September [1]. 

-using a drop down list to implement a list of links.  For a trained user, 
a drop down list containing a list of links with an onchange event to 
navigate to the selected link could be a faster way to navigate a 
repetitive process. 

-data entry applications. During the process of data entry entering a 
particular code within an input field might automatically submit the form 
and load the next page.  I could do this with JavaScript by monitoring 
each character entered into a field. If a particular set of characters is 
encountered, the form could be automatically submitted and the next screen 
automatically loaded. This would prevent the data entry operator from 
having the recognize the particular character sequence and manually submit 
the page. 

-gaming applications - I envision a game implemented in flash (although 
that might be tough to make accessible).  I  can see a particular entry 
taking the gamer into the next room (which would be a new page). Or, a 
change in a radio button might do the same thing in a non-flash 
implementation. 

-A radio button that changes the editor type in an application.  An email 
message form contains a radio button that allows the user to select plain 
text or rich text editing.  Changing the radio button warns (via an alert) 
the user that any unsaved data will be lost and then reloads the page with 
the selected editor type.  This could probably be done via AJAX and not 
require an entire page reload but there are still some open issues with 
that strategy as well. 

We both realize that there can be accessibility issues with changing 
context as the result of a change to an input field. These are captured in 
the How to Meet document for 3.2.2.  But, we still have concerns with 
moving this up to level 1 for the reasons cited above. 

[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JulSep/0834.html 

Becky and Alex

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, 9 January 2006 19:19:52 UTC