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.
Jira Issue: PF-84
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-describedbyattribute.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.
Jira Issue: PF-84