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

Re: aria-kbdshortcuts feedback

From: Chaals McCathie Nevile <chaals@yandex-team.ru>
Date: Thu, 25 Feb 2016 01:06:09 +0100
Cc: "John Foliot" <john.foliot@deque.com>, "Dominic Mazzoni" <dmazzoni@google.com>, "ARIA Working Group" <public-aria@w3.org>
To: "James Craig" <jcraig@apple.com>, "Richard Schwerdtfeger" <richschwer@gmail.com>
Message-ID: <op.ydc3wjp7s7agh9@widsith.local>
On Thu, 25 Feb 2016 00:43:00 +0100, Richard Schwerdtfeger
<richschwer@gmail.com> wrote:

>
>> On Feb 24, 2016, at 3:14 PM, James Craig <jcraig@apple.com> wrote:
>>
>> Note the time. I agree with John Foliot. ;-)
>>
> My watch just stopped. LOL.
>
>> 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 agree. We need the other issues addressed however and group agreement  
> with the approach. In particular, if the user agent is going to assign a  
> key that the author did not choose how would this be discovered by the  
> end user? To me this is a big problem.

If the user agent assigned the key, then it knows what it is.
accessKeyLabel is meant to deal with this at least for the javascript
case, although currently only Firefox supports it.

But it's not rocket surgery for a user agent to provide a list of assigned
shortcuts.

It's also easy for an extension to do so.

     var thingsWithKeys = document.querySelectorAll('*[accesskey]');

gives a list of the author-declared values. In all bare browsers today,
knowing the modifier applied (which except in Opera 12, as far as I know,
cannot yet be configured ;( ) means you don't need accessKeyLabel, you can
just check the accessKey DOM attribute or the value of the source
attribute, and you're done.

> We also need to decide on this fairly quickly. We are trying to lock  
> down 1.1. Dominic raised the issue. I would like to see him satisfied  
> with the solution, or a version of the solution, that Charles is  
> proposing.
>
>> Rich wrote:
>>> What are they doing to ensure this works with SVG?
>>
>>
>> I heard a rumor that SVGElement was planning to change to inherit from  
>> HTMLElement rather than Element. If that is the case, this would be a  
>> non-issue. Rich, will you take an action to find out if there is any  
>> truth to that rumor?
>>
>> Regardless, presumably the accesskey draft could define this partial  
>> interface on both SVGElement and HTMLElement.
>>
>
> That won’t happen for some time as they are trying to lock down the SVG2  
> spec. Currently, it extends Element:
>
> https://svgwg.org/svg2-draft/idl.html
>
> Also, I don’t think we want accesskey on HTMLElement. There are a lot of  
> elements that you would not want an accesskey on.

In principle, yes. In practice I doubt it is a big problem. You do want to
be able to focus all the things that people use, whether they are a priori
interactive or not, for interactive components, and to be able to activate
them.

Like tabindex=0, it may be cheaper to make it apply to everything by spec,
and just do nothing if you somehow try to "activate" e.g.

     <meta charset="utf-8" accesskey="愚">

There are of course edge cases like meta refresh where it might be  
meaningful (although I am sceptical).

But I welcome thoughts on this.

> If this is accepted the issue needs to be logged with SVG.

Sure.

Cheers

>> James
>>
>>> On Feb 24, 2016, at 10:03 AM, 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.
>>>>>>
>>
>


-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
    chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Thursday, 25 February 2016 00:06:50 UTC

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