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

Re: aria-kbdshortcuts feedback

From: Richard Schwerdtfeger <richschwer@gmail.com>
Date: Fri, 26 Feb 2016 07:33:12 -0600
Cc: Dominic Mazzoni <dmazzoni@google.com>, John Foliot <john.foliot@deque.com>, ARIA Working Group <public-aria@w3.org>, Charles McCathie Nevile <chaals@yandex-team.ru>
Message-Id: <7AAD45DE-FDC0-4EAC-8C67-8A774019326A@gmail.com>
To: James Craig <jcraig@apple.com>
I will work on the text changes. We have until March 11 to freeze. 

I will review the text with IBM's i18n department. 

I am not sure what W3C’s i18n group will give us over the respective companies from 3+ major corporations but I can look into it. That seems a bit overkill. 


> 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.

Received on Friday, 26 February 2016 13:33:41 UTC

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