Evaluate whether use case needs a new ARIA feature — a way to define page-wide keyboard shortcuts

aleventhal commented 3 weeks ago

JAWS currently supports a non-standard attribute called data-at-shortcutkeys, used by Twitter/X and Facebook. I'm in the process of helping JAWS remove support for anything nonstandard, but they need to be able to support the same features if possible. A lot of web apps have page-wide shortcut keys (Gmail is an example), so this does seem to be a use case.

How should web pages code this up?

Should ARIA consider a new feature here? Could we consider reusing aria-keyshortcuts somehow? E.g. allow it with a JSON list of keys on non-focusable container elements? Or just the body?

The format:

Currently this attribute provides JSON with key/value pairs — "[key name]": "localized description".
JAWS splits it into key/value pairs and we check to see which key we should allow through to the web page.

Example from facebook.com (in the actual version quotation marks are escaped with their entity, "e;):

<div data-at-shortcutkeys="{"?":"Show or hide keyboard help","/":"Search Facebook","c":"Comment on current post","enter":"See more of current post","f":"Toggle fullscreen","j":"Go to next post in a feed or next photo in photo viewer","k":"Go to previous post in a feed or previous photo in photo viewer","l":"Like or react to current post in a feed or photo in photo viewer","o":"Open attachment from current post","p":"Create new post","q":"Search Messenger contacts","s":"Share current post"}"></div>

aleventhal commented 3 weeks ago

@mcking65

michaelDCurran commented 3 weeks ago

NVDA does not currently support the existing non-standard version, however if this were standardized, we may at very least report the fact a web page has custom keys, and perhaps list them on demand.

aleventhal commented 3 weeks ago

I propose that we repurpose aria-keyshortcuts when it's on the <body> of a web page. Anywhere else it acts as it does now.

stes-acc commented 3 weeks ago

I propose that we repurpose aria-keyshortcuts when it's on the of a web page. Anywhere else it acts as it does now.

On the what? The body?

aleventhal commented 3 weeks ago

I propose that we repurpose aria-keyshortcuts when it's on the of a web page. Anywhere else it acts as it does now.

On the what? The body?

Yes, I forgot the backticks.

stes-acc commented 3 weeks ago

Hm this means that aria-keyshortcuts gonna be allowed on containers (by principle, non-focusable, non-interactive stuff) too.

https://www.w3.org/TR/html-aam-1.0/#el-body says role "generic" which maps for instance to "group" in UIA.

This would be OK according to the keyshortcuts spec (all elements of base markup) but will require adjustment for best practices (for example, in ARIA APG).

More important, if you propose this, you also need to describe how to satisfy the following ARIA spec condition being part of the aria-keyshortcuts definition:

_Authors SHOULD provide a way to expose keyboard shortcuts so that all users can discover them, such as through the use of a tooltip._

A tooltip on the body is a bit pointless (people are not used to invoke that and it cold be annoying on hovering), so at least a different mechanism/pattern to inform all users have to be proposed, too. Of course it could be injected for instance in the browser context menu of the body, or/and you provide that info as part of general application help etc. Anyway, I think there needs to be group consensus on the methodology / recommendations to expose these on the UI at will.

By the way, since screen readers do speak the content of the aria-keyshortcuts property e.g. on button focus seperately, informing also in tooltip has the side effect that the respective keyshortcuts for the element will be spoken twice since tooltip is naturally also spoken. Is this acceptable? Suppressing the tooltip speech output generally by screen reader settings is no option since that may suppress other useful info for other controls.

scottaohara commented 2 weeks ago

Is there really a reason we need group consensus over something that is an author should, where what an author should do is going to be heavily dependent on the ui / logical location to provide such hints?

the “such as … a tooltip” was only an example, after all.

Maybe just add another example of what an author could do. But we shouldn’t need to get too prescriptive

stes-acc commented 2 weeks ago

"Is there really a reason we need group consensus "

In case of contradictions, it is. There should be more elaborated examples if the only example given does not fit for a variety of reasons.

aleventhal commented 2 weeks ago

I heard skepticism from a number of screen reader users about the way this is implemented by JAWS, where it lets the keys through (as opposed to a mere announcement which can be done via other means). It would be good to find out whether JAWS still considers this feature important. After all, @mcking65 expressed some misgivings about the way this is done for Facebook. Also, NVDA said they do not plan to implement that way. Maybe the best thing is to axe the feature and possibly replace with JAWS scripts that are aware of Facebook and Twitter, rather than have a piece of standard markup that has high potential for abuse.

aleventhal commented 2 weeks ago

@stes-acc I think we should determine whether we even want the feature first, and only if the answer is yes, determine what mechanism (including whether reusing existing markup makes any sense).

MarioBatusic commented 2 weeks ago

I find the idea of listing global keyboard shortcuts / keys for all users very important and useful. Whether we reuse aria-shortcuts for that or define something new. Concerning the way of displaying this keyboard info I thinkk the best would be to have a browser Menu item / Shortcut for this task. Imlementing an additional SR function for that can either exclude non-scren reader users from this information or double the voice output for SR users if using "title" attribute.

cookiecrook commented 2 weeks ago

@MarioBatusic wrote:

I find the idea of listing global keyboard shortcuts / keys for all users very important and useful.

Could this be a general web platform feature? OpenUI? WICG? WHATWG? Seems beneficial outside the screen reader use case. Could make these commands/actions more broadly available.

spectranaut commented 1 week ago

Minutes from last weeks meeting: https://www.w3.org/2024/10/17-aria-minutes#0e73

MarioBatusic commented 1 week ago

Some important things for our co-work with openUI:

Browser should list all global keys / keyboard shortcuts, not only single-letter ones. For example, we have a number of global shortcut keys combined with alt or shift key in our cloud solutions.
Browsers could offer this list in a menu or toolbar. The commands can be listed and executable in the same time.
Windows screen readers should not let the single-letter-key commands through in their reading mode. After consulting the browser global shortcut list, the user can switch in the focus mode to be able to use the shotcuts.

w3c / aria

Evaluate whether use case needs a new ARIA feature — a way to define page-wide keyboard shortcuts #2351