- From: gregory j. rosmaita <oedipus@hicom.net>
- Date: Thu, 22 Mar 2001 16:33:25 -0500
- 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 UTC