- From: Greg Lowney <gcl-0039@access-research.org>
- Date: Wed, 20 May 2009 23:40:56 -0800
- To: w3c-wai-ua@w3.org
Action-XXX Rewrite #63 splitting 4.1.5 into A for content shortcuts and AA for UI shortcuts _*1. Original Text:*_ 4.1.5 Discovery of Keyboard Commands: User has the option to have any *recognized* direct keyboard commands displayed with their associated controls. (Level A) _***2. Proposed Revised Text:*_ 2.a 4.1.5 (Proposed Revision) Present Direct Commands in Rendered Content: The user has the option to have any recognized direct commands (e.g. accesskey) in rendered content be presented with their associated elements (e.g. "[Ctrl+t]" displayed after a link whose accesskey value is "t", or an audio browser reading the value or label of a form control followed by "accesskey control plus t"). (Level A) 2.b 4.1.x (Proposed Addition) Present Direct Commands in User Interface: The user has the option to have any direct commands (e.g. keyboard shortcuts) in the user agent user interface be presented with their associated user interface controls (e.g. "Ctrl+S" displayed on the "Save" menu item and toolbar button). (Level AA) _*3. Explanatory Notes:*_ 3.1 4.1.5 Display Direct Commands in Rendered Content is Level A because: (a) many users benefit from direct commands; (b) many Web resources do not document their direct commands, or document them in ways that are not convenient; (c) direct commands change with every Web resource the user visits, so even if the Web resource documents them it is unrealistic to expect the user to memorize them; (d) many users need to reduce cognitive load of memorization. 3.2 In contrast to 4.1.5, 4.1.x Display Direct Commands in User Interface is only currently Level AA because: (a) UAAG20 already requires the user agent to document its keyboard commands, including in a single, convenient location; (b) the direct commands do not change while the user is using the product; (c) while most of today's user agents display most of their direct commands in their user interface, none known display *all* of their direct commands (e.g. for the address bar, or for add-in toolbar buttons). It is expected that this success criterion will be promoted to Level A in the future once at least two user agents fully comply. 3.3 I changed the titles from "Discovery" to "Display" to more closely match the intention and the wording of the success criteria, but then changed it to "Present" to handle audio-output, per Issue below. 3.4 I changed "presented" to "be presented" to try to make the sentence easier to read; without it, it took real effort to figure out if "rendered content presented" meant "have…rendered content /be /presented…" or "have…rendered content /that is /presented…". 3.5 4.1.5 uses the term "elements" which includes both links and form controls in rendered content, while 4.1.x uses the term "user interface controls"; both are defined in the glossary. 3.6 I changed it from "direct keyboard commands" to the more general "direct commands" so that speech input will be included. Do others agree? 3.7 My proposed wording of 4.1.5 uses the term "direct commands" even though the currently proposed definition applies ONLY to user agent user interface controls and functions, not to shortcuts for elements in rendered content, and ONLY to keyboard input (and keyboard emulators) rather than to user agents supporting speech-input commands natively. See Issues below and my separate comment section on this topic. _*4. Open Issues:* _ 4.1 Can we remove inline examples of direct commands: Should we cut "(e.g. acecsskeys)" and "(e.g. keyboard shortcuts)" out of the new wording of 4.1.5 and 4.1.x? 4.2. Define "Associated user interface controls" and "Associated elements": The terms "associated user interface controls" and "Associated elements" are not currently in the glossary, but maybe they should be (see Comment below). 4.4. Define "User has the option": The term "user has the option" is used throughout the document and sometimes linked to a glossary entry that does not yet exist. 4.4. "Display" vs. "Present" to include non-visual output: The term "display" is already used but not defined. Does this adequately cover the case of user agents outputting text as audibly rather than visually (e.g. a browser reading a link as "thread accesskey alt plus t")? Is there another, more inclusive term? (We can't use "rendered" as that applies only to author-supplied content.) "Display" is only used as a non-sense-specific verb in 4.1.5, 4.1.8; it is used and qualified as visual-only in 4.9.3 and in the definitions of "repair content" and "text content". "Present" is used as a verb only in the title of Principle 4. 4.4. "*recognized*": Existing versions of 4.1.5 and 4.1.11 emphasize the word "recognized" by putting asterisks around it. This is not done elsewhere in the document. Was that meant to indicate that the word should be bold in the final version? Because they should already links to glossary entries, additional emphasis is not needed, so I've removed it from the new draft of 4.1.5, and suggest doing the same for 4.1.11. 4.6. Do tooltips count as presenting with a control: Does providing tooltips qualify as displaying the direct commands "with" their associated controls? In most cases tooltips are only displayed on request, rather than automatically. In some cases they may not be available through speech or keyboard input. 4.7. Clarify "Associated controls": 4.1.5 requires displaying (or presenting) keyboard command with "with their associated" controls, but I think this needs clarification either in the text or in supporting materials. For example, if a keyboard command carries out the same function as a control (e.g. Ctrl+O displays the Open dialog, as does an Open button), does that automatically make the shortcut "associated with" the control? Or may the shortcut and the control simply both be associated with the same application function? Is it reasonable to assume an application will always know when about such congruencies, even if the user can customize keyboard shortcuts and UI controls? It sounds like it might be quite a bit of work in some UI architectures. But, in the end, I think it really is the goal, and since it's only Level AA we should be OK. (Note that we can limit the requirement to "recognized" direct commands when dealing with rendered content, but that term cannot be used when discussing user agent user interface controls.) 4.8. Problems with proposed definition of "Direct Command": I see two problems with the proposed glossary entry for "Direct Command" (used in 4.1.1, 4.1.3, 4.1.5 and 4.1.x). First, the proposed definition is limited to "UI controls", and thus don't apply to controls in rendered content. We don't have a current or proposed term for the latter (e.g. accesskeys). I propose changing the (proposed) definition of "direct command" to apply to both contexts, and when only one is meant it can be qualified by saying "direct commands in rendered content" or "direct commands in user agent user interface". Second, the definition does not explicitly limit it to keyboard input, but none of the text or examples address other input modalities. (Can anyone provide specific example of using a W3C standard to associate a speech command with a form control? Would that use the EMMA standard or something else?) See separate comment section on these issues, but in short I suggest we change the definition to include both. Thanks, Greg
Received on Thursday, 21 May 2009 06:44:59 UTC