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

[EuiToolTip] tooltip stays open after button click until next mouse click #5883

Closed
jeroenbrouwer opened this issue May 6, 2022 · 14 comments
Closed

Comments

@jeroenbrouwer
Copy link

jeroenbrouwer commented May 6, 2022

Is it possible to stop the tooltip from staying open? My use case is that I have a button with a tooltip which opens a modal, after closing the modal the tooltip is still open... Quick example from the EUI docs:

ezgif-2-a0d4938948

@thompsongl
Copy link
Contributor

Looking to the WCAG criterion for tooltips, we have the interaction here partially correct:

Persistent
The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

After clicking the button, the tooltip is required to stay open until focus is removed. However, we do not yet implement a the user dismissal mechanism:

Dismissible
A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content

#4040 is tracking the effort to align with the spec, but the current behavior whereby the tooltip remains open after click will not change.

@cchaos
Copy link
Contributor

cchaos commented May 6, 2022

@thompsongl I wonder if we might be able to also allow consumers to programmatically close the tooltip if they know where their users are coming from and some of these sticky (see what I did there) situations.

@thompsongl
Copy link
Contributor

Yeah the criterion definitely allows for programmaitc dismissal under my reading of "The additional content remains visible until [...] its information is no longer valid"

@jeroenbrouwer
Copy link
Author

Here's an additional gif, this time from my application, to show the odd behaviour.

ezgif-1-abaec163e9

@thompsongl
Copy link
Contributor

Here's an additional gif

Ah yep. Focus is returned to to the button after the modal is closed, which opens the tooltip (all intentional behavior). Some programmatic dismissal mechanism would be helpful in your case.

@jeroenbrouwer
Copy link
Author

Here's an additional gif

Ah yep. Focus is returned to to the button after the modal is closed, which opens the tooltip (all intentional behavior). Some programmatic dismissal mechanism would be helpful in your case.

Yeah, it would be great to be able to force close the tooltip when the modal is toggled.

@github-actions
Copy link

github-actions bot commented Nov 5, 2022

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

@jeroenbrouwer
Copy link
Author

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

Still valid!

@1Copenut
Copy link
Contributor

@jeroenbrouwer The EUI team has been discussing this item. The use case you outlined will be difficult to account for because it involves multiple components and accessibility affordances. Modal dialogs require focus be returned to the control (usually a button) when that modal is closed. This is to ensure keyboard and screen reader users do not lose context or place in the source order.

Not showing the tooltip on modal close, even though the button has focus, would be difficult to keep track of consistently and could be a significant regression in the keyboard and screen reader UX.

@jeroenbrouwer
Copy link
Author

@jeroenbrouwer The EUI team has been discussing this item. The use case you outlined will be difficult to account for because it involves multiple components and accessibility affordances. Modal dialogs require focus be returned to the control (usually a button) when that modal is closed. This is to ensure keyboard and screen reader users do not lose context or place in the source order.

Not showing the tooltip on modal close, even though the button has focus, would be difficult to keep track of consistently and could be a significant regression in the keyboard and screen reader UX.

Thanks for the consideration. I would already be helped massively if we could programmatically close a tooltip or remove its focus. Would that be a possibility?

@1Copenut
Copy link
Contributor

I'll put a ticket into the backlog for looking at ways to programmatically close a tooltip. EUI does not recommend removing focus from buttons with tooltips because of the implications for a significant number of users.

I'll open a discovery ticket and link it here before closing this issue.

@1Copenut
Copy link
Contributor

#6430

@cee-chen
Copy link
Member

Hi @jeroenbrouwer! I left this comment on #6430 but just wanted to let you know as well, since there won't be a changelog:

As it turns out, controlling internal EuiToolTip visibility state is already currently achievable (due to it being a class component) via ref, e.g.

const toolTipRef = useRef<EuiToolTip>(null);

const hideToolTip = () => toolTipRef.current?.hideToolTip();

return (
  <EuiToolTip ref={toolTipRef} content="Tooltip content">
    <EuiButton>
      // ...
    </EuiButton>
  </EuiToolTip>
);

We will not be publicly documenting this functionality - this control has a lot of accessibility implications, and as a team, EUI only wants to recommend it for very specific use cases.

The below CodeSandbox example (hiding the tooltip on modal/flyout close) is one such use case, and you can follow the below example for your app:

https://codesandbox.io/s/morning-sky-64vyoh?file=/demo.tsx:518-552

Hope that helps, and let us know if you have any questions!

@jeroenbrouwer
Copy link
Author

Awesome, thanks for the detailed reply!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants