Bug - [Popover] - Hoverable popover is not accessible

[jessiehuff]

EDIT 2/20/2025:

This issue can be scoped to fixing the issue seen in the hoverable Popover example, where keyboard focus gets trapped on the trigger, as well as VO not announcing the contents of the Popover (possibly missing an aria-describedby on the trigger?).

Original comment:

The hoverable popover is inaccessible by keyboard and screen reader. When tabbing to the Hoverable Popover example, it seems that the user is unable to Tab past it. The focus seems to get trapped on the Popover trigger unless I press Escape. When testing with VO, I was unable to hear the contents of the popover altogether.

I also question why we have this variant, as it seems to blur the lines between a tooltip and a popover. It seems that this variant was the result of this design discussion and might have been created because of a pipelines issue. They wanted the functionality of a popover without clicks because clicking the node opened the drawer. However, I question whether we should have an entire variant for a potentially outlier use case. If we do keep this variant, I think we should offer guidance around using it, especially in an accessible way. I also would propose that we move the example down in the list to not be as proponent. @andrew-ronaldson @lboehling

It should definitely be noted that the popover should only ever display contents and not interactive elements. These elements should only be attached to an interactive element (like a button or form field) but not static text. And if the contents should ever include semantic elements (like header text vs paragraph text) given that these aren’t conveyed when referenced by the aria-describedby attribute.

I heard from @jgiardino that she came across someone proposing that RHOAI use this variant so I think that this needs to be prioritized so that we can have an appropriate recommendation.

[jgiardino]

Thanks for raising this issue, @jessiehuff! I did want to clarify after I had a chance to follow up with the designer on the team, they were actually referring to the tooltip and not the popover, in case that info helps you with prioritization. The design pattern in question is more related to the [timestamp component with tooltip]https://www.patternfly.org/components/timestamp#default-tooltip). This design pattern is something we're interested in adopting in RHOAI, but it also has some accessibility concerns that I've raised on slack.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[thatblindgeye]

In regards to this issue, I think we can scope this to resolve the issue seen in the hoverable example where keyboard focus gets trapped on the trigger if the Popover is triggered via focus.

There's a separate issue already related to Timestamp a11y, and we can try to have an async discussion about whether this implementation of Popper really makes sense.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.