Enhance Support for `popovertarget` and `popover` Attributes in Native Browser Popover API

[harshdeepgill]

The latest version of WordPress lacks full support for the native browser Popover API, specifically for attributes like popovertarget and popover.

popovertarget Attribute:
The popovertarget attribute should be supported on <button> and <input type="button"> elements in HTML to fully utilize the new Popover API introduced in recent browser updates.

popover Attribute:
Additionally, the popover attribute should be supported on all relevant HTML elements, including common text wrappers like <div>, <span>, <p>, etc., to allow for broader and more flexible use of the Popover API.

Expected Behavior:
The popovertarget attribute should work correctly with <button> and <input type="button"> elements.
The popover attribute should be compatible with text-wrapping elements like <div>, <span>, <p>, and others.

Steps to Reproduce:

1. Create an HTML button or input element with the popovertarget attribute.
2. Create a <div>, <span>, or <p> element with the popover attribute.
3. Attempt to trigger a popover using the new Popover API.
4. Observe that the expected behavior does not occur because these attributes are not rendered in the browser.

Environment:
WordPress Version: 6.6.1
Browser: Chrome
OS: macos

Additional Notes: Supporting these attributes will align WordPress with modern web standards, enabling developers to create more dynamic and interactive user experiences.

[harshdeepgill]

Link for Popover API Documentation ​https://developer.mozilla.org/en-US/docs/Web/API/Popover_API

[jonsurrell]

This is a valid ticket, but the issue is not with the HTML API. These attributes are not allowed by kses, specifically ​wp_kses_attr_check seems to reject them.

I'll move this to the General component for now.

[adamsilverstein]

@harshdeepgill - is this something that could be implemented as part of the Popover component?

​https://github.com/WordPress/gutenberg/blob/trunk/packages/components/src/popover/README.md

[harshdeepgill]

Replying to adamsilverstein:

@harshdeepgill - is this something that could be implemented as part of the Popover component?

​https://github.com/WordPress/gutenberg/blob/trunk/packages/components/src/popover/README.md

No, its not. It is related to the issue that wp_kses_attr_check seems to reject attributes used in native Popover API.
​https://developer.mozilla.org/en-US/docs/Web/API/Popover_API

[joedolson]

While the popover attributes don't create an inherently accessible interface, they do allow some guardrails that are very useful for building a more accessible popover. Given that, I think that we should allow that support.

To go along with that, we might want to also add a make/accessibility article talking about how to implement an accessible popover, to cover those extra bases, but making these attributes possible is a good first step.

See: ​Hidde deVries "Popover Accessibility"

[sukhendu2002]

Reproduction Report

Description

This report validates whether the issue can be reproduced.

Environment

• WordPress: 6.8-alpha-59274-src
• PHP: 8.2.26
• Server: nginx/1.27.3
• Database: mysqli (Server: 8.0.40 / Client: mysqlnd 8.2.26)
• Browser: Chrome 131.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.0
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ❌ Error condition doesn’t occur.

Additional Notes

1. ✅ The popovertarget attribute works as expected on <button> and <input type="button"> elements.
2. The popover attribute functions correctly on <div>, <span>, and <p> elements.
3. The expected behavior occurs without any issues, and the attributes are properly rendered in the browser.

Supplemental Artifacts

Add Inline:

1. popovertarget attribute is added to the button tag.
2. popover attribute is added to the div tag, as div is the most commonly used tag for the popup.

Trac ticket: https://core.trac.wordpress.org/ticket/61959

[audrasjb]

As per today's bug scrub, removing blocker severity.

[joedolson]

Due to the significant accessibility limitations of implementing the popover group of attributes without external JS support, we're moving this to future release. If later iterations of these attributes offer more sufficient accessibility support, such that a creator adding them in the editor with no external support can create an accessible interface, then we can reconsider.

@harshdeepgill If you'd like to make further comments about why you think it's necessary to have editor support for this, feel free to add those comments!

[harshdeepgill]

