Re: aria-kbdshortcuts feedback

The changes look good, thanks. I think the widget roles it applies to is
correct.

I don't think there's anything we need to mention about duplicate
shortcuts. I think most people would realize that's probably not a good
idea and I'm not sure what other advice we should give.

On Sun, Feb 28, 2016 at 8:42 AM Richard Schwerdtfeger <richschwer@gmail.com>
wrote:

> Hi Dominic,
>
> Here is a draft of the spec. with the changes:
>
> https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts
>
> Please check the text to make sure it matches what you intended. Do you
> think Also, do you think we should suggest text to the author regarding the
> use of duplicate shortcuts. I have not yet checked to see if there were any
> widgets that we missed that this should be applied to. You gave the example
> of the like shortcut in Facebook which of course there are many of those.
>
> Rich
>
>
> On Feb 25, 2016, at 4:31 PM, James Craig <jcraig@apple.com> wrote:
>
> Dominic's feedback has convinced me we have enough justification to keep
> the aria-kdshortcuts feature.
>
> However, these things should happen prior to publishing:
>
> 1. Name changed to something uncontracted (e.g. not 'kbd') to match
> existing ARIA conventions. (hotkeys or keyshortcuts, perhaps?)
> 2. Clarify who the RFC-2119 requirements apply to.
> 3. Editorial: Clean up the informative prose, add [ARIA 1.1] to the
> description, and fix "Ctrl" examples to match "Control" ENUM specified in
> KeyboardEvent.
> 3. Dominic requests review with i18n team at Google.
> 4. I will request review with i18n team at Apple.
> 5. Optional: other vendors (Mozilla, Microsoft) check on the i18n impacts
> as well.
> 6. Someone (likely Rich as Chair?) emails relevant W3C i18n group(s)
> outlining the issues (cc public-aria) and requesting review.
>
> Thanks,
> James
>
>
> On Feb 24, 2016, at 4:24 PM, Dominic Mazzoni <dmazzoni@google.com> wrote:
>
> On Wed, Feb 24, 2016 at 1:14 PM James Craig <jcraig@apple.com> wrote:
>
>> In addition, an accesskey replacement spec would have the ability to
>> specify end use behavior (and event model changes) in a way that would be
>> inappropriate to do in an ARIA spec. Dominic, would you be willing to
>> pursue the solution in that spec rather than in ARIA?
>>
>
> I took a closer look. Current limitations of the accesskey spec that I see:
>
> 1. It doesn't require the user agent to activate the element, it's allowed
> to just focus it. That means that if a web app currently has shortcuts that
> activate something, switching to accesskey wouldn't achieve the same thing.
>
> 2. Accesskey still only allows you to specify a single key, the user agent
> chooses the modifier keys. This wouldn't help a web app that wants to
> trigger when you press an unmodified key, or a web app that wants to listen
> for a specific shortcut.
>
> Here are some examples of real-world shortcuts on six popular sites:
> * 'C' to compose a new message in Gmail/Inbox
> * Ctrl+Shift+C to do a Word Count in Google Docs
> * Shift+A to "reply all" in Yahoo Mail
> * 'L' to like the current story on Facebook
> * '/' to focus the search box on Twitter
> * 'C' to create an issue on GitHub
>
> The accesskey spec doesn't support *any* of these.
>
>
>