Re: question about aria-keyshortcuts

While I understand that today AT does nothing with aria-keyshortcuts 
other than potentially read them out when an element is focused, I don't 
think we should limit ourselves to this.

I would like the ability to, for example, have a keyboard shortcut to go 
to a specific region of the page. For example in a call center 
application I have a region which allows an operator to interact with 
the telephony functionality. Simple operations like answer call and 
reject call have simple keyboard shortcuts as they are used frequently, 
but there may be other operations that the agent may need to do such as 
place a call on hold or review the incoming number. As such I would set 
up a "hidden" (using a technique that is available to screen readers) 
button which has a label and keyboard shortcut indicating its 
functionality. This would have aria-keyshortcuts on it.

It is my hope that screen readers will,  in the future if this attribute 
proves successful, provide functionality where they list all the 
keyboard shortcuts available on the screen. In order to do this there is 
no need for the controls to be focusable. Of course, until this time, 
and to enable keyboard only users who are not using AT, we will of 
course list these shortcuts in documentation / online help - but I would 
like a programmatic way to expose all types of keyboard operations to 
users rather than having to rely on this.

Regards,

James


On 11/22/2016 6:26 PM, Michiel Bijl (list) wrote:
> I’ve created a pull request that clarifies this: 
> https://github.com/w3c/aria/pull/487
>
> —Michiel
>
>> On 19 Nov 2016, at 16:49, Matt King <a11ythinker@gmail.com 
>> <mailto:a11ythinker@gmail.com>> wrote:
>>
>> The intent is focusable only.
>>
>> Where the spec says:
>>> Indicates keyboard shortcuts that an author has implemented to 
>>> activate or
>> give focus to an element.
>>
>> It would probably be more clear if it said "the element" instead of "an
>> element". But, it means that you put aria-keyshortcuts on the element 
>> that
>> will get activated or focused. You can only activate or focus an 
>> element if
>> it is focusable.
>>
>> Compare this to the definition of other properties that use the term "an
>> element". For example, haspopup:
>>
>>> Indicates the availability and type of interactive popup element, 
>>> such as
>> menu or dialog,
>>> that can be triggered by an element.
>>
>> Matt
>>
>> -----Original Message-----
>> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
>> Sent: Friday, November 18, 2016 4:50 PM
>> To: ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org>>
>> Subject: question about aria-keyshortcuts
>>
>> Hi,
>> Is aria-keyshortcuts supposed to only be used on focusable elements, 
>> or on
>> any element? The spec is not clear on this.
>>
>> Also, if it is acceptable on non-focusable elements, how is this to be
>> conveyed to AT users?
>>
>> Thanks,
>> Bryan
>>
>>
>>
>>
>>
>> Bryan Garaventa
>> Accessibility Fellow
>> SSB BART Group, Inc.
>> bryan.garaventa@ssbbartgroup.com 
>> <mailto:bryan.garaventa@ssbbartgroup.com>
>> 415.624.2709 (o)
>> www.SSBBartGroup.com
>>
>>
>>
>>
>

-- 
Regards, James

Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 
1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com 
<sip:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment