JAWS does not treat "enter" press as click when on aria-haspopup element within an outer contenteditable element

[tronguye]

Summary

https://jsfiddle.net/6hxt0k41/

1. Go to the above JSFiddle
2. Observe the DOM structure: A contenteditable=true div that contains a contenteditable=false div. The latter div contains a button with aria-haspop=true
3. With JAWS on, focus on the button that has the text "has aria-popup"
4. Press Enter
5. Observe that no alert is triggered. Instead, observe that focus has moved to the contenteditable=true div with the caret in the position it previously was in

Repeat the above steps, but focus on the button that has the text "no aria-popup". This time, observe the alert is triggered successfully.

Expected result

Button callback is invoked

Actual result

Focus is moved to the wrapping contenteditable div

Example

Minimal repro: https://jsfiddle.net/6hxt0k41/ More complex example, forking WCAG action menu https://codepen.io/tronguye/pen/XWPErgQ

Additional Information

JAWS version and build number

JAWS Job Access With Speech Professional Edition Version 2023.2210.29 ILM

Operating System and version

Windows 10 Enterprise Version 22H2

Browser and version:

Microsoft Edge Version 110.0.1587.69 (Official Build) (64-bit)

[tronguye]

I've added another case to the jsfiddle linked above. When aria-haspopup="dialog", the click handler is executed on full focus. On the red, staging focus that JAWS has, the handler is not invoked. Instead, the caret is moved the previous location

[stevefaulkner]

@tronguye can reproduce Note: Does not occur with NVDA