Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
aleventhal opened this issue Oct 8, 2024 · 16 comments
Assignees
Labels
feature may add new concept(s) to ARIA which will require implementations or APG changes openui

Comments

@aleventhal
Copy link
Contributor

aleventhal commented Oct 8, 2024

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, &quote;):
<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
Copy link
Contributor Author

@aleventhal aleventhal added the feature may add new concept(s) to ARIA which will require implementations or APG changes label Oct 8, 2024
@michaelDCurran
Copy link

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
Copy link
Contributor Author

aleventhal commented Oct 9, 2024

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
Copy link

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
Copy link
Contributor Author

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
Copy link

stes-acc commented Oct 11, 2024

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
Copy link
Member

scottaohara commented Oct 12, 2024

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
Copy link

"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
Copy link
Contributor Author

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
Copy link
Contributor Author

@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
Copy link
Contributor

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
Copy link
Contributor

cookiecrook commented Oct 17, 2024

@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
Copy link
Contributor

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

@MarioBatusic
Copy link
Contributor

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.

@aleventhal
Copy link
Contributor Author

@keithamus do I recall correctly that you were planning to bring this up in Open UI or HTML? Or was that someone else? Wanting to get some kind of update.

@keithamus
Copy link
Member

Yes I'm working on a proposal doc for OpenUI which I'll present to them in the coming weeks. It's a very big topic but I hope to have something this month or next perhaps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature may add new concept(s) to ARIA which will require implementations or APG changes openui
Projects
None yet
Development

No branches or pull requests

9 participants