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

On Fri, Jun 12, 2015 at 11:38 AM James Craig <jcraig@apple.com> wrote:

> If this is an ARIA replacement for @accesskey or HTML5 command, both of
> those should be listed in the Related Concepts section.
>

I think HTML5 command is obsolete, but @accesskey is related.

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

Would that be better for web authors or better for user agents / AT?

I think the current proposal is much more natural for web authors - specify
the keyboard shortcut directly with the element it supports.

Finding all of the commands doesn't sound like something that would need to
be done frequently. If AT wants to get a list of all elements with keyboard
shortcuts quickly, we can extend existing mechanisms to make that more
efficient - for example on Mac OS X we could use the
AXUIElementsForSearchPredicate API.

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 see, your concern is not as much about authors using the attribute at
all, but not directly conforming to the spec, like if the author writes
"Cmd+S" for a Mac shortcut instead of the strange-looking "Meta+S" which is
what the spec requires.

That's a reasonable concern. It's true that an attribute that actually
binds keys to activating an element would be much better in that you'd know
for sure that the accessible version matches the implementation. I think we
have to balance that against the fact that keyboard shortcuts are extremely
widespread. Asking developers to add an aria-keys attribute is much easier
than asking them to use a totally new attribute that may take a long time
to get browser support.

Keep in mind that even if the author provides the wrong syntax, the AT
still gets some information - a lot more than it gets now.

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?
>

Aren't those all questions for the authors of the KeyboardEvent spec? I
don't love all of the decisions made in that spec, but it's the standard.

Also, note that this keeps the spec consistent with the author's event
listener code. If I want to detect Cmd+S on Mac, I have to check
event.metaKey == true and event.keyCode == 'S'.


> How do you handle conflict resolution with a native shortcut, whether a
> default or user-defined one?
>

You don't. Specifying a conflicting shortcut is an author error.

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

The answer to these is, whatever the KeyboardEvents spec says to do. That
spec tells you how to write JS code to handle those keys, and aria-keys
should use the exact same syntax to advertise support for those keys.




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

Yes, but my point is that this is not a concern of aria-keys.

In Cocoa, the NSMenuItem constructor takes a key equivalent, and you can
also set the modifier mask. It doesn't prevent you from setting a key
equivalent that can't be pressed on all keyboards - it's up to the author
to pick something as universal as possible, based on the locale, or give
users options to change it.




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

Agreed.


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

That would be an author error. The problem isn't really with aria-keys,
it's that their event listener for that keyboard shortcut wouldn't actually
work.


> 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?
>

Yes, we could do that. I wasn't sure how important that use-case was to add
to the spec.

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

Again, I don't see how this is an issue with the ARIA attribute. If the web
app has implemented a shortcut that's possible to type on a Russian
keyboard, then Russian users will be happy, and aria-keys can reflect the
actual shortcut. If the web app hasn't implemented that shortcut, Russian
users will complain and the developer can choose to implement different
shortcuts, and modify aria-keys to reflect that.

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

That'd be an author error, just like having two elements in the document
with the same id, making it ambiguous what aria-labelledby points to.

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
>

Perhaps that's needed too?