[wp-trac] [WordPress Trac] #61959: Enhance Support for `popovertarget` and `popover` Attributes in Native Browser Popover API

[WordPress Trac]

#61959: Enhance Support for `popovertarget` and `popover` Attributes in Native
Browser Popover API
-------------------------------------+-------------------------------------
 Reporter:  harshdeepgill            |       Owner:  tirth03
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  6.8
Component:  General                  |     Version:  6.6.1
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch reporter-      |     Focuses:  ui, accessibility,
  feedback                           |  javascript, css
-------------------------------------+-------------------------------------

Comment (by 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`

 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61959#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform