`aria-keyshortcuts` needs attention?

[aphillips]

aria-keyshortcuts property https://www.w3.org/TR/wai-aria-1.3/#aria-keyshortcuts

The internationalization (I18N) working group reviewed 1.3 as part of horizontal review. In the course of doing this review, we found the below quoted text about the aria-shortcuts property. We aren't sure how shortcuts are used with assistive technology, but the description given provokes a number of concerns for us. We think the best course of action here would be to discuss key shortcuts in more detail.

Specific concerns:

• The relationship of key shortcuts to physical keyboards seems unclear. There might be an unstated assumption that the physical keyboard matches the language of the content. Generally, when selecting shortcut keys, one is more interested in the key typed value rather than the key combination used to produce it. For example, one might want the letter "A" to be a hot key, regardless of what key is printed with the letter "A" or what modifiers are needed to produce it. Some modifiers, however, such as Control and Alt/AltGr have additional "short-cut-like" meaning. Understanding the usage here would let us comment more productively.
• The term "printable character" is incompletely specified.
• The interaction of shortcuts with complex keyboards (such as Chinese or Japanese "input method editors" aka "IMEs") is not mentioned
• The discussion of upper and lowercase should specify Unicode equivalence and take into account language-specific mappings. E.g. Turkic language keyboards interact with the letter "i" in different ways than e.g. English ones.
• The French keyboard uses Shift, not Control, to produce numbers.

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 UI Events KeyboardEvent key Values spec [uievents-key] - for example, "Enter", "Tab", "ArrowRight", "PageDown", "Escape", or "F1". The use of "Space" for the spacebar is an exception to the UI Events KeyboardEvent key Values spec [uievents-key] as the space or spacebar key is encoded as ' ' and would be treated as a whitespace character.

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 shortcut. 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.

When implementing keyboard shortcuts authors should consider the keyboards they intend to support to avoid unintended results. Keyboard designs vary significantly based on the device used and the languages supported. For example, many modifier keys are used in conjunction with other keys to create common punctuation symbols, create number characters, swap keyboard sides on bilingual keyboards to switch languages, and perform a number of other functions.

For many supported keyboards, authors can prevent conflicts by avoiding keys other than ASCII letters, as number characters and common punctuation often require modifiers. Here, the keyboard shortcut entered does not equate to the key generated. For example, in French keyboard layouts, the number characters are not available until you press the Control key, so a keyboard shortcut defined as "Control+2" would be ambiguous as this is how one would type the "2" character on a French keyboard.

If the character used is determined by a modifier key, the author MUST specify the actual key used to generate the character, that is generated by the key, and not the resulting character. This convention enables the assistive technology to 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 might be an unmodified key, in which case "%" and "Shift+%" could be correct on those keyboards.

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 single-quote character can be encoded as "'" in HTML.

[spectranaut]

Discussed briefly at the end of our meeting today: https://www.w3.org/2024/03/14-aria-minutes.html#t02

[aphillips]

Would it be convenient for us to do a joint call (such as joining your next call) to discuss? On the one hand, the purpose of this seems clear. On the other hand, we found a bunch of questions relating to the keyboard and I18N jargon. I think we could make quick work of this with a higher-bandwidth conversation.

[cookiecrook]

@aphillips wrote:

Would it be convenient for us to do a joint call…

I think your point is clear enough. I raised some similar concerns (inc the french keyboard numbers being on the shift plane) when the attribute was proposed. I dropped the objection when @aleventhal agreed that the web app should localize this (as Google Docs and others do), not the engine.

But I agree with all the reasons you gave for the prose needing to change.

[cookiecrook]

@aphillips If you're open to writing (or co-writing a PR) that might be the most efficient way to proceed.

@aphillips If you think a small group meeting is necessary, I'd like @aleventhal to attend or assign a member of his team to attend, since Google Docs was the primary driver for this feature. I'd like to attend too (optionally), and the I think the @w3c/aria-editors would attend too.

[spectranaut]

Briefly discussed in the working group meeting today, with the conclusion being @cookiecrook comment above: https://www.w3.org/2024/03/21-aria-minutes.html#t06

[daniel-montalvo]

Hi @aphillips

Have you had a chance to review [James' comment](https://github.com/w3c/aria/issues/2141#issuecomment-2013148718 above?

Thanks much.

[aphillips]

@daniel-montalvo @cookiecrook Thanks for the response.

I'm open to writing or co-writing a PR. I usually try to make concrete text proposals in comments (rather than just saying "hey, this looks wrong..."). However, in this case, I'd need to understand some things before I could propose text, hence my desire to chat about it before diving in. We don't have to do a super-formal call--we can just jump on Slack or Zoom or such. We're both in Norcal, so it should be easy enough to sync schedules.

[cookiecrook]

I'm on the W3C Slack, and another contact is firstname at GH username with the most common TLD. (This type of obfuscation won't deter the AI bots for long, will it?)