Popover - Safari breaks browser convention in how it translates popover components to screen-readers

What type of issue is this?

Other

What information was incorrect, unhelpful, or incomplete?

Note: This is primarily for the purpose of ACD and WebDX to understand how accessibility issues can be documented in ACD, BCD and Baseline.

Popover is currently newly available in Baseline.

The Popover spec says

When using popover on elements without accessibility semantics, for instance the div element, authors should use the appropriate ARIA attributes to ensure the popover is accessible.

Technically all the browsers meet this requirement. However, a convention has been adopted with Chrome, Edge and Firefox where they automatically add aria semantics without the web author having to do so. Chrome, Edge and Firefox and an implicit aria-details relationship between a popover invoker and a popover if they're not sibling elements, and they also add a role=group to popovers which have been applied to elements without a role or a role of generic.

What browsers does this problem apply to, if applicable?

Safari

What did you expect to see?

On MacOS, when I apply a popover to an element that isn't the sibling of the popover invoker, and I use Voice Over, I should hear the aria-details relationship.

In Safari when I add a popover to an element that doesn't have a role or has a generic role, the role should be "group" in the accessibility tree.

Did you test this? If so, how?

Manual tests using MacOS 26.2 and included Safari and Voice Over. Using the code below I used Voice Over to hear if aria-details is voiced and inspected the popover to see if the group role is applied. I also Ran the second test in Google Chrome Version 147.0.7727.117

<button popovertarget=foo>something</button>
<p>...</p>
<div popover id=foo>...</div>

Can you link to any release notes, bugs, pull requests, or MDN pages related to this?

No response

Do you have anything more you want to share?

While the first issue seems to be an issue with the screen-reader, and not the browser, the browser that makes the implicit aria-details possible even though it can't be observed in the accessibility tree. There is a more thorough breakdown here, along with screen-reader recordings: https://hidde.blog/popover-accessibility/#heading-3

MDN URL

No response

MDN metadata

No response

Start with the popover compatibility entry in this repository and compare its Safari data with the reported behavior. Reproduce the HTML example on macOS using Safari and VoiceOver, checking the aria-details relationship and group role; done means the compatibility data documents the observed Safari behavior consistently with the Chrome, Edge, and Firefox convention.