Create context menu component

[robintown]

This component represents a menu that opens when another UI element is right-clicked or long-pressed.

Screencast.from.2023-10-18.00-56-47.webm

Screencast.from.2023-10-18.00-57-04.webm

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	348c9a6
Status:	✅  Deploy successful!
Preview URL:	https://010c48e2.compound-web.pages.dev
Branch Preview URL:	https://context-menu.compound-web.pages.dev

View logs

[kerryarchibald]

Unless I'm missing the key binding, this doesn't seem to be accessible.
Aside from that, I don't feel super confident this should be added to CW. Right click hijacking is pretty broadly considered a dark pattern. I've raised this with the compound team to see if this is something we want to support.

[kerryarchibald]

@robintown as it turns out we already have lots of right click menus in EW Desktop. (I guess right clicking is just not something I do... I had never used them)
They're allowed per platform using BasePlatform.allowOverridingNativeContextMenus
Given that right click menus will be disabled in the browser, all their actions must be available elsewhere. Which I think means we can get away with these menus being inaccessible.
https://github.com/matrix-org/design/issues/231

[t3chguy]

Which I think means we can get away with these menus being inaccessible.

Keep in mind right click context menus are also triggered by Accessibility Technologies using the Menu key or Shift + F10, so they should be accessible if they are presented in the accessibility tree whatsoever.

[robintown]

Re: accessibility - yes, I think we do need to be careful to only provide this component as an extra convenience for pointing device users, and always provide an alternative route for accessing the menu options. Maybe it's enough to document this in the component's doc comment?

[t3chguy]

The current context menus in Element are accessible, given this it is very unlikely we'd want to degrade accessibility by removing those and running 2 implementations is worse than one we maintain ourselves.

[toger5]

Not sure this is the best place to comment.
In general I am not sure about the blue/black border around the bottom sheet mobile modal. It looks like it has a border at the tob but not left/right. On the current deployment it also has a border on one of the sides and the top.
I thik we should have the border left/right/top or nowhere. Would that make sense for this PR?

[robintown]

@t3chguy I've taken a second look at the accessibility concerns:

• The component now sets aria-haspopup="menu" on the trigger. Element Web's implementation doesn't do this, but I believe that attribute is applicable here?
• Radix's context menu implementation which we're using here does respond to the Menu key, so as long as the trigger is focusable, we appear to be good on the keyboard navigation front.
• Since the most common use case for context menus is as an additive usability improvement for pointing device users, the extra tab stop often won't be necessary (in the case of Element Web, for instance, it would probably be annoying to add that tab stop to every message, when the 'options' button is right there).
• But still, it's conceivable that a downstream project might end up with a menu that has no other keyboard-accessible entry point, so I've added hasAccessibleAlternative: boolean as a required prop. The idea is that this will get consumers to at least acknowledge whether they've taken keyboard accessibility into account, and if not, the component can provide a tab stop as a fallback.

How does this solution sound to you? I'd appreciate your review.

[t3chguy]

The component now sets aria-haspopup="menu" on the trigger. Element Web's implementation doesn't do this, but I believe that attribute is applicable here?

Yes, it does. As per MDN:

The value true is the same as menu

Agreed otherwise