Integrate CloseWatcher to dialog patterns

[artalar]

Mobile users, especially on Android, are accustomed to closing modal dialogs using the native back button—a common pattern in modern mobile UX. It would be beneficial to include notes explaining why handling the back button with history manipulation is considered bad practice, and to mention the new CloseWatcher API as a better alternative.

• CloseWatcher spec
• CloseWatcher MDN

Why navigation history isn't a viable option

Let's examine the different implementation approaches:

- Opening a modal dialog
  - `pushState` implementation
    - 👍 "back" button handled perfectly
    - 👎 if the page reloads for any reason (user switches to another app and the OS kills the process), there's no way to restore the state, and the back button appears to do nothing on the first press which is very misleading
  - Query parameters implementation
    - 👍 "back" button handled perfectly
    - 👍 page reload handled perfectly
    - 👎 extraneous data in the URL could lead to unexpected UI states if the link is shared and opened by a different user
  - Hash implementation
    - 👎 same issues as query parameters, but also cannot handle nested dialogs

As demonstrated above, there's no way to implement perfect back button handling with the native history API without significant drawbacks.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 3308: Supporting "back" in modal dialogs on mobile devices.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 3308: Supporting "back" in modal dialogs on mobile devices
<jugglinmike> github: https://github.com//issues/3308
<jugglinmike> Matt_King: This is related to the way modal dialogs are handled on mobile devices
<jugglinmike> lola: I can share a little context into what "close watcher" is--I'm currently implementing it in the Servo browser
<jugglinmike> lola: It's a mechanism to allow modal-type elements to respond to closing in a similar way as dialog
<jugglinmike> lola: It should be native within the browser--it's not something that the user has to install or the author has to install
<jugglinmike> lola: It's part of HTML. It inherits from EventTarget, so it behaves like an event
<jugglinmike> lola: There is a page for this on MDN, if folks want to read more in detail
<arigilmore> https://developer.mozilla.org/en-US/docs/Web/API/CloseWatcher
<jugglinmike> https://developer.mozilla.org/en-US/docs/Web/API/CloseWatcher
<jugglinmike> lola: This will respond to different mechanisms for closing, e.g. swiping, hitting "back", etc.
<jugglinmike> lola: You can specify which element to put the close watcher on
<jugglinmike> Matt_King: That's pretty cool!
<jugglinmike> Matt_King: This sounds like a good idea
<jugglinmike> lola: I don't know whether it's available across all browsers. I know that it's in Firefox (but not the main release)
<jugglinmike> Matt_King: So you need a fallback. That sounds complicated because how would you know that closewatcher is doing what it's supposed to do?
<jugglinmike> Jem: How does this help accessibility?
<jugglinmike> lola: I'm a bit confused about why this person opened the issue because I don't think this needs to be in APG.
<jugglinmike> Matt_King: The author is saying that it would make the standard "back" button in Android work. That doesn't work right now
<jugglinmike> Matt_King: ...and I think there's an accessibility argument to be made for that kind of support
<jugglinmike> Jem: I don't think this is about APG patterns. This is about usability improvements for the APG website... Right?
<jugglinmike> Matt_King: I think it's something we would include in specific examples, like the modal dialog example
<jugglinmike> lola: The interface is not limited to mobile, but it's useful in mobile because on mobile, you have more options for how you can close something
<jugglinmike> lola: But it can be used on desktop, as well
<jugglinmike> Jem: So it enhances usability
<jugglinmike> Matt_King: In terms of where we would possibly utilize this in APG--
<jugglinmike> lola: If you have anywhere that you use dialog or popover
<jugglinmike> Matt_King: We're not using the "dialog" element, but we have multiple examples with the "dialog" role
<jugglinmike> Matt_King: It sounds like a potentially good thing, but I guess the complicated part is: if it's not supported, then how do you fall back in a reliable way?
<jugglinmike> arigilmore: I think it makes sense to table this for now
<jugglinmike> Matt_King: In practice, I think this means that we will not add "assignee", and for a label, we will use "P3", "enhancement", and "example page"