-
Notifications
You must be signed in to change notification settings - Fork 125
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
Comments
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. |
I propose that we repurpose aria-keyshortcuts when it's on the |
On the what? The body? |
Yes, I forgot the backticks. |
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. |
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 |
"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. |
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. |
@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). |
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. |
@MarioBatusic wrote:
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. |
Minutes from last weeks meeting: https://www.w3.org/2024/10/17-aria-minutes#0e73 |
Some important things for our co-work with openUI:
|
@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. |
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. |
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?
The format:
The text was updated successfully, but these errors were encountered: