Re: aria-kbdshortcuts feedback

Rich brings up another potential issue with the ARIA feature.

> 4. Does not handle a fallback mechanism in case a key combination is taken or cannot function (different keyboards). Yet, the author is responsible for doing the testing. It is documentation and much lighterweight than accesskey

One problem with ARIA 1.0 is that most new authors think it's sufficient to specify role="button" (or any control for that matter) on an element. Even adding tabindex="0" is insufficient unless you also register keypress events for Enter (Windows/Linux) and Spacebar (Mac).

There is no magic keyboard event handling associated with ARIA attributes (nor should there be), which is confusing to many authors. For this reason, a native solution like an @accesskey implementation would be better, since it's fair for these features to specify user agent behavior such as keyboard event interception.

James


> On Feb 24, 2016, at 12:13 PM, Richard Schwerdtfeger <richschwer@gmail.com> wrote:
> 
> Hi John,
> 
> So, I went briefly through the accesskey spec. and see some issues and positive points
> 
> 1. The access key is limited to a very small list of elements. 
> 2. I like that it tries to ask the user agent to spec. the key mapping (they are suggested mappings). This could potentially address keyboard inconsistencies. 
> 3. It does not address SVG which does does not have an accesskey. 
> 4. It does not specify what to do with multiple characters: TR. Is that a key sequence or a key combination (both are pushed down)
> 5. It appears that the labels of the control merge the short cut. That may not work for all controls. 
> 6. The keys it supports is limited to what elements the accesskey can be applied to. 
> 7. If the user agent assigns the key (the accesskey is a suggestion) how do you find what the key is that is assigned. 
> 
> What Dominic is proposing:
> 
> 1. keyboard shortcut documentation for any interactive element. the presence of the attribute does not force the user agent to try to implement it.
> 2. Clear definitions for how to represent keys and modifiers (I am not seeing that in the accesskey spec.)
> 3. Is applicable to SVG. 
> 4. Does not handle a fallback mechanism in case a key combination is taken or cannot function (different keyboards). Yet, the author is responsible for doing the testing. It is documentation and much lighterweight than accesskey
> 5. Does not say what the function does however it is the equivalent of an activate or a click. 
> 6. The implementation is left to the author (javascript)
> 7. The keys specified has a richer vocabularly 
> 
> Dominic, what are your thoughts on Charles proposal? What are we overlooking?
> 
> Rich
> 
>> On Feb 24, 2016, at 12:03 PM, John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com>> wrote:
>> 
>> Hi Rich,
>>  
>> To your first question, I don’t actually have a specific answer, and note that the current Draft from Chaals is just that, a draft. My larger point is that there should be some type of coordination here.
>>  
>> To your second question, that draft is related to the HTML5 @accesskey attribute – does SVG have a similar attribute? If not, then I would guess that this proposed aria attribute is intended to replicate the functionality. I think we’d want the behavior of @accesskey and @aria-keyboardshortcut to essentially operate in a similar (identical?) fashion.
>>  
>> JF
>>   <>
>> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com <mailto:richschwer@gmail.com>] 
>> Sent: Wednesday, February 24, 2016 11:11 AM
>> To: John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com>>
>> Cc: Dominic Mazzoni <dmazzoni@google.com <mailto:dmazzoni@google.com>>; ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org>>; James Craig <jcraig@apple.com <mailto:jcraig@apple.com>>; Charles McCathie Nevile <chaals@yandex-team.ru <mailto:chaals@yandex-team.ru>>
>> Subject: Re: aria-kbdshortcuts feedback
>>  
>> What browser support does this Chaals keyboard shortcut have?
>> What are they doing to ensure this works with SVG?
>>  
>>  
>> Rich Schwerdtfeger
>>  
>>  
>> 
>>  
>>> On Feb 24, 2016, at 10:59 AM, John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com>> wrote:
>>>  
>>> Hi Rich,
>>>  
>>> I do agree with your comments, however I think as well that as the ARIA WG addresses aria-keyboardshortcuts [sic] that any solution be in step with, and not counter to, work that is happening around @accesskey 
>>>  
>>> JF
>>>  
>>> From: Richard Schwerdtfeger [mailto:richschwer@gmail.com <mailto:richschwer@gmail.com>] 
>>> Sent: Wednesday, February 24, 2016 10:27 AM
>>> To: John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com>>
>>> Cc: Dominic Mazzoni <dmazzoni@google.com <mailto:dmazzoni@google.com>>; ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org>>; James Craig <jcraig@apple.com <mailto:jcraig@apple.com>>; Charles McCathie Nevile <chaals@yandex-team.ru <mailto:chaals@yandex-team.ru>>
>>> Subject: Re: aria-kbdshortcuts feedback
>>>  
>>> The accesskey Charles is proposing suffers from similar issues regarding knowing the keyboard type. 
>>>  
>>> How are the accesskeys exposed to ATs?
>>> This implementation of accesskeys requires they be visible but if the author does not want to show them all the time will the be active? … What if the accesskeys are such that:
>>>  
>>> <nav hidden>
>>> …
>>> </nav>
>>>  
>>>  
>>> Rich
>>>  
>>>> On Feb 24, 2016, at 10:02 AM, John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com>> wrote:
>>>>  
>>>> Hi All,
>>>>  
>>>> I suspect that there will be an intersection between this topic and Chaals’ current Draft Proposal on @accesskey, found here: http://chaals.github.io/accesskey/index.src.html <http://chaals.github.io/accesskey/index.src.html>
>>>>  
>>>> Specifically to one of James’ concerns, there is a consideration for i18n in there.
>>>>  
>>>> (Note to Chaals: the Contents link to “5.5 Assigning Keyboard Shortcuts <http://chaals.github.io/accesskey/assigning-keyboard-shortcuts>” in the current draft is broken)
>>>>  
>>>> JF
>>>>  
>>>> From: Richard Schwerdtfeger [mailto:richschwer@gmail.com <mailto:richschwer@gmail.com>] 
>>>> Sent: Wednesday, February 24, 2016 9:32 AM
>>>> To: Dominic Mazzoni <dmazzoni@google.com <mailto:dmazzoni@google.com>>
>>>> Cc: ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org>>; James Craig <jcraig@apple.com <mailto:jcraig@apple.com>>
>>>> Subject: Fwd: aria-kbdshortcuts feedback
>>>>  
>>>> Hi Dominic, 
>>>>  
>>>> You put the original proposal in for this so I wanted to bring you into this discussion. 
>>>>  
>>>> I would imagine that anyone implementing keyboard shortcuts would need to know their are limitations beyond knowing what the languages is for the page, regarding the keyboard being used. Given that you know the language you are targeting do you feel it is enough to be able to determine your keyboard shortcuts when authoring a page? 
>>>>  
>>>> Have you vetted this with the Google i18N experts?
>>>>  
>>>> I personally don’t have issues with James name change to aria-keyboardshortcuts other than it is very long or the use of the word control (this is spelled out on Mac keyboards). 
>>>>  
>>>> We are working toward locking ARIA 1.1 down so that we can move on to ARIA 2.0, web component support, etc. 
>>>>  
>>>> Rich
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> Begin forwarded message:
>>>>>  
>>>>> From: James Craig <jcraig@apple.com <mailto:jcraig@apple.com>>
>>>>> Subject: aria-kbdshortcuts feedback
>>>>> Date: February 24, 2016 at 3:33:06 AM CST
>>>>> To: ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org>>
>>>>> Resent-From: public-aria@w3.org <mailto:public-aria@w3.org>
>>>>>  
>>>>> Issue #1: Name: kbdshortcuts. With the notable exception/oversight of the "img" role, ARIA doesn't use abbreviations like "kbd" in role or attribute names. This one should be changed to aria-keyboardshortcuts or something shorter like aria-hotkeys.
>>>>> 
>>>>> Issue #2: Spec examples make it seem as if both "Control" and "Ctrl" are valid values. My interpretation of the KeyboardEvent spec is that only "Control" is valid.
>>>>> 
>>>>> Issue #3: This prose:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> When specifying a key on the keyboard that changes when you hold down a modifier key other than an alphabetic key, you must specify the unmodified key name. For example, on most U.S. English keyboards, the percent sign "%" can be printed by pressing Shift+5. The correct way to specify this shortcut is "Shift+5". It is incorrect to specify "%" or "Shift+%". However, note that on some international keyboards the percent sign may be an unmodified key, in which case "%" and "Shift+%" would be correct on those keyboards.
>>>>> 
>>>>> 
>>>>> If I recall correctly, I raised this specific example on the list last year as a reason for not including the property in ARIA 1.1. It is not possible for the web application to know which keyboard is being used and therefore not possibly to implement this feature in a i18n-friendly manner. Simply stating in prose that there is a problem does not resolve the problem. 
>>>>> 
>>>>> Please don't publish this feature without consulting some of the W3C i18n experts.
>>>>> 
>>>>> Issue #4: Editorial: Spec does not list [ARIA 1.1] on this property.
>>>>> 
>