Rewrite #63 splitting 4.1.5 into A for content shortcuts and AA for UI shortcuts

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