You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: