[Webkit-unassigned] [Bug 239295] AX: UsableNet re: inconsistency in hidden contents behind aria-modal dialogs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=239295

--- Comment #3 from James Craig <jcraig at apple.com> ---
I am getting different behavior in the linked URL, but I have not fully diagnosed.
https://www.w3.org/TR/wai-aria-practices-1.2/examples/dialog-modal/dialog.html 

- Most FKA outside of dialog results in looping due to scripted keyboard trap, preventing some FKA testing without a full teardown of the example.

- attempted VO Nav to contents *before* the dialog (VO Left) results in looping due to scripted keyboard trap on blur

- VO Nav to *after* the dialog (VO Right) does result in VO breaking free of the dialog, as long as JavaScript remains on.

The following results in expected behavior:
- JavaScript on, VoiceOver off.
- click on dialog trigger to show dialog
- turn JavaScript off, then turn VO on.

VO remains in modal dialog unless the user tabs outside of it. In which case, the aria-modal state is invalidated as expected.

That's all the diagnosis I have time for at the moment. My hunch is that the dialog is being created while focus is left outside the dialog, resulting in immediate invalidation of the modal state. My example may not reproduce because the focus() call is in the same event loop as the dialog creation.

If hunch is correct, the workaround until a fix is deployed cold be to focus inside the dialog before marking it as modal, or focus in the same runloop instead of a delayed timeout. (Delayed timeout is a common pattern due to prior bugs in various web engines, so the latter is not a feasible workaround proposal.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220413/6b88486a/attachment.htm>