Use the native `<dialog>` element for Popovers/modals

[aristath]

What problem does this address?

Our current popovers are custom implementations. We use <div> elements for everything, and have a lot of custom JS to handle the accessibility of those: Handling esc events, focus, keyboard navigation and so on. There is however an alternative... The native HTML <dialog> element handles most of these things automatically and is semantically the right element to use for modals, popovers & dialogs. It is stylable, supported by all browsers, and will allow us to clean up a lot of code while at the same time improving the project's a11y.

[ciampo]

Hey @aristath , thank you for opening the issue!

The <dialog /> element won't probably adapt to all the needs that we have for a popover — for example, a tooltip is not a dialog.

A new Popover API is starting to land in browsers, but it's still early days (also, see the difference between popover and dialog APIs).

Finally, even in a scenario where these APIs would be stable and well-supported by browsers, it may not be straightforward for our @wordpress/components package to use them, since we have a series of components that all rely on Popover, and some of them have complex implementations (like DropdownMenu).

We're also migrating such components to third-party headless libraries that comply with accessibility requirements while offering a refined user experience.

[aristath]

The <dialog /> element won't probably adapt to all the needs that we have for a popover — for example, a tooltip is not a dialog.

Then perhaps a tooltip should use a different component? We have many scenarios for which the <dialog> element would be a perfect fit... So perhaps we could introduce a new component and migrate those scenarios to the new one?

[afercia]

Just adding some technical details:

So far, the <dialog> element couldn't be used because its initial focus behavior was not spec'ed. On 26 January 2023 (that is 4 months ago), the HTML working group finally agreed on the initial focus behavior after a mylti-year discussion. That's now detailed in the specification. However, that's doesn't mean the initial focus behavior is actually fully implemented in the browsers we support. Also, I'm not sure there's any data yet about actual screen readers support. For these reasons, we may want to wait a bit before considering using the <dialog> element.

More details:

Dialog Focus in Screen Readers - (Spec) Update: 26 January 2023 by Adrian Roselli

Use the dialog element (reasonably) by Scott O’Hara - 2023.01.26

WebKit tracking bug: https://bugs.webkit.org/show_bug.cgi?id=84635

Firefox tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=840640

[ciampo]

As of today, I don't see us needing to use <dialog /> or the new popover APIs — at least in @wordpress/components.

We can evaluate in some time, after those technologies have matured and received wider adoption — but given that we're slowly migrating to use third-party libraries for our components (including the ones using popovers), I personally think that it won't likely make much sense (unless there's a clear improvement that can justify the effort).