Re: aria-kbdshortcuts feedback

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 <mailto:dmazzoni@google.com>> wrote:
>> 
>> On Wed, Feb 24, 2016 at 1:14 PM James Craig <jcraig@apple.com <mailto: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.
>> 
>