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
When opening a tooltip by hovering the pointer, tooltip is dismissed when moving the pointer to hover over tooltip content.
This seems to violate Success Criterion 1.4.13 Content on Hover or Focus, which states:
If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
Any of the example tooltips in the docs page can be used to reproduce the behavior.
Suggested solution(s)
We could attach new event listeners to the TooltipContent, either inside of the TooltipContent component itself, or by using a forwardRef from higher in the component tree. We may be able to reuse the existing state transitions for MOUSE_ENTER, MOUSE_LEAVE and MOUSE_MOVE for the new callbacks.
I think the existing delay for dismissal could account for any "gaps" between the tooltip trigger element and its content element, but if the pointer moves between each element for too long, this could still cause the tip to be dismissed (not sure if that would be undesirable?). If the dismissal delay time were ever set to 0 or another low number (maybe in a potential future where delay time is configurable?) then this method definitely wouldn't work. In that case, we might need to think about a way to eliminate the "gap" between the trigger and content elements so that moving the pointer from trigger to tooltip content wouldn't trigger a MOUSE_LEAVE transition.
Additional context
This only effects validation against WCAG 2.1, not 2.0.
Your environment
Software
Name(s)
Version
Reach Package
@reach/tooltip
^0.7.3
React
react
^16.12.0
Browser
Chrome
79.0.3945.117
Assistive tech
VoiceOver
10 (708.5)
Node
node
10.16.3
npm/yarn
npm
6.9.0
Operating System
macOS Catalina
10.15.2
The text was updated successfully, but these errors were encountered:
AFAIK criteria for tooltips specifically still aren't finalized. Interestingly enough, native tooltips in the browser don't behave that way either despite the example in your link suggesting that they should. In Chrome they linger for a moment and then fade out, whereas in FF they seem to disappear a bit more quickly whether you hover over the tooltip text or not.
Closing this for now, as I'm not sure that there's a violation here. That said, all components will be audited by WebAIM prior to our 1.0 release and we'll get clarity on our approach to tooltip at that time.
Is there any chance we can re-open this so this can be addressed? I found that the original bug report was accurate and will still be relevant with WCAG 2.2 as well (based on the working draft).
🐛 Bug report
Current Behavior
When opening a tooltip by hovering the pointer, tooltip is dismissed when moving the pointer to hover over tooltip content.
This seems to violate Success Criterion 1.4.13 Content on Hover or Focus, which states:
https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html
Expected behavior
Users can activate the tooltip on hover and be able to move the pointer to hover over tooltip content without the tooltip disappearing.
Reproducible example
reach-ui Tooltip Documentation
Any of the example tooltips in the docs page can be used to reproduce the behavior.
Suggested solution(s)
We could attach new event listeners to the
TooltipContent
, either inside of theTooltipContent
component itself, or by using a forwardRef from higher in the component tree. We may be able to reuse the existing state transitions forMOUSE_ENTER
,MOUSE_LEAVE
andMOUSE_MOVE
for the new callbacks.I think the existing delay for dismissal could account for any "gaps" between the tooltip trigger element and its content element, but if the pointer moves between each element for too long, this could still cause the tip to be dismissed (not sure if that would be undesirable?). If the dismissal delay time were ever set to 0 or another low number (maybe in a potential future where delay time is configurable?) then this method definitely wouldn't work. In that case, we might need to think about a way to eliminate the "gap" between the trigger and content elements so that moving the pointer from trigger to tooltip content wouldn't trigger a MOUSE_LEAVE transition.
Additional context
This only effects validation against WCAG 2.1, not 2.0.
Your environment
The text was updated successfully, but these errors were encountered: