Re: aria-action2036 aria-keyshortcuts (IBM i18N review)

Attached is the first set of comments by the IBM i18N team. Hopefully W3C will take a document file for the links but I included the text. I did not want to lose the links. 

aria-keyshortcuts (property)§ <https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts>
(Extracted text from: https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts)

[ARIA 1.1] Indicates keyboard shortcuts that can be pressed to activate widgets, such as a button, link or menuitem. Any widget that has a default activation behavior when clicked can have a keyboard shortcut.

The value of the aria-keyshortcuts <https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts> attribute is a space-delimited list of keyboard shortcuts that can be pressed to activate the command widget. Each keyboard shortcut consists of one or more tokens delimited by the plus sign ("+") representing zero or more modifier keys and exactly one non-modifier key that must be pressed simultaneously to activate the given shortcut.

Authors MUST specify modifier keys exactly according to the DOM Level 3 KeyboardEvent key Values <http://www.w3.org/TR/DOM-Level-3-Events-key/> spec [DOM-Level-3-Events-key <https://rawgit.com/w3c/aria/action2036/aria/aria.html#bib-DOM-Level-3-Events-key>] - for example, "Alt", "Control", "Shift", "Meta", or "AltGraph". Note that Meta corresponds to the Command key on Apple computers.

The valid names for non-modifier keys are any printable character such as "A", "B", "1", "2", "$", "Plus" for a plus sign, "Space" for the spacebar, or the names of any other non-modifier key specified in the DOM Level 3 KeyboardEvent key Values <http://www.w3.org/TR/DOM-Level-3-Events-key/> spec [DOM-Level-3-Events-key <https://rawgit.com/w3c/aria/action2036/aria/aria.html#bib-DOM-Level-3-Events-key>] - for example, "Enter", "Tab", "ArrowRight", "PageDown", "Escape", or "F1".

===================================

Comment:

In the above para --…. “Space”  for the spacebar ….. is mentioned.  This needs revisiting – as a possible exception to what is in the DOM spec; or be revised to align with the DOM spec.

Under ‘White Space’ in DOM Level 3 KeyboardEvent key Values <http://www.w3.org/TR/DOM-Level-3-Events-key/>. “Space” for the spacebar is NOT included.  The Note under this item specifically states:

Note:

The space or spacebar key is encoded as ' '.

=================================================================

Authors MUST ensure modifier keys come first when they are part of a keyboard shortcut. Authors MUST ensure that required non-modifier keys come last when they are part of a keyboardshortcut. The order of the modifier keys is not otherwise significant, so "Alt+Shift+T" and "Shift+Alt+T" are equivalent, but "T+Shift+Alt" is not valid because all of the modifier keys don't come first, and "Alt" is not valid because it doesn't include at least one non-modifier key.

When specifying an alphabetic key, both the uppercase and lowercase variants are considered equivalent: "a" and "A" are the same.

Authors SHOULD avoid keys other than ASCII letters. On many keyboards even numbers and common punctuation often require modifiers. For example, in French keyboard layouts, the number keys are not available until you hold the Control key, so a keyboard shortcut defined as "Control+2" would be ambiguous as this is how you would type the number 2 on a French keyboard.

==========================================================

Comment:

In the above para: … “Authors SHOULD avoid keys other than ASCII letters” is mentioned.

There are several keyboard layouts, especially those using non-Latin alphabet, where the character set to be used in a specific language does not include any of the set of ‘ASCII letters’.  (Also the statement (elsewhere) about ‘upper case and lower case are equivalent’ will not be applicable to ‘unicameral’ scripts/languages.)

For example: http://www-01.ibm.com/software/globalization/topics/keyboards/registry_index.html <http://www-01.ibm.com/software/globalization/topics/keyboards/registry_index.html> lists several layouts used with different languages/regions.  Most of the non-Latin keyboard layouts are ‘bi-lingual’ in the sense that the keyboards have two halves one for Latin and one for non-Latin layout usage.  Switching between these two halves is usually accomplished by Alt+RightShift or Alt+LeftShift key combinations in a ‘locking shifting mode’.  Once in the specific layout – such as for the Devanagari layout (in Layout 468 - ftp://ftp.software.ibm.com/software/globalization/keyboards/KBD468.pdf <ftp://ftp.software.ibm.com/software/globalization/keyboards/KBD468.pdf>) the character set that is available need not be any of the Latin characters.

Several of the keys are assigned to generate ‘non-spacing’ marks (even in International Latin layout, this is the case), to be able to generate either combining sequences for conjuncts or accented characters needed in the language being used.

You may want to consider some guideline like “Avoid using keys that generate non-spacing marks as part of the keyboard shortcut sequence” towards simplifying Accessability usage.

