search

w3c / aria-practices

WAI-ARIA Authoring Practices Guide (APG)
https://www.w3.org/wai/aria/apg/
Other
1.21k stars 345 forks source link

Modal Dialog Example: Nested modal dialogs don't work on Safari/VoiceOver #1241

Open diegohaz opened 4 years ago

diegohaz commented 4 years ago

The nested modal dialog example on https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/dialog.html doesn't work with Safari/VoiceOver (both on MacOS and iOS).

The VoiceOver cursor ring remains on the parent modal.

GIF showing VoiceOver being used to navigate through the nested modal page

I believe that this is because VoiceOver doesn't accept nested elements with aria-modal="true" that aren't actual descendants in the DOM. It doesn't work even using aria-owns on the parent modal.

The solution, I guess, is to put the nested dialog as a child of the parent dialog.

ZoeBijl commented 4 years ago

Thank you for the report Haz! Did you by any chance file an issue with Apple too?

diegohaz commented 4 years ago

I've found a fix for this issue, which is essentially removing the aria-modal attribute from the parent modal while the nested one is open.

The solution can be checked on Reakit nested dialogs.

Just sent #1381

mcking65 commented 4 years ago

@diegohaz, thank you for your investigation and work on this. And, very sorry for the long delay responding.

While this may fix the example, I am concerned that what we would really be doing here is hacking around a VoiceOver bug. If a modal opens a modal, and the new modal receives focus, the parent modal should now be inert from a screen reader perspective. We should not have to make the new modal descendant of the spawning modal, nor should we have to change the modality of the spawning modal.

If @cookiecrook has rationale for why authors should have to do this, and the ARIA Working Group agrees it is a reasonable authoring requirement, then we will change the example. Otherwise, we should leave the example as is, so we are demonstrating how to code to the spec. Of course, we should also work to get the downstream bug fixed.

mcking65 commented 1 year ago

Looking for someone to test. If this is still an issue, then raise a webkit or VoiceOver bug. I don't believe this is a practices issue.

cookiecrook commented 12 months ago

ARIA Practices should attempt to have working examples in the current releases of browsers, so I would recommend taking the patch that @diegohaz has graciously provided.

Matt wrote:

I am concerned that what we would really be doing here is hacking around a VoiceOver bug.

This Interop problem was caused by the ARIA WG changing the the meaning of aria-owns after WebKit had implemented from the original spec… It wasn't just a clarification. The current meaning of aria-owns was explicitly disallowed by prior versions of the spec. So this isn't really a bug in WebKit as much as an interop problem with the spec authoring process in ARIA, most of which is not testable.

In order to prevent similar problems in the future, the current WPT Accessibility Interop goal is to make all or most of ARIA testable in WebDriver as a priority, before adding any new features or making breaking changes like this again. There are WebKit trackers (223798 and 241694) for the aria-owns rearchitecture to update to the new definition of aria-owns, but testability is a higher priority for me, so that we don't have to implement the feature a third time.

That said, the WebKit rearchitecture may land before the testability changes… it just isn't my priority.

In the meantime, APG should promote working examples like Diego's.