Re: 19 March 2001 UAAG 1.0 Guidelines and Techniques available

Gregory,

Thanks for comments. Mine preceded by "IJ:" below.

"gregory j. rosmaita" wrote:
> 
> GJR COMMENTS ON 19 MARCH 2001 UAAG DRAFT
> 
> GJR 1 [EDITORIAL]: isn't the "and" before "pointing device" in
> checkpoints 1.1 and 9.3 superfluous, although i suppose that, in
> light of the 22 March 2001 teleconference, this point may now be
> superfluous...
> 
> quote
>    1.1 Ensure that the user can operate the user agent fully through
>        keyboard input alone, and pointing device input alone, and
>        voice input alone. [Priority 1]
> unquote
> quote
>    9.3 For the element with content focus, allow the user to activate
>        any explicitly associated input device event handlers through
>        keyboard input alone, and pointing device input alone, and
>        voice input alone. [Priority 1]
> unquote

IJ: The 'and' was added for emphasis. But you're right, it's
now superfluous.
 
> =-=-=
> GJR 2 [EDITORIAL]: in the unordered list in the introduction to GL2,
> the second list item is not as clear as it could be
> 
>      * Structure is preferred (both the author's specified preferences
>        and the user's structured access), but unstructured access may be
>        necessary for access.
> 
> should it not state "necessary for access to all content"?

IJ: Agreed.
 
> =-=-=
> GJR 3 [PRIORITY LEVEL]: why are there no P1 checkpoints in GL5?
> why are 5.3 and 5.4 only P2? 

IJ: That is "pure coincidence". In the reorganization that
led to the creation of Guideline 5, checkpoints whose priorities
had already been determined by the Working Group happened to fall
this way.

> i am still unconvinced that these are P2
> issues--5.4, at the very least, should be a P1, as there is no guaruntee
> that one will be able to undo the results of a form submission, 
> and i am still of the opinion that 5.3 is a P1, as well

IJ: Gregory, at the 2 May 2000 teleconference [1], which you
attended, we resolved to leave this checkpoint 5.4 (then 9.2) a
Priority 2 checkpoint. I realize that you have for a long
time felt this should be a P1 checkpoint (refer to your earlier
comments on this topic [2]). This is a case where I don't think
the Working Group should reopen this issue and you should voice
an objection if you have one. Please make an effort to review
past rationale for this decision and present new evidence why
the priority should be raised.

[1] http://www.w3.org/WAI/UA/2000/05/wai-ua-telecon-20000502
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0235

As for checkpoint 5.3, issue #175 involved the priority of
this checkpoint (increasing it to P1). At the 12 January 2000
teleconference, which you attended, we clarified that notification
was crucial for users of assistive technologies. Our P1 checkpoint
6.5 (in the 19 March draft) requires notification for changes
to the user interface. Therefore, notification of new viewports
is covered at a P1 level. We resolved to leave what is now 5.3
a Priority 2 checkpoint. I request here as well that you present
new evidence as to why this checkpoint must be a P1.

[3] http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#175
[4] http://www.w3.org/WAI/UA/2000/01/wai-ua-telecon-20000112

I note for the record that two of your previous objections have
been rendered moot by the progress of the document (which I
consider a good thing. These are [4] (CSS2 DOM raised to P2)
and [5]  (minreqs related to speech playback rate).

[4] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0110
[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0111

[5.3 and 5.4 deleted]

> =-=-=
> GJR 4 [PRIORITY LEVEL]: in the 9 March 2001 draft, the checkpoint then
> numbered 9.3 read:
> 
> quote
>        Allow configuration so that moving the content focus to an enabled
>        element does not automatically activate any explicitly associated
>        input device event handlers. [Priority 1]
>           Note: In this configuration, user agents should carry out any
>           stylistic changes (e.g., highlighting) that may occur when
>           there is a change in content focus.
> unquote
> 
> but in the 19 March 2001 UAAG draft, the priority level of the checkpoint,
> now numbered 9.6, has been REDUCED to Priority 2
> 
>    9.6 Allow configuration so that moving the content focus to an enabled
>        element does not automatically activate any explicitly
>        associated input device event handlers. [Priority 2]

IJ: Yes. For the record, we resolved to change it at the 15 March 2001
teleconference:
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0427

> i would like the UAWG to reconsider the following reasons NOT to
> REDUCE the priority level of this checkpoint:
> 
> 1. reducing the priority of a checkpoint is a substantive change to
> the document;

IJ: But it was a new checkpoint (less than two weeks old).
 
> 2. access to all content is the over-riding concern; if something is
> automatically triggered when an enabled interactive element receives
> focus, i've lost access to content; if the content of the page is
> changed by what i, as a user, perceive as simply navigating the page,
> how am i to know what i am missing?

IJ: We have a P1 requirement that the UA alert through APIs
changes to content.

>  how can i have foreknowledge of
> the implications of navigating the enabled interactive elements
> unless the UA provides me with a configuration option that allows me
> to suppress automatic changes so that i can either manually query
> the element to ascertain its properties and any associated event
> handlers, or so that my AT can automatically convey to me (e.g.
> through an audible signal) that there is/are event handlers
> associated with the enabled interactive element to which i have
> navigated;
> 
> 3. the ability to pause OnFocus events provides a mechanism which is
> analagous to a blind pedestrian stopping at an intersection in order
> to ascertain, whether or not it is safe to cross; as a blind
> individual, i may not be able to perceive all potential obstacles or
> dangers to my person, but pausing at an intersection does, at least,
> provide me with the opportunity to gather information before starting
> across the street; 

IJ: The argument made at the previous teleconference was that
we were not convinced that too many dangers were lurking out there
in practice. Charles has an action item to hunt down real-world
cases of destructive on-focus handlers.

>allowing automatic content changes OnFocus,
> therefore, is akin to allowing a large cow-catcher to be syncronized
> with the traffic signal, so that, when the light turns green, anyone
> standing on the corner of the intersection is suddenly, abruptly,
> disorientingly -- and potentially dangerously -- thrust into an
> active roadway;
> 
> 4. if a functionality exists, it will be used; there are numerous
> examples of strange, non-sensical scripts, as well as those which
> depend upon the ability to perceive rendered content in a multi-modal
> manner (the example i gave during the telecon, where on a form used
> to spec out a new system, an OnFocus event is attached to a form
> control, which, in turn, causes a "Learn More" link to point to
> information pertaining to the item represented by the form control
> with focus; the presumption is that when focus is established on a
> form element, the user will then use a pointing device to activate
> the "Learn More" link, but if one cannot use a pointing device (or
> doesn't have access to one), then one must move focus to the "Learn
> More" hyperlink in order to follow the link, but doing so removes
> the referential relationship between the form element and the "Learn
> More" link, leaving the pointerless user without the ability to
> "Learn More" about the item selected on the form;
> 
> 5. preserving stylistic changes (e.g., highlighting) that may occur
> when there is a change in content focus will enable some users to
> re-orient themselves (e.g., where focus has been established);
> 
> =-=-=
> GJR 5 [toggle video/images on and off]: i fully support the following
> proposed checkpoint:
> 
> quote
>  3.x If activation of a placeholder required by checkpoints
>  3.2 and 3.7 causes the placeholder to be replaced in context
>  by the original author-supplied content, allow the user to
>  undo the action (by turning the visual content off and the
>  placeholder on again).
>       Note: If the user agent satisfies the placeholder
>       activation requirement by rendering the author-supplied
>       content in a new viewport, the user can close the new
>       viewport per checkpoint 5.3
> unquote
> 
> this is at least a P2 issue, although Denis' point about the man who
> could play five card stud, but if one handed him a sixth card, everything
> ceased making sense, would indicate that this is a very important--perhaps,
> essential functionality

IJ: Noted. This will be on the agenda for next week.

 - Ian


-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Thursday, 22 March 2001 17:48:35 UTC