[i18n-activity] `aria-keyshortcuts` needs attention? (#1829)

aphillips has just created a new issue for https://github.com/w3c/i18n-activity:

== `aria-keyshortcuts` needs attention? ==
## Proposed comment

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

> 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](https://www.w3.org/TR/uievents-key/) spec [[uievents-key](https://www.w3.org/TR/wai-aria-1.3/#bib-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](https://www.w3.org/TR/uievents-key/) spec [[uievents-key](https://www.w3.org/TR/wai-aria-1.3/#bib-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.

The above section about keyshortcuts makes me nervous.

- "Printable character" is incompletely specified.
- The text about uppercase and lowercase should specify Unicode equivalence.
- The various discussions about keyboards and "language" seem to imply that the language of a page has some effect on the keyboard being used. Some of the discussion about how to access e.g. the `%` key or the number `2` key seems confusing.


## Instructions: 

This follows the process at https://w3c.github.io/i18n-activity/guidelines/review-instructions.html

1. Create the review comment you want to propose by replacing the prompts above these instructions, but **LEAVE ALL THE INSTRUCTIONS INTACT** 

2. **Add one or more t:... labels. These should use ids from specdev establish a link to that doc.**

2. Set a label to identify the spec: this starts with s: followed by the spec's short name. If you are unable to do that, ask a W3C staff contact to help.

3. Ask the i18n WG to review your comment.

4. After discussion with the i18n WG, raise an issue in the repository of the WG that owns the spec. Use the text above these instructions as the starting point for that comment, but add any suggestions that arose from the i18n WG. In the other WG's repo, add an 'i18n-needs-resolution' label to the new issue. If you think any of the participants in layout requirements task force groups would be interested in following the discussion, add also the appropriate i18n-\*lreq label(s).

5. Delete the text below that says 'url_for_the_issue_raised', then add in its place the URL for the issue you raised in the other WG's repository. Do NOT remove the initial '§ '. Do NOT use \[...](...) notation – you need to delete the placeholder, then paste the URL.

6. Remove the 'pending' label, and add a 'needs-resolution' tag to this tracker issue. 

7. If you added an \*lreq label, add the label 'spec-type-issue', add the corresponding language label, and a label to indicate the relevant typographic feature(s), eg. 'i:line_breaking'. The latter represent categories related to the Language Enablement Index, and all start with i:.

8. Edit this issue to **REMOVE ALL THE INSTRUCTIONS & THE PROPOSED COMMENT**, ie. the line below that is '---' and all the text before it to the very start of the issue.

---


**This is a tracker issue.** Only discuss things here if they are i18n WG internal meta-discussions about the issue. **Contribute to the actual discussion at the following link:**


§ url_for_the_issue_raised


Please view or discuss this issue at https://github.com/w3c/i18n-activity/issues/1829 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 29 February 2024 20:02:00 UTC