Area
React Components (@fluentui/react-components)
Describe the feature that you would like added
PopoverSurface currently assigns role="group" whenever trapFocus is false, regardless of the content or intended interaction pattern. This makes every non-modal popover a semantic group, even when its children do not form a logical collection of related user interface objects.
WAI-ARIA defines group as a set of user interface objects and recommends it for logical collections within widgets. PopoverSurface can contain many kinds of content, so role="group" is not an appropriate universal default.
In the reported Narrator scenario ADO #18661, the default role produced the announcement "contains style group" instead of communicating the popover content.
I propose that PopoverSurface use behavior-driven and author-defined semantics:
- When trapFocus is enabled, retain role="dialog" and aria-modal="true".
- For a non-modal surface, do not apply an ARIA role by default.
- Continue to preserve an explicit role supplied by the consumer, including role="group" when the content genuinely represents a logical collection.
- Do not infer role="group" solely from the presence of aria-label or aria-labelledby. An accessible name does not determine whether the content is semantically a group.
- Document the intended patterns for Tooltip, non-modal Popover, and modal Popover, including their focus and accessible naming requirements.
This would avoid imposing unrelated structural semantics while keeping PopoverSurface flexible for consumers that need a specific role.
Tests should cover:
- A non-modal surface without an explicitly supplied role.
- Preservation of an explicitly supplied role.
- A non-modal surface with an accessible name.
- A trapped-focus surface using dialog semantics.
Additional context
PR #36406 proposes to address the audited Storybook examples by focusing and naming non-interactive popover surfaces. This fixes those examples, but it does not change the default semantics emitted by the published component.
PR #36383 explored the package-level behavior and demonstrates the affected implementation and downstream snapshot impact. This proposal narrows that discussion to the desired public semantic contract rather than prescribing its exact implementation.
This proposal does not suggest using Popover instead of Tooltip for simple descriptive content. Tooltip remains appropriate when focus stays on the trigger and the popup only describes it. The request is that Popover should not impose group semantics on every supported non-modal use case.
Have you discussed this feature with our team
No response
Validations
Priority
Low
Area
React Components (@fluentui/react-components)
Describe the feature that you would like added
PopoverSurface currently assigns role="group" whenever trapFocus is false, regardless of the content or intended interaction pattern. This makes every non-modal popover a semantic group, even when its children do not form a logical collection of related user interface objects.
WAI-ARIA defines group as a set of user interface objects and recommends it for logical collections within widgets. PopoverSurface can contain many kinds of content, so role="group" is not an appropriate universal default.
In the reported Narrator scenario ADO #18661, the default role produced the announcement "contains style group" instead of communicating the popover content.
I propose that PopoverSurface use behavior-driven and author-defined semantics:
This would avoid imposing unrelated structural semantics while keeping PopoverSurface flexible for consumers that need a specific role.
Tests should cover:
Additional context
PR #36406 proposes to address the audited Storybook examples by focusing and naming non-interactive popover surfaces. This fixes those examples, but it does not change the default semantics emitted by the published component.
PR #36383 explored the package-level behavior and demonstrates the affected implementation and downstream snapshot impact. This proposal narrows that discussion to the desired public semantic contract rather than prescribing its exact implementation.
This proposal does not suggest using Popover instead of Tooltip for simple descriptive content. Tooltip remains appropriate when focus stays on the trigger and the popup only describes it. The request is that Popover should not impose group semantics on every supported non-modal use case.
Have you discussed this feature with our team
No response
Validations
Priority
Low