W3C home > Mailing lists > Public > public-aria@w3.org > February 2016

Re: aria-kbdshortcuts feedback

From: Rich Schwerdtfeger <richschwer@gmail.com>
Date: Thu, 25 Feb 2016 08:13:10 -0600
Cc: James Craig <jcraig@apple.com>, John Foliot <john.foliot@deque.com>, ARIA Working Group <public-aria@w3.org>, Charles McCathie Nevile <chaals@yandex-team.ru>
Message-Id: <539E8886-1C12-40AE-9863-2ED449B7FD3F@gmail.com>
To: Dominic Mazzoni <dmazzoni@google.com>
I thought about your comments overnight and another deficiency in accesskey came up and it has to do with context.

Take the ā€˜Lā€™ to like issue ā€¦ +1 for Google+. You could be on a page feed with a lot of likes (e.g. Facebook). We would really need for it to apply to the current context and not be just a page-wide access key (with activate capabilities). 

So we should consider other options as well:

1. We allow JavaScript to do this vs. accesskey with activate
2. We expand accesskey  to be scoped. IOW, depending where your focus is on the page, hitting the accesskey would got to the element in the nearest ancestor container it is applied in 
3. We allow the author to override the accesskey with script  whereby we associate access keys and threat them as page wide and the author is allowed to have a handler that handles the event. 

This last hybrid model would allow greater functionality and leave the keyboard arbitration issues to the user agent. 


Rich Schwerdtfeger

> On Feb 24, 2016, at 6:24 PM, Dominic Mazzoni <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.

Received on Thursday, 25 February 2016 14:13:41 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:20 UTC