Re: aria-kbdshortcuts feedback

Can we add tab to the list of roles?

Also - I'd like to see a way to have a keyboard shortcut allow 
navigation to a control (which requires input) much like accesskey can. 
It is a pretty common requirement to have a shortcut to move to a 
textarea where you can start typing a reply (for example). This proposal 
doesn't seem to cover that. Am I the only one that sees that (in which 
case I will drop it at this late stage) or is this a case for anyone else?

On 2/29/2016 9:50 AM, Dominic Mazzoni wrote:
> 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 <mailto: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
>>     <mailto: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.
>>>
>>

-- 
Regards, James

Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 
1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com 
<sip:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment