Re: aria-kbdshortcuts property for review - ACTION-1642

Responses and more detailed concerns interspersed. Including Jukka for opinion. (Jukka, read in reverse order for context.)

> On Jun 12, 2015, at 10:21 AM, Dominic Mazzoni <dmazzoni@google.com> wrote:
> 
> 1. This does not account for cross-platform usage. E.g. <button> shortcut is space bar on Mac, Enter on Windows, and that’s the simplest example. The “meta” keyword is a start, but that only helps with simple shortcuts, like copy/paste.
> 
> Wait, but those are shortcuts to activate the control *when focused*. Totally different.
> 
> This proposal is for shortcuts that activate a control or command *globally*, like Cmd+S for Save. Yes, it's up to the author to adjust that for each platform, but many web apps have separate keyboard shortcuts for each platform, e.g.: https://support.google.com/docs/answer/179738?hl=en <https://support.google.com/docs/answer/179738?hl=en>
If this is an ARIA replacement for @accesskey or HTML5 command, both of those should be listed in the Related Concepts section. 

Why not use a <meta> element or the native equivalent, with an IDREF to the control? This way the user agent doesn't need to deep-scan the DOM to find all the commands. For the record, I am still concerned about the general idea, but suggested this as a good-faith improvement to the overall design of the feature.

> 2. This does not add support for actually capturing the keys, so there is a high potential for mismatch via author error, leading to user confusion. I feel this is the strongest case against this new property.
> 
> How is that different than anything else in ARIA?

ARIA 1.0 used to have normative keyboard shortcut authoring requirements for each role. We removed it for the reasons listed and others. 

I'm wary about the assumptions made in these paragraphs, for example.

>>> Modifier keys must be specified 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/Keyboard_Shortcuts/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.

Why isn't the Control key listed as the "Meta" key on Windows? What is the Windows key? How do you handle conflict resolution with a native shortcut, whether a default or user-defined one?

How do you specify the Option key (Opt) on Mac? It's not the same as Alt, which can be triggered by (fn+Opt) on Mac. Likewise, Enter on Windows is equivalent to fn+Return on Mac.

>>> When specifying a key on the keyboard that changes when you hold down a modifier key other than an alphabetic key, you must specify the unmodified key name. 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.


This seems like an arbitrary distinction. Shift+5 happens to be % in many western keyboard layouts, so let's use another common example: Ctrl+=

You can't detect I'm using a German keyboard with an English locale so there is no way to specify these keyboard shortcuts accurately. What you specify as Ctrl+= would be Ctrl+Shift+0 on my German keyboard layout. 

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

Does this mean that Ctrl+Ü and Ctrl+Shift+ü are non-equivalent, too? If so, you should include an example.

What happens if an author specifies Option+u, which on Mac is the key command that allows you to type the umlaut in ü. That will always be reserved.

How do you handle combo shortcuts, e.g. press Opt+u then Command+u to get "Meta+ü"? Would you add a comma syntax like is used with phones? 

> 3. There is no internationalization support. E.g. What is Ctrl+M on a Russian or Hindi keyboard?
> 
> If a web app is fully localized into Russian, then presumably they've come up with keyboard shortcuts that work in Russian too. All they need to do is describe that shortcut according to the spec. That's why I tied it to the keyboard event spec - that way it supports every key from every international keyboard that's possible to capture with JavaScript.

It doesn't matter if the app is localized in Russian. Many more people in the world speak, read, and type English than use Qwerty keyboards.

> Not using the correct localized shortcut here would be just as bad as not localizing alt text.
> 
> 4. Minor nits: “kbdshortcuts” is a hybridization of abbreviation and not, and also pluralized for some reason.
> 
> There were several votes for aria-keys, I like that. It's plural on purpose, an element can have multiple shortcuts.

You'd need to work out conflict resolution, too. What happens when multiple commands use the same combination?

> In order to make this work consistently, you’d need something more akin to @srcset, but with an added DOM interface to account for keyboard event interception.
> 
> srcset is needed because the web server doesn't know the resolution of the monitor at request time, right? The web server does know the locale of the user agent when serving the page, so it only needs to generate one shortcut - the one for the user's locale.

To my knowledge, there is no way to detect keyboard layout. I may be wrong.
http://stackoverflow.com/questions/8892238/detect-keyboard-layout-with-javascript

James

> I don’t believe this proposal is ready for the spec. At a minimum, it should be marked as at-risk for these reasons.
> 
> James 
> 
> 
> On Jun 12, 2015, at 8:43 AM, Michael Cooper <cooper@w3.org <mailto:cooper@w3.org>> wrote:
> 
>> I have posted a branch with Rich's proposal for the aria-kbdshortcuts property:
>> 
>> https://rawgit.com/w3c/aria/Keyboard_Shortcuts/aria/aria.html#aria-kbdshortcuts <https://rawgit.com/w3c/aria/Keyboard_Shortcuts/aria/aria.html#aria-kbdshortcuts>
>> 
>> A couple notes:
>> I made "must" to be RFC2199 MUST.
>> Because of this, the DOM Level 3 KeyboardEvent key Values spec needed to be a normative reference. We've avoided having too many normative dependencies, and while it's ok for now, ARIA 1.1 wouldn't be able to advance to Recommendation until that spec does. That may be appropriate, but I wanted to point it out.
>> After putting the property on the four roles listed in Rich's proposal, I note that it inherited into one role not listed in the proposal: switch. That's probably fine but wanted to make sure it was clear where it's inheriting into.
>> Michael