Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tooltip does not pass WCAG 2.1 AA Success Criterion 1.4.13 (Content on Hover or Focus) #439

Closed
darthrellimnad opened this issue Jan 23, 2020 · 3 comments
Labels
Status: Unconfirmed Bug reports without a repro, not yet confirmed

Comments

@darthrellimnad
Copy link

darthrellimnad commented Jan 23, 2020

🐛 Bug report

Current Behavior

When opening a tooltip by hovering the pointer, tooltip is dismissed when moving the pointer to hover over tooltip content.

reach-ui-tooltip-bug

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;

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 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
@chaance
Copy link
Member

chaance commented Jan 24, 2020

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.

@chaance chaance added the Status: Unconfirmed Bug reports without a repro, not yet confirmed label Jan 24, 2020
@chaance
Copy link
Member

chaance commented Feb 3, 2020

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.

@karrie-humu
Copy link

karrie-humu commented May 23, 2022

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Unconfirmed Bug reports without a repro, not yet confirmed
Projects
None yet
Development

No branches or pull requests

3 participants