Use CloseWatcher API when supported in place of escape key handlers

[lukewarlow]

Motivation

The CloseWatcher API [1][2] is a new API that allows UI components to respond to close requests, this is normally done through escape key handlers, however this API abstracts that to support newer types such as the back button / gesture on Android.

The native html dialog (when modal) and popovers have the newer Close Watcher behaviour built-in in supported browsers (Chromium), using the close watcher API would align aria-kit with the platform.

It also provides increased accessibility as on top of the back gesture/ button the Talkback back gesture (and potentially other screen readers) also triggers a close watcher.

[1] https://html.spec.whatwg.org/multipage/interaction.html#the-closewatcher-interface
[2] https://developer.chrome.com/blog/new-in-chrome-120#close-watcher

Usage example

// Probably would need to be put into a useState.
const cw = new CloseWatcher();

cw.onclose = () => {
props.onClose();
}

Requirements

Most components that have an escape key handler currently would probably benefit from this API, e.g. Dialogs, Popovers, any really anything that's an "overlay".

Workaround

The work around would be to disable the built in escape handling and manually update the open prop for example using the API in userland.

Possible implementations

Where I've implemented this I've used branching logic where this API is used where supported and then the conventional escape key handlers are used when not supported.

Alternatively a polyfill could be used (https://close-watcher-demo.glitch.me/ uses one)

[diegohaz]

Thanks for raising this, @lukewarlow!

Where I've implemented this I've used branching logic where this API is used where supported and then the conventional escape key handlers are used when not supported.

Agreed. We've employed a similar strategy to implement inert.