W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2001

Re: 19 March 2001 UAAG 1.0 Guidelines and Techniques available

From: gregory j. rosmaita <oedipus@hicom.net>
Date: Thu, 22 Mar 2001 16:33:25 -0500
Message-ID: <000301c0b317$baac2f00$7eb6f5d0@igor>
To: <w3c-wai-ua@w3.org>
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

=-=-=
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"?

=-=-=
GJR 3 [PRIORITY LEVEL]: why are there no P1 checkpoints in GL5?
why are 5.3 and 5.4 only P2? 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

quote
   5.3 Allow configuration so that viewports only open on explicit user
       request. In this configuration, instead of opening a viewport
       automatically, alert the user and allow the user to open it on
       demand (e.g., by following a link or confirming a prompt).
       Allow the user to close viewports. If a viewport (e.g., a frame
       set) contains other viewports, these requirements only apply to
       the outermost container viewport. [Priority 2]
          Note: User creation of a new viewport (e.g., empty or with a
          new resource loaded) through the user agent's user interface
          constitutes an explicit user request. See also checkpoint 5.1
          (for control over changes of focus when a viewport opens) and
          checkpoint 6.5 (for programmatic alert of changes to the user
          interface).

   5.4 Allow configuration to prompt the user to confirm (or cancel) any
       form submission that is not caused by an explicit user request
       to activate a form submit control. [Priority 2]
          Note: For example, do not submit a form automatically when a
          menu option is selected, when all fields of a form have been
          filled out, or when a mouseover event occurs. The user agent
          may satisfy this checkpoint by prompting the user to confirm
          all form submissions.
unquote

=-=-=
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]

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;

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?  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; 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

--- end comments
Received on Thursday, 22 March 2001 16:31:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:38 GMT