RE: Loretta's analysis of UAAG Guideline 9

Responses preceded by "js:"



(snip...)
I reviewed the checkpoints of UAAG 9  to see whether all the issues are 
addressed. The P1 checkpoints for UAAG 9 are:


9.1 Provide content focus

     * Provide at least one content focus for each viewport (including 
frames) where enabled elements are part of the rendered content.
     * Allow the user to make the content focus of each viewport the 
current focus.

9.1 seems to be covered by WCAG 2.1.
Js: agree



9.2 Provide user interface focus

     * Provide a user interface focus.

9.2 seems to be a user agent responsibility
Js: agree




9.3 Move content focus

     * Allow the user to move the content focus to any enabled element
in 
the viewport.
     This seems to be covered by WCAG 2.1, but it may be possible to
invoke 
functionality via the keyboard without actually moving focus to an
enabled 
element, for instance, by providing keyboard shortcuts. 

Js: I think I need an example here. Current user agents implement
accesskey in different ways-- in some cases accesskey fires the element,
in others it just moves the focus. But I'm thinking only about accesskey
right now, not about scripting, Flash, etc., where the situation may be
quite different.



At level 2, WCAG 
3.2 requires that all user interface components should be able to
receive 
focus without causing activation.

     Allow configuration so that the content focus of a viewport only 
changes on explicit user request.

     Nothing in WCAG seems to cover this requirement. It requires, for 
instance, that it be possible to configure the user agent so that
scripts 
can't move the focus as a side effect of something else. If we consider
a 
change in focus to be an extreme change of context, if might be covered
by 
GL 3.2, but I think this is not what was intended by extreme change of
context.
Js: This sounds to me like a user agent issue. What can an author do to
affect whether or not the UA can be *configured* to prevent automatic
changes of focus?
     * If the author has not specified a navigation order, allow at
least 
forward sequential navigation, in document order, to each element in the

set established by provision one of this checkpoint.
     This seems to be covered by WCAG 2.4, by the requirements at level
3 
related to sequences. We might need to  promote them to level 1 to cover

this requirement.
Js: This seems to lend further support to Michael's proposal to move
(<current>2.4 L3 SC1 and SC2</current> to L1.  (See Yvette's issue
summary for 2.4; I think it's issue 829 (there was also a
counter-suggestion in another bug to delete the SC altogether, so this
analysis seems to argue against that idea.)

9.4 Restore viewport state history

     * For user agents that implement a viewport history mechanism, for 
each state in a viewport's browsing history, maintain information about
the 
point of regard, content focus, and selection.
     * When the user returns to any state in the viewport history (e.g.,

via the "back button"), restore the saved values for the point of
regard, 
content focus, and selection.

9.4 seems to be a user agent responsibility.
Js: agree



Recommendation:

1. Add the following success criterion to GL 3.2, level 1:

Any change of content focus is implemented in a way that can be 
programmatically identified.
Js: What would be an example of a change of focus that *can't* be
programmatically identified?


2. Promote the following success criteria of GL 2.4 to level 1:
     * When content is arranged in a sequence that affects its meaning, 
that sequence can be determined programmatically.
     * When a page or other delivery unit is navigated sequentially, 
elements receive focus in an order that follows relationships and
sequences 
in the content
Js: agree

Received on Saturday, 23 April 2005 19:56:06 UTC