Hi @joedolson , thanks for reviewing this ticket.

As far as I can see Popovers were created with accessibility in mind, with a few accessibility features included out-of-box:

• Any element can become a popover, which carries over element semantics to the #top-layer as well.
• When popover elements are open, they become the next focusable element in the tabindex.
• Users can close popovers by pressing the Esc key on the keyboard, as well as clicking outside the popover to dismiss.

Please let me know if I am missing something.

[flixos90]

Replying to joedolson:

Due to the significant accessibility limitations of implementing the popover group of attributes without external JS support, we're moving this to future release. If later iterations of these attributes offer more sufficient accessibility support, such that a creator adding them in the editor with no external support can create an accessible interface, then we can reconsider.

Could you elaborate on the accessibility limitations? I have been exploring the use of the popover attributes myself, and so far had the understanding that many of the accessibility best practices were built-in. So I'm curious what the limitations are - not purely related to this ticket, but generally.

[joedolson]

It's more accurate to say that certain accessibility guardrails are baked in, but not enough to actually turn it into an independent accessible interface component.

But I'll freely admit that I'm on the fence about this. But right now the accessibility API mapping is a moving target, because it's been changing fairly rapidly. Last I checked, it had very irregular handling on mobile & was limited in WebKit, but that was months ago.

But one of the largest concerns is that since CSS Anchor Positioning is not yet mainstream, there are limitations on how usable the popover will be without JS.

What I'll say is that this can wait until late in the release cycle; it's pretty trivial to add; I just need to find the time to thoroughly check it over so that I know the exact cross-browser limitations.

Happy to move it back into the 6.8 milestone, just with the caveat that it's going to need an accompanying article on usage and limitations, and that should be considered a blocker to commit.

[flixos90]

@joedolson I would love to learn more about what you've observed. Not quite directly related to this ticket, so probably we could move this conversation elsewhere. But I'm in touch with some of the folks that have been working on the popover APIs and would love to forward any feedback as applicable.

For instance, are there specific ARIA attributes that you see incorrectly or not applied as needed? Are there certain problematic behaviors that you noted in specific browsers?

[joedolson]

I think that the only real issue that needs highlighting is ::backdrop support.

::backdrop can create contrast and focus visibility failures, because it supports a backdrop, but does not make the concealed content inert. This allows people to create an interface that's similar to a modal dialog, but that does not meet the accessibility needs of a modal dialog.

Solution: the ::backdrop property should not be used with popovers. There's no way we can protect against this, however, so it shouldn't be a blocker.

The controlled target should have a role that describes the contained content. Roles can include dialog, menu, nav, listbox, tooltip, etc.

The most generally valid case would be for the controlled target to allow popovers to control non-modal dialogs. By default, the content gets a group role. So it'll always have a role, though that role may not be the most appropriate. Again, there's really no way we can or should control this, so again - not a blocker.

But, practically speaking, I think I'd have to argue that WordPress is a content management system, and we should allow most valid attributes, regardless of usage. When it comes to the block editor, things are different; there, we're creating interfaces, and they need to meet accessibility needs - but just allowing users to properly sanitize HTML that contains valid attributes seems like something we should do.

I still think that this will need a document talking about limitation and scope, that can link to other relevant sources (​https://hidde.blog/popover-semantics/, ​https://hidde.blog/popover-accessibility/, in particular).

So, for completeness, I think that we need to add support for:

popovertarget on button elements
popover on div, dialog, and ul
popovertargetaction on button
The dialog element.

I think the popovertargetaction attribute is important because it allows a popover to contain a dismiss button that doesn't also act as an invoker, for clarity of purpose.

[audrasjb]

As per today's bug scrub: It appears this ticket is still needs feedback. As 6.8 beta 1 is very close, I'm moving it to 6.9. Feel free to move it back to 6.8 if it can be committed by Monday.

[harshdeepgill]

Hi @joedolson thanks for the feedback, I have pushed the commit addressing the changes. Please take a look, and let me know if anything else is required.

cc: @audrasjb