search

w3c / aria

Accessible Rich Internet Applications (WAI-ARIA)
https://w3c.github.io/aria/
Other
654 stars 125 forks source link

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

Open aleventhal opened 1 month ago

aleventhal commented 1 month 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?

The format:

aleventhal commented 1 month ago
michaelDCurran commented 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 month ago

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

MarioBatusic commented 1 month ago

Some important things for our co-work with openUI:

aleventhal commented 2 weeks ago

@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 commented 2 weeks ago

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.