RE: aria-kbdshortcuts feedback

James, I completely agree. The definition is too restrictive. Keyboard shortcuts are used to either move focus or activate. It should support both use cases.

 

Shortcuts are often used to move focus to a listbox, tablist, toolbar, radio group, textbox, etc. In my experience, it is more likely that there would be a shortcut for a listbox, tree, or grid than there would be for an option, treeitem, or gridcell.

 

I suggest shortening the definition and then including a subsequent paragraph with broader language. Perhaps:

 

Indicates the keys that activate or focus an element.

 

The keyboard shortcuts property communicates which keys an author has enabled for focusing or activating an element. If an element is a widget that has a click behavior, such as a button, link or menuitem, pressing the indicated key or key combination will typically activate that behavior. If the element is a container or composite widget, such as a toolbar, tablist, tree or grid, pressing the indicated keyboard shortcut will usually move focus to a focusable descendant element.

 

Then, we could consider making it global.

 

Matt King

 

From: James Nurthen [mailto:james.nurthen@oracle.com] 
Sent: Monday, February 29, 2016 12:57 PM
To: public-aria@w3.org
Subject: 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 

 <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 <mailto:james.nurthen@oracle.com>  
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065 
 <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment