Re: [w3ctag/design-reviews] Early design review of modal close signals/ModalCloseWatcher (#594)

Hi @domenic!

Sorry it's taken so long to get back to you on this one. @plinss and I looked at this today during the TAG's F2F, and also some months ago [at the previous TAG F2F](https://github.com/w3ctag/meetings/blob/gh-pages/2021/01-Kronos/minutes.md#594-early-design-review-of-modal-close-signalsmodalclosewatcher), after which we failed to follow up here.

If we take a step back from the actual specific problem you have, adding a bespoke <code><var>X</var>Watcher</code> object to the platform for every <var>X</var> in the future wouldn't be great.

While a simple, higher-level approach (like Indie UI's "dismiss" event) would enable browsers to solve the Android back button problem without all this complexity, we're reminded of the experience the AOM folks had (when they defined specific accessibility events but then ripped them out and replaced them with synthetic keypresses and the like).

Given that, we find the simplicity of going with synthetic `Esc` presses instead of anything more complicated here really appealing. This would be just as easy for authors to handle as the increment/decrement synthetic arrow events thing in AOM—authors simply do what they should be doing anyway (provide aria attributes to say what their div soup is doing, and handlers for arrow key presses) and then the browser sends the events as needed. Note that the browser can often target the synthetic `Esc` correctly, if there's a real open `<dialog>` on the page or an element marked up with the appropriate ARIA. Maybe the thing to do for more "exotic" closable things is to add ARIA roles for them?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/594#issuecomment-840150249