We'd like to ensure the "Paste" button is accessible to as many users as possible.
Here, we want to determine if further work is required for e.g. blind users.

For sighted people, the "Paste" button can enabled and tested, on Desktop with current Nightly, as follows:

1. Flip the pref "dom.events.asyncClipboard.readText" to true.
2. Open https://jsfiddle.net/68hng59s/.
3. Touch the "X" button and check whether a "Paste" button occurs.

Be aware of bug 1766803 though

Jamie: is this feature relevant for a11y and does it potentially require additional code? Any context is appreciated.

Thanks for the heads up about this. This is definitely relevant for a11y.

The good news is that from my initial testing with the NVDA screen reader on Windows, this works quite nicely as is. Because it uses a menupopup, it behaves like any other Firefox context menu, with which users are already quite familiar. The appearance of the menu is reported just like the appearance of any other context menu. It might be slightly confusing to some beginning screen reader users because context menus don't tell you what's inside them when they appear - you have to move to the first item (e.g. with down arrow) in order to know what's inside them - but that's true for any context menu and is thus a pattern they will have to learn regardless.

Just to clarify, you called this a paste "button"... but from what I can see, it's really a menu item. Is there/will there be some visual styling that makes it more prominent and/or look more like a button for sighted users? That might change the semantics we should be using for a11y.

Morgan, would you mind taking a look with VoiceOver and/or HCM when you get a chance? I don't anticipate any problems, but best to be sure.

The only other thing I'd flag is that if this gets changed to use some other markup in a future iteration (e.g. you stop using a menupopup for styling reasons), that will absolutely affect a11y exposure and we will need to re-evaluate the situation.

(In reply to James Teh [:Jamie] from comment #2)

Thanks for the heads up about this. This is definitely relevant for a11y.

The good news is that from my initial testing with the NVDA screen reader on Windows, this works quite nicely as is. Because it uses a menupopup, it behaves like any other Firefox context menu, with which users are already quite familiar. The appearance of the menu is reported just like the appearance of any other context menu. It might be slightly confusing to some beginning screen reader users because context menus don't tell you what's inside them when they appear - you have to move to the first item (e.g. with down arrow) in order to know what's inside them - but that's true for any context menu and is thus a pattern they will have to learn regardless.

Thanks for having tested that and for the context.

Just to clarify, you called this a paste "button"... but from what I can see, it's really a menu item.

Yes, for simplicity I called it a "button", a menupopup with a single menu item is indeed more precise.

Is there/will there be some visual styling that makes it more prominent and/or look more like a button for sighted users?

Currently, that's not intended. FYI, Safari shows such a menu item too under certain circumstances when calling clipboard.readText(), so that's encouraging in terms of UX and presumably we'll keep it as it is.

That might change the semantics we should be using for a11y.

Thanks for making me aware of this.

Morgan, would you mind taking a look with VoiceOver and/or HCM when you get a chance? I don't anticipate any problems, but best to be sure.

With VoiceOver, I can activate the button, and the menu launches and is announced. The menu item does not get focus automatically, though, so you have to press down/next to read "Paste" :Jamie is this expected? I doubt this is a markup issue, probably a VO one.

Things look fine with Increase Contrast on macOS -- we're using native context menus so stuff "Just works". I'll test on windows with HCM and report back :)

This looks fine on windows with HCM.

If I activate the button with VO, or with keyboard on either mac or windows, the menu opens but the mouse is moved ~100px down and right from the button and that new point is used as the menu anchor. So visually, the menu isn't "attached" to the button. Is that expected?

(In reply to Morgan Reschenberg [:morgan] from comment #5)

With VoiceOver, I can activate the button, and the menu launches and is announced. The menu item does not get focus automatically, though, so you have to press down/next to read "Paste"

It's expected for context menus on Windows, but I'm not sure about Mac. What normally happens when you open a context menu with VO on Mac with VO+shift+m? What about pressing a menu button; e.g. the View button in the History sidebar?

(In reply to Morgan Reschenberg [:morgan] from comment #6)

This looks fine on windows with HCM.

If I activate the button with VO, or with keyboard on either mac or windows, the menu opens but the mouse is moved

The cursor position itself isn't moved, or? Could you please attach a screenshot, that might be helpful.

~100px down and right from the button and that new point is used as the menu anchor. So visually, the menu isn't "attached" to the button. Is that expected?

It's expected that the menu appears at the mouse position. That's based on the premise that users rarely use the keyboard instead of the mouse. Moreover, that's Safari's behavior too.

(In reply to James Teh [:Jamie] from comment #7)

(In reply to Morgan Reschenberg [:morgan] from comment #5)

With VoiceOver, I can activate the button, and the menu launches and is announced. The menu item does not get focus automatically, though, so you have to press down/next to read "Paste"

It's expected for context menus on Windows, but I'm not sure about Mac. What normally happens when you open a context menu with VO on Mac with VO+shift+m? What about pressing a menu button; e.g. the View button in the History sidebar?

The same thing happens with VO and the native context menu for webpages, so I imagine this is ok

I've attached a screen recording of what I'm seeing.
It looks like the context menu always launches at the mouse location, when I activate the paste button.
However, for other interactive elements (ie. the jsfiddle navigation) if I launch the context menu we first route the mouse to the element and then launch the context menu at the mouse.

This "routing the mouse" behaviour might be a little hack-ish. FWIW Safari's behaviour is inconsistent, too.
If I launch the context menu on the jsfiddle navigation there, it launches at the center of the focused element without routing the mouse.
If I launch the context menu on the paste button in the fiddle, it launches at the mouse location or the center of the button element non-deterministically.

(In reply to Morgan Reschenberg [:morgan] from comment #11)

I've attached a screen recording of what I'm seeing.
It looks like the context menu always launches at the mouse location, when I activate the paste button.
However, for other interactive elements (ie. the jsfiddle navigation) if I launch the context menu we first route the mouse to the element and then launch the context menu at the mouse.

This "routing the mouse" behaviour might be a little hack-ish. FWIW Safari's behaviour is inconsistent, too.
If I launch the context menu on the jsfiddle navigation there, it launches at the center of the focused element without routing the mouse.
If I launch the context menu on the paste button in the fiddle, it launches at the mouse location or the center of the button element non-deterministically.

Thanks, now I understand.

AFAIU, Firefox's current behavior is acceptable. If not, please reopen this ticket.