Consider an attribute to declare the presence of a "context menu" for a currently-focused element

[vick08]

Description of bug or feature request

Some web apps, such as GOogle Calendar or Gmail, provide context menus for the currently-focused control that can be activated by either invoking a browser's right-click menu or a screen reader specific "context menu" shortcut key, e.g. Shift+F10 (Windows) or Control+Option+Shift+M (VoiceOver / Mac)..
It does not appear that ARIA currently allows developers to declare the presence of such menus to the screen reader or another AT user.
This feature request is to consider an ARIA attribute to cover this particular use case.

Will this require a change to CORE-AAM?

If unknown, leave blank. If relevant, link bug.

Will this require a change to the ARIA authoring guide?

Yes

If unknown, leave blank. If relevant, link bug.

[pkra]

This was discussed on July 13. https://www.w3.org/2023/07/13-aria-minutes.html

The general feeling was that this would not add significant value for users and might even hinder them.

On the one hand, in situations with many context menus (e.g., the aforementioned Gmail and Calendar), a non-visual indicator would likely be extremely noisy for users as practically every element they come across would announce that it has a (frequently changing) context menu.

On the other hand, context menus are generally not very discoverable but instead something that's just assumed to be present. As a result there is usually parity for visual and non-visual users because they are not discoverable for any user.

[pkra]

If there are good use cases out in the wild, it would be good to bring them up.

[vick08]

I would like to politely disagree! :)
The "context menu" paradigm exists on desktop for many years and is somehow acceptable. Take VOiceOver as an example. The "context menu" and other announcements are spoken pretty much at every navigation step. Users always have the ability to turn those announcements off.
Re discoverability. These issues can and should be fixed by designers by adding visual indicators.
Semantically speaking though, I do believe ARIA should expose this information in the same way operating systems do.

[stevefaulkner]

Why not aria-haspopup=“context menu”?

[stes-acc]

Context menus are a blessing and their implementation WILL resolve situations we have for list items with actions at the end (the aria-actions debate).

But their presence should be indicated AT WILL and not always! Always announcing them is annoying, I think.

For instance, by invoking default Shift+F10 (Windows default for opening context menus), if "menu" or "context menu" with focused menu item is announced then, fine. If nothing is announced -> no context menu. And yes, you have to DEFINE this for the web platform. Which is a low hanging fruit because in Windows default browser context menus for inputs etc. are already invoked with that key combination.

Before inventing new properties, we have to investigate the clashes. What happens if you define a menu in ADDITION to an already existing context menu? Will they open with the same key combination? Likely not, otherwise you may run in issues for combos.

Items that have typically NO aria-haspopup (standard input, for instance) but want to define a custom menu in addition (there are use cases for that) its content could also MERGE in its default context menu which is always present as intrinsic part of the item.

This is annother example for the fact that extending ARIA always comes with a backload of "do this but don't do that" things for authors, browsers and assistive tech.

[vick08]

aria-haspopup=contextmenu is fine by me as long as we have a way to semantically signal the AT that pressing whatever context menu shortcut key will open a system-provided context menu.
Let's leave the announcement business to AT. They can make it a user-configurable option. I feel that the job of the spec is to enable developers mark up the UI. It is then the job of AT to decide what to do with that information.
WDYT?

[vick08]

Sorry, just realized something after reading the aria-haspopup docs on https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-haspopup#
The potential problem with repurposing aria-haspopup is that, according to the definition, the element in focus will trigger a popup. The context menu, discussed here, is a user-driven operation and it is adjacent to the current item. In other words, the user does not activate the item in focus to generate a popup. Rather they have to press a screen-reader-specific or an OS-specific shortcut key to open the context menu. I am thinking of HTML5's "contextmenu" attribute which, I believe, has been deprecated or discouraged?

[scottaohara]

one of the reasons we weren't sure about this is because everything on the web has a context menu. right click on text, a link, button, or the body of the web page - and it produces a context menu. It's unclear why ARIA specifically would need to tell AT this if it's already ubiquitous.

if someone has implemented a custom context menu - then isn't there some way that already exists for people to know this (per the design/content that describes the functionality of what the user is interacting with)? is it not available via a button (re: aria-haspopup opening a menu)? does everyone, equally, just have to figure out that a custom context menu has overwritten the standard context menu - which can be done via the same keypresses / right click functionality?

[konainm]

A few thoughts here:

1. To clearly define the ask here: Web pages offer two types of context menus:
   • Default Browser Context Menus: These appear when right-clicking anywhere on a page.
   • Custom Application-level Context Menus: For example, the context menus that show up on applications like Gmail, Google Calendar, Google Drive, etc. Our goal is to help screen reader users identify where these custom context menus are available.
2. if someone has implemented a custom context menu - then isn't there some way that already exists for people to know this - I think that is the jist of the ask here, that it may not always be directly clear to users that such a context menu exists, and hence this attribute would provide a much needed context (:P) to screen reader users.
3. aria-haspopup vs. New Attribute: aria-haspopup typically signals popups triggered by direct activation (e.g., clicking a button). Our scenario involves right-click activation, hence I think making a new attribute like aria-hascontextmenu="true" would be more appropriate. This would clearly indicate the presence of a custom context menu.

[scottaohara]

using the google apps as the example though, implementing an attribute like this would mean that almost everything would have the potential to announce it has a custom context menu - and that'd be overly noisy and per earlier comments, do nothing to inform everyone equally that such functionality exists.

That said, while there hasn't been discussion specifically in #1999, this request could potentially be solved by further movement on aria-actions, without needing to get consensus to create another new attribute for a very limited-scope purpose.

[konainm]

implementing an attribute like this would mean that almost everything would have the potential to announce it has a custom context menu - and that'd be overly noisy and per earlier comments - isn't that a risk with almost all ARIA attributes? But that does not take away from the advantages that come from them being used correctly.

That said, while there hasn't been discussion specifically in https://github.com/w3c/aria/issues/1999, this request could potentially be solved by further movement on aria-actions, without needing to get consensus to create another new attribute for a very limited-scope purpose.

I took a look at this PR: #1805 and got to this preview: https://pr-preview.s3.amazonaws.com/w3c/aria/1805/264a2b5...b85cd5e.html. aria-actions here is defined as: Identifies a related element or elements whose primary activation ( click event) will trigger a behavior or operation relevant to the referencing user interface object, such as the close button for a dialog, or a reply button relevant to the email message that references it.

If I am reading this correctly, even aria-actions seems to deal with primary actions on an actionable element. Since the custom context menu is never really a primary action, how would the two be merged? Additionally, if an element had both a primary action and a custom context menu, how would that be addressed?

In my opinion, this should still be defined as a seperate attribute given the aspect of a secondary action here.

[vick08]

Thanks Konain. Agree with your comments. Thanks for the analysis.
@stevefaulkner would you happen to have an opinion on the above. We are trying to solve a real-life use case here and, ideally, would love to have a working solution from the W3C ARIA workgroup.
Thoughts?