Re: aria-action2036 aria-keyshortcuts

Here is fine Charles. 

Rich Schwerdtfeger




> On Mar 9, 2016, at 6:02 PM, Chaals McCathie Nevile <chaals@yandex-team.ru> wrote:
> 
> On Thu, 10 Mar 2016 00:22:18 +0100, Richard Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com>> wrote:
> 
>> Thank you to you and the Apple i18n team for the feedback. I made extensive to the the branch to reflect the feedback:
>> 
>> https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts <https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts>
>> 
>> I did not, yet, take into account comments from the list regarding applying it to other roles yet as it is very hard to follow the spec. (as to what supports what) until Shane makes changes to respec.
>> 
>> I am sure there were be additional comments as i introduced more normative text for authors.
> 
> Yep. Should I reply in response to this thread, on a separate email thread here, in the comments list, or somewhere else?
> 
> cheers
> 
>> Rich
>> 
>> 
>>> On Mar 1, 2016, at 4:08 AM, James Craig <jcraig@apple.com <mailto:jcraig@apple.com>> wrote:
>>> 
>>>> On Feb 28, 2016, at 8:42 AM, Richard Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com> <mailto:richschwer@gmail.com <mailto:richschwer@gmail.com>>> wrote:
>>>> 
>>>> Here is a draft of the spec. with the changes:
>>>> https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts <https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts> <https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts <https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts>>
>>> 
>>> 1. Changelog reference to aria-kbdshortcuts is a broken link.
>>> 
>>> 2. Examples list "Ctrl" (KeyboardEvent spec value is "Control".)
>>> 
>>> 3. [From the Apple i18n team] It's recommended to avoid anything other than ASCII letters. 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 (This is just the way you type "2") or impossible to input (Control modifier may not be passed to the web application).
>>> 
>>> As such this requirement may need to be reconsidered.
>>> 
>>>> 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/ <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 <https://rawgit.com/w3c/aria/action2036/aria/aria.html#bib-DOM-Level-3-Events-key>>] - for example, "Enter", "Tab", "ArrowRight", "PageDown", "Escape", or "F1".
>>> 
>>> 
>>> Next example:
>>> 
>>>> When specifying an alphabetic key, both the uppercase and lowercase variants are considered equivalent: "a" and "A" are the same, as are "ü" and "Ü".
>>> 
>>> In light of all the i18n warnings about this property, avoid the umlauts and accented characters altogether, as it shines a light on the problems. Worse, it makes it seem like the WG is unaware that the problems exists, making the group appear naïve or foolish.
>>> 
>>> It's impossible to enter ü or Ü on most keyboards without a modifier (Ü is actually a set of two key shortcuts on Mac OS X "Option+u" for the umlaut, immediately followed by "Shift+u") so this requirement conflicts with the statement that immediately follows:
>>> 
>>>> When specifying a key on the keyboard that changes when you hold down a modifier key other than an alphabetic key, authors must specify the unmodified key name.
>>> 
>>> This requirement is flanked on both sides by examples that conflict with it. (See ü above and &quot; below.)
>>> 
>>> The first clause is also hard to understand. I think "other than an alphabetic key" may be a misplaced modifier in this sentence, or if it's not, the sentence should be rewritten to avoid the ambiguity.
>>> 
>>>> For example, on most U.S. English keyboards, the percent sign "%" can be printed 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+%" would be correct on those keyboards.
>>> 
>>> 
>>> Replace: s/printed/input/
>>> Replace: s/would/could/
>>> 
>>>> 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 "&quot;" in HTML.
>>> 
>>> 
>>> This example also conflicts the previous requirement, because on a US English layout, the double quotation mark character should be specified as a shifted single quotation mark: "Shift+&#39;"
>>> 
>>>> Adding the aria-keyshortcuts attribute to an element does not change the behavior of the user agent by mapping the specified keyboard shortcuts to the triggering of the element's activation function. It is still up to the application to implement support for the keyboard shortcuts.
>>> 
>>> 
>>> These are non-requirements that should be rewritten as two RFC-2119 statements: ~"User Agents MUST NOT change keyboard behavior…" and ~"Authors MUST handle scripted keyboard events…"
>>> 
>>>> The aria-keyshortcuts attribute exposes the fact that these shortcuts exist so that assistive technologies can communicate this information to users.
>>> 
>>> 
>>> It is not a "fact" that the shortcuts exist. They very well may not exist. Even rephrased, I don't think this sentence adds value. Consider dropping it.
>>> 
>>>> Keyboard shortcuts are assumed to be global. If a button is present in a document and it is visible and enabled, and it exposes a keyboard shortcut, it is assumed that as long as the document has focus, pressing that keyboard shortcut will activate that button. If the button or other element is not currently available to be activated normally, for example because it's currently invisible or hidden, or explicitly marked as disabled, that implies that the keyboard shortcut is unavailable too.
>>> 
>>> • If this paragraph is intended to be non-normative, it should be wrapped in a Note.
>>> • The second and third sentences are run-on sentences.
>>> • The term "document" here is ambiguous or perhaps incorrect. Should this work in a containing frame's document? Perhaps this should be "window"?
>>> 
>>> That's all I've got for now.
>>> James
>>> 
>> 
> 
> 
> -- 
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru <mailto:chaals@yandex-team.ru> - - - Find more at http://yandex.com <http://yandex.com/>