RE: question about aria-keyshortcuts

So, the question was, does an item with keyshortcuts need to be focusable.

 

James Nurthen wrote:

> I would like the ability to, for example, have a keyboard shortcut to go to a specific region of the page. 

 

"Go to" usually means "move focus to", right? So the region would have a tabindex, perhaps set to -1, wouldn't it?

 

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

 

What is the purpose of the hidden button?

 

Wouldn't all users want the key shortcut for hold?

 

To give fast access to the phone number, couldn't you do something like:

<span tabindex="-1" aria-keyshortcuts="Alt+N">123-456-789</span>

 

But, maybe all users should see the number in a read-only edit so they can easily copy it if needed.

 

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

 

Wouldn’t it be better if this were a function of your application so all users can access the list/menu and utilize it in context?

 

I imagine some screen readers would do this, but it seems like there is much more value to web authors doing it.

 

That said, I can agree that we do not need to require focusability. I can imagine some very rare scenarios where we need to hack in a stopgap bug fix that uses a key shortcut for an off-screen widget that provides screen reader only function. However, I think this is a case where normal good/best practice means authors SHOULD only use it on focusable items because things you can activate (widgets) and things you can focus (widgets or structures) should all be focusable. Obviously, that does not require them to be in the tab sequence. They could be buried 3 layers deep in a menu system.

 

Matt

 

From: James Nurthen [mailto:james.nurthen@oracle.com] 
Sent: Wednesday, November 23, 2016 12:01 PM
To: public-aria@w3.org
Subject: 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 <http://www.SSBBartGroup.com> 





 

 

-- 
Regards, James 

 <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 
 <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment