Proposals for 3.2.2

Hi all,

The following proposals are meant to address the category 1 issues that 
remain for guideline 3.2, questions raised while drafting techniques 
related to guideline 3.2, and an action item that David and I had from a 
few weeks ago related to documenting reasons for moving SC 3.2.2 up to 
level 1.

<current>

3.2.2 Changing the setting of any input field does not automatically
cause a change of context.

</current>

4 revisions proposed:

1.) Change "input field" to "form control or field" so that it is clear
that check boxes, radio buttons etc are covered.

2.) Add the phrase, "unless the delivery unit contains instructions that 
describe the behavior before the control" to the end of success 
criterion 3.2.2.

<proposed>

Changing the setting of any form control or field does not automatically 
cause a change of context unless the delivery unit contains instructions 
that describe the behavior before the control.

</proposed>

Note: Sufficient techniques would need to provide examples of where the 
instructions should appear in various circumstances. (either directly 
preceding the form control itself or, if multiple controls of this 
nature are used, preceding the first item that causes the change of 
context.)

Rationale:

This would allow for behaviors where focus change explained in advance 
and where it is helpful and not disorienting for those who cannot see 
(if they are aware that this is how the component was intended to 
operate.)  For example, clicking on radio buttons could cause the rest 
of the page to change from one document to another.

3.) Revise the definition of change of context to allow for changes of
focus that do not interfere with expected behavior of content. See 
Becky's example at [1].

<current>

changes of context

      A change of user agent, viewport, or focus; or complete change of
content that changes the meaning of the delivery unit.

      Note: A change of content is not always a change of context. Small
changes in content, such as an expanding outline or dynamic menu, do not
change the context.

</current>

<proposed>

changes of context

changes of:
     - user agent,
     - viewport,
     - focus (except next field in tab order),
     - content (that change the meaning of the delivery unit).

      Note: A change of content is not always a change of context. Small
changes in content, such as an expanding outline or dynamic menu, do not
change the context.

</proposed>

4.) Move 3.2.2 to level 1.

Rationale:

Isssue 1747 [2] asks, Shouldn't this [3.2.2] be level 1? This is very 
important to screen reader users. Users can become very confused if the 
context changes by the mere action of changing the setting of an input 
field (JavaScript enabled select boxes that redirect on the first 
selection is a serious issue for keyboard users).

This was discussed at the 22 December 2005 telecon: [3]

Leave issue 1747 open - can not reach consensus on this call. Comments 
included some people can not live with it at level 1 - too restrictive. 
what would it prevent? what should it allow? concern about defn. of 
change of context - could it be misinterpreted? word "complete" is 
important and "changing the meaning of the d.u." clarification needed 
about "dynamic outline" - what does this entail/cover?.

Becky and Alex put together a list of reasons  for not moving SC 3.2.2 
up to level 1 [4] a few weeks ago.

I think the proposed changes listed above address these concerns and 
that this SC can be moved to level 1 as the reviewer proposes.

Comments invited,

-Ben

[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JulSep/0834.html
[2] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1747
[3] http://www.w3.org/2005/12/22-wai-wcag-minutes.html
[4] http://lists.w3.org/Archives/Public/w3c-wai-gl/2006JanMar/0056.html

-- 
Ben Caldwell | <caldwell@trace.wisc.edu>
Trace Research and Development Center <http://trace.wisc.edu>