Aria-practices: modal dialog If JAWS user types a few letters in an input then presses ESC to exit forms mode the dialog closes

[DavidMacDonald]

TO reproduce
https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/dialog.html

1. Open dialog example with JAWS 2019 running
2. listen for the little "pop" from JAWS to enter forms mode.
3. Type a letter a-z into the first field (it doesn't do the error if you start with a number??)
4. Press esc to exit forms mode and continue down the form in virtual cursor mode

Expected results
JAWS exits forms mode, the dialog remains open and the user can continue to arrow through the form

Actual Results
The dialog closes (user is kicked out of the dialog)

I'm not sure of the solution, but I'm starting to lean towards NOT trapping ESC key if there is a dialog with form fields. Perhaps there is a less harsh solution.
This behaviour doesn't happen in NVDA

[JAWS-test]

I can confirm that the problem does not occur with NVDA, but with JAWS together with IE 11, Chrome and Firefox (even if numbers are entered).
The reason is that JAWS passes all keystrokes to the browser in Forms mode. This seems to be a bug in JAWS. That's why I'm in favor of setting an appropriate issue in JAWS and leaving the APG example as it is.

In JAWS, forms mode can also be exited with other keys that work in this APG example:

• Enter
• Num Pad +
• for input fields: Arrow key up or down

[StommePoes]

I agree. I expect keys that do SR-things to be eaten by the SR. While normally a focus/forms mode should pass everything on to the browser, a logical exception for the act of getting out of the mode itself makes sense.

[DavidMacDonald]

https://twitter.com/davidmacd/status/1191741943807643650
Here's a poll on twitter

[ZoeBijl]

I think we can come up with a solution that works everywhere. For example, we could include a confirm dialog when pressing Esc on a dialog with inputs in it.

[JAWS-test]

I think we can come up with a solution that works everywhere. For example, we could include a confirm dialog when pressing Esc on a dialog with inputs in it.

I don't think that's good, because it means adding more navigation steps, which makes operation more cumbersome.

[mcking65]

I agree that this issue is a JAWS bug and thus not for practices.

That said, a separate, tangential issue in UX would be related to preventing unintentional loss of input. There is an argument for prompting cancel if the user has filled out a significant portion of the form. If someone wishes, please submit an issue requesting such an enhancement with a proposal for how it would be designed.

[StommePoes]

If such a proposal is made, another place for this is rich content editors-- some use Esc to get focus out of the main fake-textarea.

Also, is it even doable to rely on an alertdialog? JAWS user hits Esc to leave forms mode, alertdialog opens (and of course moves focus to it). User closes alertdialog by cancelling, focus is brought back to the form input. Which should normally re-trigger focus mode, no?
Authors wishing to prevent loss of input for 3.3.4/3.3.6+UX reasons should perhaps be doing this anyway, but may be outside aria-practices.