Often, AltGr key is used to access the Level 3 characters in layouts needing more than Level 1 and Level 2 set of characters.  One has to enter AltGr+xxx to be able to generate those.  Perhaps another guideline could be like “Avoid using key sequences that require using AltGr in keyboard shortcuts” – to simplify Accessibility usage.

==================================================

If the key used is determined by a modifier key the author MUST specify the actual key used to generate the resulting key and not the resulting key so that the assistive technology can accurately convey what keys must be used to generate the shortcut. For example, on most U.S. English keyboards, the percent sign "%" can be input by pressing Shift+5. The correct way to specify this shortcut is "Shift+5". It is incorrect to specify "%" or "Shift+%". However, note that on some international keyboards the percent sign may be an unmodified key, in which case "%" and "Shift+%" could be correct on those keyboards.

==========================================

Comment:

“If the key used is determined by a modifier key the author MUST specify the actual key used to generate the resulting key and not the resulting key ….”

Perhaps “character that is generated by the key” should be used to disambiguate over-usage the word ‘key’ in the above sentence.  (I think the work ‘key’ is used elsewhere also, sometimes to mean the character that the keystroke generates as well as to represent the key on which it is engraved in a particular layout.  Some disambiguation is needed in the text where there is potential for confusion.)

==============================

If the key that needs to be specified is illegal in the host language or would cause a string to be terminated, authors MUST use the string escaping sequence of the host language to specify it. For example, the double-quote character can be encoded as "Shift+&#39;" in HTML.

Examples of valid keyboard shortcuts include:

"A"
"Shift+Space"
"Control+Alt+."
"Control+&quot;"
Examples of valid values for the aria-keyshortcuts attribute, that can include more than one space-delimited shortcut, include:

aria-keyshortcuts="Alt+Shift+P"
aria-keyshortcuts="/ Control+F"
aria-keyshortcuts="Meta+C Meta+Shift+C"
User agents MUST NOT change keyboard behavior in response to the aria-keyshortcuts attribute. Authors MUST handle scripted keyboard events to process aria-keyboardshortcuts <https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyboardshortcuts>. The aria-keyshortcuts attribute exposes the existence of these shortcuts so that assistive technologies can communicate this information to users.

Authors MUST ensure aria-keyshortcuts are global for active elements to which they are applied in a document. Authors MUST provide a sequence of operations to reveal the shortcut to the user by making it visible so that it may be discovered by a user of an assistive technology <https://rawgit.com/w3c/aria/action2036/aria/aria.html#dfn-assistive-technologies>. An example would be a visible and enabled menu item within a document. If the menu item exposes a keyboard shortcut it is assumed that as long as the document has focus, pressing that keyboard shortcut will activate that menu item. Authors MUST ensure that when elements having aria-keyshortcuts are marked disabled those keyboard shortcuts are unavailable. Authors MAY choose to make as shortcut unavailable to the user when it is invisible or hidden.

 

Generic Comment:

You will encounter several situations where ‘soft layouts’ for key entries are in use, especially on mobile devices.  Not sure how the above guidelines could be made applicable for ‘keyboard shortcuts’.  One may need to mandate appearance of at least one of the keys such as Alt, AltGr, Shift or in the case of a soft keyboard then some mechanism to signal that a shortcut is about to be input, to be able to generate a keyboard shortcut!

=====================================================================

 



> On Mar 15, 2016, at 9:54 AM, Joseph Scheuhammer <clown@alum.mit.edu> wrote:
> 
> On 2016-03-15 10:23 AM, Rich Schwerdtfeger wrote:
>>> Keyboard shortcuts become unavailable all the time. For example, the "Send" shortcut in a mail application is only available when there is a draft message to send and only when it's the front-most window. Having contextual keyboard shortcuts is a common pattern that does not need to be addressed in the ARIA spec.
>>> 
>> Previously, this was not an issue because when the keyboardshortcut was hidden it was not active. Now Jason has asked for the keyboard shortcut to be applicable anywhere. He wants to mandate that these be available globally. If we are to relax that restriction then I agree that we don’t need this statement.
>> 
> 
> The case that James is referring to (I think) is where a UI widget is disabled, but not hidden.  Continuing with his email example, there may be a tool bar button named "Send", that is enabled when the user is drafting a message, and disabled when the user is not. Since the button is disabled, the keyboard shortcut is non-functional.  Nonetheless, the "Send" tool bar button is visible at all times.
> 
> This points to some interaction between aria-disabled and aria-keyshorcuts, but it's fairly straight forward, since this sort of interaction is common on the desktop.
> 
> -- 
> ;;;;joseph.
> 
> 'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>                 - C. Carter -
>