Charles, Are you willing to extend the accesskey spec. to perform an activation? Otherwise, this is at 2 step process - give focus and then manually activate. http://chaals.github.io/accesskey/index.src.html Rich 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 01:27:39 UTC