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

[lolaodelola]

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

[caugner]

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 we have done occasionally is to add a non-standard behavioral subfeature that describes this behavior, and specifically #27450 comes to mind.

Ideally, this "browser convention" would become part of the specification, and then we could treat it as a spec change by adding a behavioral subfeature.

[caugner]

Is there already a Safari bug for this? Then this information could be mentioned in the notes of the corresponding Safari support statement.

[lolaodelola]

Is there already a Safari bug for this?

I can check but anecdotally Safari doesn't consider this a bug because of the expectations that Voice Over has. (This is a unique case where the browser vendor and the screen-reader vendor are the same company.)